4. Kubernetes 探针详解：Pod 生命周期与探针关系及参数调优

在弹性伸缩发布过程中，Kubernetes 探针（Probe）是质量门禁的第一道防线。探针直接决定了 Pod 何时被认定为“就绪”并接入流量，以及何时被认定为“存活”并触发重启。理解探针与 Pod 生命周期的关系，并掌握 initialDelaySeconds、periodSeconds、failureThreshold 等核心参数的调优方法，是构建可靠健康检查体系的基础。

4.1 Pod 生命周期与探针的触发时机

Pod 从创建到终止经历多个阶段，探针仅在 Pod 处于 Running 状态且容器已启动后开始工作。下图展示了 Pod 生命周期中三种探针的介入位置：

4.2 三种探针的职责与区别

Kubernetes 提供三种探针，分别服务于不同的健康检查目的。下表总结了它们的核心差异：

4.3 探针参数详解与调优策略

每个探针都包含一组可调参数，这些参数决定了探测的灵敏度、频率和容错能力。错误的参数配置可能导致频繁误判或延迟发现故障。

4.3.1 核心参数一览

4.3.2 参数调优公式与计算示例

探针的“首次健康判定时间”和“故障响应时间”可以通过以下公式计算：

• 首次健康判定时间 = initialDelaySeconds + (periodSeconds × successThreshold)
• 故障响应时间 = periodSeconds × (failureThreshold - 1) + timeoutSeconds

示例：一个 Java 应用平均启动时间 45 秒，网络偶有抖动：

initialDelaySeconds: 60    # 45s × 1.3 ≈ 60s
periodSeconds: 15          # 中等频率，平衡负载与响应速度
timeoutSeconds: 3          # 给 HTTP 请求足够时间
failureThreshold: 3        # 容忍 2 次连续失败，第 3 次触发动作
successThreshold: 1        # 一次成功即认为就绪

计算得到：

• 首次健康判定时间 = 60 + (15 × 1) = 75 秒
• 故障响应时间 = 15 × (3 - 1) + 3 = 33 秒

4.4 探针配置示例（YAML）

以下是一个包含三种探针的完整 Deployment 配置片段：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  template:
    spec:
      containers:
      - name: app
        image: my-app:1.0
        ports:
        - containerPort: 8080
        startupProbe:
          httpGet:
            path: /health/startup
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 5
          failureThreshold: 30   # 最多等待 150 秒启动
        livenessProbe:
          httpGet:
            path: /health/live
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 15
          timeoutSeconds: 3
          failureThreshold: 3
        readinessProbe:
          httpGet:
            path: /health/ready
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10
          timeoutSeconds: 2
          failureThreshold: 2

4.5 参数调优决策矩阵

根据不同的应用特征，推荐以下参数组合：

4.6 常见陷阱与避坑指南

• 陷阱 1：livenessProbe 依赖外部服务（如数据库）。
  后果：数据库抖动导致所有 Pod 被重启。
  解决：livenessProbe 只检测进程内部状态，readinessProbe 检测外部依赖。
• 陷阱 2：initialDelaySeconds 设置过小。
  后果：容器尚未完成初始化，探针连续失败触发重启。
  解决：通过 startupProbe 替代 initialDelaySeconds 的硬等待。
• 陷阱 3：periodSeconds 设置过小（如 1 秒）。
  后果：高频探测增加 API Server 和容器负载。
  解决：生产环境 periodSeconds 不低于 5 秒。
• 陷阱 4：failureThreshold 设置过大。
  后果：故障发现延迟，流量持续发送到异常 Pod。
  解决：根据业务容忍度设置，通常不超过 5。