17、Kubernetes 健康检查与资源管理全解析

dapp9builder

于 2025-09-29 16:25:22 发布

阅读量23

点赞数

CC 4.0 BY-SA版权

分类专栏： Kubernetes实战入门指南文章标签： Kubernetes 健康检查活性检查

本文链接：https://blog.csdn.net/dapp9builder/article/details/152507747

Kubernetes实战入门指南专栏收录该内容

22 篇文章 ¥69.90 ¥499.90 限时 7 天

订阅专栏

超级会员免费看

Kubernetes 健康检查与资源管理全解析

1. 健康检查机制

1.1 活性检查（Liveness Probe）

1.1.1 exec 活性检查

可以使用以下命令查看相关 Pod 的信息：
- kubectl describe pod ha-liveness-exec-pod
- kubectl get pods

1.1.2 httpGet 活性检查

创建 httpGet 活性检查与 exec 机制类似，但在探针规范中，使用 spec.containers.livenessProbe.httpGet 字段。示例配置如下：

apiVersion: v1
kind: Pod
metadata:
  name: ha-liveness-http-get-pod
spec:
  containers:
    [...]
    livenessProbe:
      httpGet:
        path: /livenessCheck
        port: 8080
        httpHeaders:
        - name: ha-header
          value: 10
      initialDelaySeconds: 120
      periodSeconds: 30
    [...]

各字段说明：
- spec.containers.livenessProbe ：指定活性检查的详细信息。
- spec.containers.livenessProbe.httpGet.path 和 spec.containers.livenessProbe.httpGet.port ：指定 HTTP GET 探针应发送到的服务器详细信息。若返回的响应代码为 HTTP 2xx 或 HTTP 3xx，则探针成功；否则失败。
- spec.containers.livenessProbe.httpGet.httpHeaders ：指定要随探针请求发送的其他 HTTP 头。
- spec.containers.livenessProbe.initialDelaySeconds ：指定发送第一个探针请求之前的初始延迟，此处为 120 秒。
- spec.containers.livenessProbe.periodSeconds ：指定再次发送探针的时间间隔，此处为 30 秒。

1.1.3 tcpSocket 活性检查

创建 tcpSocket 活性检查时，使用 spec.containers.livenessProbe.tcpSocket 字段指定探针详细信息。示例配置如下：

apiVersion: v1
kind: Pod
metadata:
  name: ha-liveness-tcp-socket-pod
spec:
  containers:
    [...]
    livenessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 120
      periodSeconds: 30
    [...]

各字段说明：
- spec.containers.livenessProbe ：指定活性检查的详细信息。
- spec.containers.livenessProbe.tcpSocket ：指定 TCP 套接字连接详细信息。

1.2 就绪检查（Readiness Probe）

创建就绪检查与活性检查类似，但在探针规范中，使用 spec.containers.readinessProbe 字段。示例配置如下：

apiVersion: v1
kind: Pod
metadata:
  name: ha-readiness-exec-pod
spec:
  containers:
  - name: ha-readiness-exec-pod-c-1
    image: nginx:1.10.1
    command: [ "/bin/sh", "-c", "touch /tmp/readiness; sleep 150; rm -f /tmp/readiness; sleep 600;" ]
    readinessProbe:
      exec:
        command:
        - cat
        - /tmp/readiness
      initialDelaySeconds: 120
      periodSeconds: 50

各字段说明：
- spec.containers.readinessProbe ：指定就绪检查的详细信息。
- spec.containers.readinessProbe.exec.command ：指定作为探针一部分需要执行的命令，该命令在容器内执行。
- spec.containers.readinessProbe.initialDelaySeconds ：指定发送第一个探针请求之前的初始延迟，此处为 120 秒。
- spec.containers.readinessProbe.periodSeconds ：指定再次发送探针的时间间隔，此处为 50 秒。

当就绪检查成功时，容器将被标记为 READY，Pod 将接收流量；若后续就绪检查失败，容器将被标记为 not-ready，Pod 将不再接收流量。

2. 资源管理

2.1 请求和限制

在 Kubernetes 中，控制容器资源使用的两种主要方式是请求（Requests）和限制（Limits），它们可控制 CPU 和内存等计算资源的使用，且在 Pod 规范的容器部分指定，适用于容器级别。

2.1.1 请求配置示例

apiVersion: v1
kind: Pod
[...]
spec:
  containers:
    [...]
    resources:
      requests:
        memory: "256M"
        cpu: ".2"
    [...]

此配置表示容器应使用 256MB 内存和 200 毫核 CPU 启动。

2.1.2 限制配置示例

apiVersion: v1
kind: Pod
[...]
spec:
  containers:
    [...]
    resources:
      limits:
        memory: "512M"
        cpu: "1.0"
    [...]

此配置表示容器在其生命周期内不应消耗超过 512MB 内存和 1 个 CPU 核心。

若指定了限制配置但未指定请求配置，且没有准入控制器添加默认请求配置，则限制配置的值将用作请求配置的默认值。

2.2 Kubernetes 控制器对请求和限制的处理

请求配置 ：kube - scheduler 确保 Pod 仅调度到能提供请求的计算资源的节点上。若找不到匹配的节点，Pod 将不会被调度。
限制配置 ：kubelet 确保容器在其生命周期内不会突破指定的限制。

2.3 计算资源的基本单位

Kubernetes 中计算资源单位的不同表示方式如下表所示：
| Command | Explanation |
| ---- | ---- |
| cpu: “500m” | 表示 500 毫核 CPU，等同于指定 .5 |
| cpu: “.5” | 表示 500 毫核 CPU，等同于指定 500m |
| cpu: “1.0” | 表示一个 CPU 核心，等同于指定 1000m |
| memory: “512Mi” | 表示 512 兆字节（或 536.87 兆字节） |
| memory: “512M” | 表示 512 兆字节 |
| memory: “512m” | 表示 .512 字节 |

在指定计算资源单位时，“m” 表示毫，注意不要将其与兆字节混淆。

2.4 节点计算资源不足时的情况

当容器调度到节点上正常运行，但内存需求增加，而节点没有足够的内存来满足容器的需求时，Pod 可能会从节点中被驱逐。

2.5 资源配额（Resource Quotas）

资源配额用于对集群中每个命名空间的聚合资源使用设置阈值，确保单个命名空间中的对象不会占用所有集群资源。示例配置如下：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: ha-resource-quota
spec:
  hard:
    requests.cpu: "500m"
    requests.memory: 500Mi
    limits.cpu: "1000m"
    limits.memory: 1Gi

各字段说明：
- kind ：指定 Kubernetes 对象的类型，此处为资源配额。
- metadata.name ：指定对象的名称，此处为 ha - resource - quota。
- spec.hard.requests.cpu ：对命名空间中所有 Pod 的 CPU 请求总和设置阈值，此处为 500 毫核 CPU。
- spec.hard.requests.memory ：对命名空间中所有 Pod 的内存请求总和设置阈值，此处为 500 Mi。
- spec.hard.limits.cpu ：对命名空间中所有 Pod 的 CPU 限制总和设置阈值，此处为 1000 毫核 CPU 或 1 个 CPU 核心。
- spec.hard.limits.memory ：对命名空间中所有 Pod 的内存限制总和设置阈值，此处为 1 Gi。

若有一个 30GB 可用内存的 Kubernetes 集群，有三个应用程序，可通过以下两种方式确保没有特定应用程序占用过多内存：
- 使用资源配额 ：为每个应用程序创建一个独立的命名空间，并为每个命名空间创建一个 10GB 内存限制的资源配额，以平均分配集群资源。
- 使用限制 ：使用 Pod 规范的 spec.containers[*].resources.limits 字段指定内存限制。

资源配额始终适用于命名空间级别。若创建资源配额时未明确指定命名空间，则适用于默认命名空间。创建资源配额后，命名空间中创建的所有 Pod 必须明确指定其 CPU 和/或内存请求和限制，否则 Pod 可能无法调度。

2.6 限制范围（Limit Ranges）

虽然资源配额可控制每个命名空间的聚合资源使用，但命名空间内仍可能有对象占用所有资源，而其他对象资源不足。限制范围可确保单个 Pod 不会占用所有命名空间资源。示例配置如下：

apiVersion: v1
kind: LimitRange
metadata:
  name: ha-limit-range-all
spec:
  limits:
  - default:
      memory: 800Mi
      cpu: "800m"
    defaultRequest:
      memory: 600Mi
      cpu: "600m"
    max:
      cpu: "1500m"
      memory: 1500Mi
    min:
      cpu: "100m"
      memory: 100Mi
    type: Container

各字段说明：
- kind ：指定 Kubernetes 对象的类型，此处为限制范围。
- metadata.name ：指定对象的名称，此处为 ha - limit - range - all。
- spec.limits.default ：指定 Pod 的默认 CPU 和内存限制。
- spec.limits.defaultRequest ：指定 Pod 的默认 CPU 和内存请求。
- spec.limits.max ：指定 Pod 可请求的最大 CPU 和内存。
- spec.limits.min ：指定 Pod 应请求的最小 CPU 和内存。

限制范围适用于命名空间级别。若创建限制范围时未明确指定命名空间，则适用于默认命名空间。

2.7 资源配额和限制范围的区别

资源配额 ：用于对集群中命名空间内所有对象可请求的计算资源总和设置阈值。
限制范围 ：用于对命名空间内单个 Pod 可请求的计算资源量设置阈值。

2.8 创建具有明确 CPU 和内存请求与限制的 Pod

可使用 Pod 规范的 resources.requests 字段指定 Pod 创建时应接收的最小 CPU 和内存，使用 resources.limits 字段指定 Pod 在其生命周期内可接收的最大 CPU 和内存。示例配置如下：

apiVersion: v1
kind: Pod
metadata:
  name: ha-requests-limits-pod
spec:
  containers:
  - name: ha-requests-limits-pod-c-1
    image: nginx:1.10.1
    command: [ "/bin/sh", "-c", "touch /tmp/readiness; sleep 180; rm -f /tmp/readiness; sleep 180; touch /tmp/readiness; sleep 180;" ]
    resources:
      limits:
        cpu: "500m"
        memory: "700Mi"
      requests:
        cpu: "500m"
        memory: "700Mi"

可使用以下命令查看相关 Pod 的信息：
- kubectl get pods
- kubectl describe pod ha-requests-limits-pod

通过以上健康检查机制和资源管理方法，可更高效地管理 Kubernetes 集群。

3. 操作流程总结

3.1 活性检查操作流程

graph LR
    A[开始] --> B[选择活性检查机制]
    B --> C{exec 机制}
    B --> D{httpGet 机制}
    B --> E{tcpSocket 机制}
    C --> F[配置 spec.containers.livenessProbe.exec 字段]
    D --> G[配置 spec.containers.livenessProbe.httpGet 字段]
    E --> H[配置 spec.containers.livenessProbe.tcpSocket 字段]
    F --> I[设置 initialDelaySeconds 和 periodSeconds]
    G --> I
    H --> I
    I --> J[创建 Pod]
    J --> K[使用 kubectl 命令查看 Pod 状态]
    K --> L[结束]

3.2 就绪检查操作流程

graph LR
    A[开始] --> B[配置 spec.containers.readinessProbe 字段]
    B --> C[设置 exec 命令（若使用 exec 机制）]
    C --> D[设置 initialDelaySeconds 和 periodSeconds]
    D --> E[创建 Pod]
    E --> F[观察 Pod 状态变化]
    F --> G{就绪检查是否成功}
    G -->|是| H[Pod 接收流量]
    G -->|否| I[Pod 不接收流量]
    H --> J[结束]
    I --> J

3.3 资源管理操作流程

graph LR
    A[开始] --> B[确定资源管理需求]
    B --> C{设置请求和限制}
    B --> D{设置资源配额}
    B --> E{设置限制范围}
    C --> F[配置 spec.containers.resources.requests 和 limits 字段]
    D --> G[创建 ResourceQuota 对象]
    E --> H[创建 LimitRange 对象]
    F --> I[创建 Pod]
    G --> I
    H --> I
    I --> J[使用 kubectl 命令查看资源使用情况]
    J --> K[根据情况调整配置]
    K --> L[结束]

4. 关键技术点总结

4.1 健康检查

活性检查 ：通过 exec、httpGet 和 tcpSocket 三种机制，定期检查容器的健康状态，当检查失败时，Kubernetes 会重启容器。
就绪检查 ：确保容器准备好接收流量，当检查失败时，容器将被标记为 not - ready，Pod 不再接收流量。

4.2 资源管理

请求和限制 ：控制容器的资源使用，请求用于确保容器启动时获得一定资源，限制用于防止容器超过资源使用上限。
资源配额 ：对命名空间内所有对象的资源使用总和设置阈值，避免单个命名空间占用过多集群资源。
限制范围 ：对命名空间内单个 Pod 的资源请求量设置阈值，防止单个 Pod 占用过多命名空间资源。

5. 常见问题及解决方法

5.1 健康检查问题

问题：活性检查频繁失败导致容器不断重启。
- 解决方法 ：检查探针配置，如 initialDelaySeconds 是否设置过小，导致容器还未完全启动就进行检查；检查应用程序本身是否存在问题。
问题：就绪检查失败，Pod 无法接收流量。
- 解决方法 ：检查就绪检查的命令或请求是否正确，确保容器内的相关资源存在且可访问。

5.2 资源管理问题

问题：Pod 无法调度。
- 解决方法 ：检查请求和限制配置是否合理，确保节点有足够的资源；检查资源配额和限制范围是否限制了 Pod 的创建。
问题：容器突破资源限制。
- 解决方法 ：检查 kubelet 配置是否正确，确保其能有效控制容器的资源使用。

6. 总结

Kubernetes 的健康检查机制和资源管理功能是保证集群稳定运行和高效利用资源的关键。通过合理配置活性检查和就绪检查，可以及时发现和处理容器的异常情况；通过设置请求、限制、资源配额和限制范围，可以有效控制资源的使用，避免资源浪费和冲突。在实际应用中，需要根据具体的业务需求和集群环境，灵活运用这些技术，以实现 Kubernetes 集群的高效管理。