2025，每天10分钟，跟我学K8S（二十五）- 对象属性 - Health Check

        在Kubernetes中，健康检查是确保集群中容器稳定运行的重要机制。它通过探针（Probe）定期检查容器的健康状态，并根据检查结果采取相应的措施。下面我将详细讲解Kubernetes中的健康检查机制。

健康检查种类

Kubernetes中的健康检查主要分为三种：

1. ‌存活性健康检查（Liveness Probe）‌：用于检测应用程序是否处于健康状态。如果应用程序不健康，Kubernetes将杀掉该容器，并根据容器的重启策略决定是否重启容器。这有助于及时替换掉出现问题的容器，保证服务的可用性。

2. ‌可用性健康检查（Readiness Probe）‌：用于检测应用程序是否就绪并处于正常服务的状态。如果应用程序未就绪，Kubernetes将停止向该容器发送流量，直到它通过健康检查。这有助于防止将请求发送到尚未准备好的容器，提高服务的稳定性。

3. 启动探针（Startup Probe）‌：用于容器启动时判断容器是否启动完成。在启动探针探测成功前，即容器启动成功前，存活性探针和可用性探针都不会起作用。这有助于防止某些启动很慢的容器在启动过程中被误判为不健康。

探针类型

Kubernetes支持三种类型的探针：

1. ‌HTTP探针（HTTPGet）‌：向容器中运行的服务发送HTTP GET请求，根据响应状态码判断健康状态。返回任何大于等于200且小于400的值，均表示健康。

2. ‌TCP探针（TCPSocket）‌：连接到容器的某个端口，如果探测成功，则容器是健康的。

3. ‌EXEC探针（Exec）‌：在容器中执行特定的命令，如果命令执行成功，则返回0，表示容器是健康的。

配置示例

以下是一个包含 ​Liveness探针、Readiness探针 和 ​Startup探针 的 Kubernetes Deployment YAML 示例。该示例基于 Nginx 构建，展示了三种探针的典型配置和注释说明：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-probes-demo
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.27-alpine
        ports:
        - containerPort: 80
          protocol: TCP
        # Liveness Probe（存活探针）: 确保应用持续运行
        livenessProbe:
          httpGet:
            path: /health
            port: 80
          initialDelaySeconds: 5  # 初始等待时间（秒）
          periodSeconds: 10       # 探测间隔（秒）
          timeoutSeconds: 2       # 超时时间（秒）
          successThreshold: 1     # 需要连续成功多少次才视为正常
          failureThreshold: 3     # 连续失败多少次触发重启
        # Readiness Probe（就绪探针）: 确保应用可接受流量
        readinessProbe:
          httpGet:
            path: /ready
            port: 80
          initialDelaySeconds: 5  # 初始等待时间（秒）
          periodSeconds: 10       # 探测间隔（秒）
          timeoutSeconds: 2       # 超时时间（秒）
          successThreshold: 1     # 需要连续成功多少次才视为正常
          failureThreshold: 3     # 连续失败多少次触发重启
        # Startup Probe（启动探针）: 确保应用初始化完成
        startupProbe:
          httpGet:
            path: /init-complete
            port: 80
          initialDelaySeconds: 0  # 立即开始探测
          periodSeconds: 5        # 探测间隔（秒）
          timeoutSeconds: 10      # 超时时间（秒）
          successThreshold: 1     # 需要连续成功多少次才视为正常
          failureThreshold: 60    # 允许最大60秒初始化时间
      # 服务配置（可选）
      imagePullBackOffGracePeriodSeconds: 60
      terminationGracePeriodSeconds: 300

关键配置说明：

1. ​Liveness Probe

   • ​用途：检测应用是否持续运行​（如处理崩溃/死锁）
   • ​机制：每 periodSeconds 秒发送 HTTP 请求到 /health
   • ​触发条件：连续 failureThreshold 次失败后重启 Pod

2. ​Readiness Probe

   • ​用途：检测应用是否准备好接收流量​（如依赖服务就绪）
   • ​机制：每 periodSeconds 秒发送 HTTP 请求到 /ready
   • ​触发条件：连续 failureThreshold 次失败后从 Service 中移除

3. ​Startup Probe

   • ​用途：检测应用是否完成初始化​（如数据库连接/缓存预热）
   • ​机制：每 periodSeconds 秒发送 HTTP 请求到 /init-complete
   • ​特殊配置：failureThreshold 设置为较大的值（示例为60秒）

4. imagePullBackOffGracePeriodSeconds和imagePullBackOffGracePeriodSeconds

1. imagePullBackOffGracePeriodSeconds

        imagePullBackOffGracePeriodSeconds定义了在容器启动前等待镜像拉取的最长时间。如果在这段时间内镜像仍未拉取成功，容器将进入ImagePullBackOff状态。这有助于防止因短暂的网络问题或镜像仓库延迟导致的频繁重启。在本例中为60S

     2.imagePullBackOffGracePeriodSeconds

  terminationGracePeriodSeconds 是 Pod 生命周期管理的核心参数之一，用于控制 Pod ​优雅终止的时间窗口。

        

        在上面的示例中，我们为nginx-probes-demo配置了3个pod副本，镜像使用的是nginx，配置了存活性探针、可用性探针、就绪探针。 ​

Startup决定这个pod是否初始化完毕，避免在pod未正常启动完毕的时候因为其他的2种探针而频繁杀掉自身。

Liveness探针通过指定的探测方式去探测判断当前容器是否正常，如果异常则重启。

Readiness探针通过指定的探测方式去探测判断当前容器是否可以正常接收来自service的流量转发。

三种探针的顺序：

在 Kubernetes 中，​探针的执行顺序与 ​Pod 的生命周期阶段密切相关。以下是三者作用的详细时序逻辑和场景化说明：

执行顺序总览

Pod 启动 → 
    1. Startup Probe → 
        2. Liveness Probe &  Readiness Probe（并行运行）

分阶段详解

​1. Startup Probe（启动探针）​

• ​触发时机：
  • ​Pod 第一次创建时立即执行（initialDelaySeconds: 0）。
  • 如果配置了 initialDelaySeconds > 0，则会在延迟后开始探测。
• ​作用：
  • 确保应用完成初始化​（如数据库连接、缓存预热、加载配置等）。
  • ​避免早期误判：在应用未初始化完成时，禁止 Kubernetes 因探针失败而频繁重启 Pod。
• 执行流程：
  • Pod 启动 → 立即触发 startupProbe。
  • 连续成功 successThreshold 次（默认1次） → 标记初始化完成。
  • ​后续停止：一旦初始化成功，kubelet ​不再执行该探针。

2. Liveness Probe（存活探针） & Readiness Probe（就绪探针）​

• ​触发时机：
  • ​仅在 startupProbe 成功后开始执行。
  • 若未配置 startupProbe，则两者在 initialDelaySeconds 后直接启动。
• ​执行逻辑：
  • ​并行运行：两个探针独立工作，周期由各自 periodSeconds 控制。
  • ​无固定顺序：例如，Liveness 每10秒探测一次，Readiness 每15秒探测一次，两者的执行时间点会交错。
• ​核心区别：

探针类型	目标	失败后果
​Liveness	确保应用持续运行	触发 Pod 重启（自我修复）
​Readiness	确保应用可接受流量	从 Service 中移除 Pod（流量隔离）

      

• 时序图示例

Pod 启动
├── 检查 Startup Probe → 成功？
│   ├── 是 → 初始化完成 → 启动 Liveness/Readiness 探针
│   └── 否 → 重启 Pod（不超过 failureThreshold 次）
└── Liveness 探针循环执行（周期性地检查应用健康状态）
└── Readiness 探针循环执行（周期性地检查应用就绪状态

健康检查流程

Kubernetes中的健康检查流程大致如下：

1. Kubernetes根据配置的探针类型和参数，定期触发健康检查。
2. 探针根据配置的探测方式（HTTP、TCP或EXEC）对容器进行探测。
3. 根据探测结果，Kubernetes判断容器的健康状态。
4. 如果容器不健康（存活性探针探测失败），Kubernetes将杀掉该容器，并根据重启策略决定是否重启。
5. 如果容器未就绪（可用性探针探测失败），Kubernetes将停止向该容器发送流量。

通过合理配置健康检查机制，我们可以确保Kubernetes集群中的容器稳定运行，提高服务的可用性和稳定性。