📚 课程目录第3章 Pod生命周期与健康检查

3. Pod 生命周期与健康检查：状态机与探针原理

Pod 是 Kubernetes 中最小的调度与部署单元，其生命周期由一组严格的状态机驱动。理解 Pod 状态转换以及三种探针（livenessProbe、readinessProbe、startupProbe）的工作原理，是实现事件驱动自愈的基础。本章将深入剖析 Pod 状态机模型，并详细讲解三种探针的配置与协作机制。

3.1 Pod 状态机：从 Pending 到 Running 再到 Terminating

Pod 从创建到销毁会经历多个阶段，每个阶段对应一个 PodPhase。Kubernetes 控制平面通过观察 Pod 的实际状态与期望状态的差异，驱动状态转换。

PodPhase	说明	典型触发条件
Pending	Pod 已被 API Server 接受，但尚未调度到节点，或镜像正在拉取	调度器未完成绑定、镜像拉取中
Running	Pod 已绑定到节点，所有容器已创建，至少一个容器处于运行或启动中状态	容器运行时启动成功
Succeeded	Pod 中所有容器均正常退出（退出码 0），且不会重启	Job 或批处理任务完成
Failed	Pod 中至少一个容器以非零退出码退出，或被系统终止	容器崩溃、OOM、健康检查失败
Unknown	API Server 无法获取 Pod 状态，通常由于节点失联	节点网络分区、kubelet 停止响应

  关键点： Pod 的 status.phase 是只读的顶层字段，由 kubelet 和控制器管理器共同维护。自愈机制主要关注 Running 阶段内的容器级健康检查，而非 PodPhase 本身。

3.2 三种探针：liveness、readiness、startup 的职责与区别

Kubernetes 提供了三种探针，分别服务于不同的生命周期阶段。它们都支持 HTTP GET、TCP Socket 和 Exec Command 三种检测方式。

探针类型	检测目标	失败后果	典型场景
livenessProbe	容器是否存活（进程是否健康）	kubelet 重启容器（RestartPolicy 生效）	死锁、内存泄漏、进程挂起
readinessProbe	容器是否准备好接收流量	从 Service Endpoints 中移除 Pod	应用启动加载、缓存预热、依赖服务未就绪
startupProbe	容器是否已完成启动初始化	kubelet 重启容器（类似 liveness）	慢启动应用（Java、Legacy 应用）

最佳实践： 对于启动时间较长的应用，务必配置 startupProbe，并设置较长的 failureThreshold * periodSeconds。在 startupProbe 成功之前，livenessProbe 和 readinessProbe 不会生效。

3.3 探针配置参数详解

每个探针都包含一组可调参数，用于控制检测频率、超时、重试和优雅终止时间。

apiVersion: v1
kind: Pod
metadata:
  name: probe-demo
spec:
  containers:
  - name: app
    image: myapp:1.0
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 5      # 容器启动后等待 5 秒再开始探测
      periodSeconds: 10           # 每 10 秒探测一次
      timeoutSeconds: 3           # 探测超时时间 3 秒
      successThreshold: 1         # 连续成功 1 次视为健康
      failureThreshold: 3         # 连续失败 3 次触发重启
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      initialDelaySeconds: 3
      periodSeconds: 5
      timeoutSeconds: 2
      successThreshold: 1
      failureThreshold: 2
    startupProbe:
      httpGet:
        path: /startup
        port: 8080
      initialDelaySeconds: 0
      periodSeconds: 2
      timeoutSeconds: 2
      successThreshold: 1
      failureThreshold: 30        # 最多允许 60 秒启动时间 (30 * 2s)

避坑提示： initialDelaySeconds 与 startupProbe 不要同时设置过大的值。如果应用启动需要 30 秒，建议使用 startupProbe 的 failureThreshold * periodSeconds 来控制，而不是依赖 livenessProbe 的 initialDelaySeconds，否则可能错过真正的死锁检测窗口。

3.4 三种探针的协作时序图

下图展示了 Pod 启动过程中三种探针的激活顺序与相互影响关系。

3.5 探针检测方式对比

三种探针均支持以下三种检测机制，选择时需考虑应用特性与安全要求。

检测方式	配置字段	适用场景	注意事项
HTTP GET	`httpGet`	提供 HTTP 端点的 Web 应用	返回 2xx/3xx 视为成功；避免暴露敏感接口
TCP Socket	`tcpSocket`	非 HTTP 协议（gRPC、Redis、MySQL）	仅检测端口是否监听，无法验证业务逻辑
Exec Command	`exec`	需要自定义检查逻辑（脚本、二进制）	退出码 0 为成功；注意命令执行开销

3.6 自愈场景中的探针配置策略

在事件驱动自愈架构中，探针是触发自愈动作的第一道信号源。以下配置策略可提升自愈的准确性与响应速度。

分级检测： 使用 startupProbe 处理慢启动，避免误重启；使用 livenessProbe 检测死锁；使用 readinessProbe 控制流量灰度。
合理设置阈值： failureThreshold 不宜过小（避免抖动误判），也不宜过大（延迟自愈）。建议 liveness 设为 3，readiness 设为 2。
避免探针耦合： 探针不应依赖外部服务（如数据库），否则级联故障会导致大规模重启。应使用 readinessProbe 检测外部依赖，livenessProbe 仅检测进程自身健康。
结合事件监控： 探针失败会生成 Killing、Unhealthy 等事件，可被事件驱动框架捕获并触发自动化恢复流程。

  自愈触发链路： livenessProbe 连续失败 → kubelet 生成 Unhealthy 事件 → 容器重启 → Pod 状态短暂进入 CrashLoopBackOff → 事件驱动控制器（如 KEDA、自定义 Operator）捕获事件 → 执行高级自愈动作（如重新调度、扩容、通知）。

3.7 常见问题与排查思路

现象	可能原因	排查命令
Pod 频繁重启	livenessProbe 配置过于严格或应用启动慢	`kubectl describe pod <pod>` 查看 Last State 与 Events
Pod 一直处于 Running 但无法访问	readinessProbe 失败，Pod 未加入 Service Endpoints	`kubectl get endpoints <svc>` 检查 Pod 是否在列表中
Pod 启动后立即被重启	startupProbe 未配置，livenessProbe 在启动完成前开始探测	增加 startupProbe 并设置合理的 failureThreshold
探针日志无输出	Exec 探针命令路径错误或权限不足	`kubectl exec <pod> -- <command>` 手动测试