Kubernetes Pod 生命周期与容器探针详解

1. Pod 的完整生命周期
2. 两种探针的分工
3. 探针配置实战
4. 优雅退出：从停止到销毁
5. 高频排障速查

1. Pod 的完整生命周期

Pod 是 Kubernetes 最小的调度单元。它的一生可以用这张状态流转图概括：

Pending → Running → Succeeded / Failed
             │  ↑
             └── 多次重启后也可能进入 CrashLoopBackOff

Pending —— Pod 已创建，等待调度与容器启动。卡在这里通常是资源不足（Requests 超配）或节点污点未容忍。
ContainerCreating —— 镜像拉取、卷挂载、Init 容器执行中。卡住多为镜像拉取慢、私有仓库认证失败。
Running —— 所有容器正常运行，可以对外提供流量。
Succeeded / Failed —— 正常完成 / 因错误退出。
CrashLoopBackOff —— 容器反复崩溃重启，Backoff 指数增长。最常见也是最好查的异常态。

排查工具 kubectl describe pod <name> 看 Events，kubectl logs <name> --previous 看上次崩溃的日志。90% 的 Pod 异常都靠这两条命令定位。

2. 两种探针的分工

很多刚接触 K8s 的同学分不清 liveness 和 readiness，这里用一句话记住：

liveness 决定「要不要重启」，readiness 决定「要不要接流量」。

livenessProbe —— 探活。失败会杀掉容器并重建，用于检测死锁、无限循环等不可恢复状态。
readinessProbe —— 就绪。失败只是从 Service 的 Endpoints 中摘除，不重启容器，用于检测「正在加载配置/依赖未就绪」等暂时性状态。
startupProbe —— 启动探针（1.16+）。用于保护启动很慢的应用，避免 liveness 在启动阶段误杀。

3. 探针配置实战

一份生产级配置示例：

apiVersion: v1
kind: Pod
metadata:
  name: demo-app
spec:
  containers:
  - name: app
    image: registry.example.com/demo:1.2.3
    ports:
    - containerPort: 8080
    startupProbe:
      httpGet:
        path: /health/startup
        port: 8080
      failureThreshold: 30
      periodSeconds: 5
    livenessProbe:
      httpGet:
        path: /health/live
        port: 8080
      initialDelaySeconds: 10
      periodSeconds: 10
      timeoutSeconds: 3
      failureThreshold: 3
    readinessProbe:
      httpGet:
        path: /health/ready
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 5
      timeoutSeconds: 2
      failureThreshold: 3

三个常见坑 ① 三个探针共用一个健康端点，应用加载慢时会被 liveness 误杀 —— 用 startupProbe 兜底； ② timeoutSeconds 设太小（默认 1s），GC 触发时误报失败； ③ 不要给 liveness 探针依赖外部组件（如数据库），否则 DB 抖动会导致整批容器滚动重启。

4. 优雅退出：从停止到销毁

删除 Pod 时，K8s 并不会立刻杀死容器，而是走一遍优雅停机流程：

$ kubectl delete pod demo-app
# 1. 状态变为 Terminating，readiness 探针失效，从 Service 摘除流量
# 2. 发送 SIGTERM，等待 terminationGracePeriodSeconds（默认 30s）
# 3. 超时后发送 SIGKILL，强制杀掉
$ kubectl delete pod demo-app --grace-period=10 --force

应用应监听 SIGTERM，完成「停止接收新请求 → 处理完存量请求 → 清理资源 → 退出」。
配合 preStop Hook 可以实现更精细的摘流量逻辑（例如调用注册中心下线接口）。
滚动更新失败时，kubectl rollout undo deployment/demo-app 一键回滚。

5. 高频排障速查

把最常见的 Pod 症状和处置直接列成速查表：

症状	定位命令	常见原因
卡在 Pending	describe 看 Events	资源不足 / 污点不匹配
CrashLoopBackOff	logs --previous	应用启动即崩溃
频繁重启但无崩溃日志	describe Events	liveness 误杀
有流量但无响应	exec 进容器检查	readiness 摘流量异常

探针设计的核心原则：readiness 保守（尽早摘流量），liveness 宽松（只杀真正死掉的）。按这个原则配置，绝大多数抖动都不会演变成事故。

← 返回首页