Pod生命周期#
一句话答案#
Pod 状态流转：Pending→Running→Succeeded/Failed（节点失联、状态拿不到时为 Unknown），通过 liveness/readiness/startup 探针管理健康状态。
核心要点
Pod 阶段： Pending（调度中/拉镜像）→ Running → Succeeded/Failed；另有 Unknown（节点失联、拿不到状态）
三种探针：
| 探针 | 作用 | 失败后果 |
|---|---|---|
| livenessProbe | 存活检查 | 重启容器 |
| readinessProbe | 就绪检查 | 从 Service 摘除 |
| startupProbe | 启动检查（保护慢启动应用，成功前不执行 liveness/readiness） | 超过 failureThreshold 重启容器 |
生命周期钩子： postStart（创建后）/ preStop（终止前，优雅停机；1.34 起原生 sleep 动作 GA，镜像里不需要 sleep 命令）
Init 容器与原生 sidecar： init 容器按顺序跑完才启动主容器；给 init 容器设 restartPolicy: Always 就是原生 sidecar（1.29 起默认开启，1.33 GA），它先于主容器启动、在主容器退出后才终止，不再阻塞 Job 结束
面试回答（2分钟版）
Pod是K8s最小调度单位，它的生命周期经历几个阶段：Pending表示已被接受但还在调度或拉镜像，Running表示至少一个容器在运行，最终进入Succeeded（正常结束）或Failed（异常退出）。Pod健康管理靠三种探针：startupProbe保护慢启动应用，在启动完成前其他探针不生效，避免被误杀；livenessProbe做存活检查，失败后kubelet会重启容器；readinessProbe做就绪检查，失败后Pod从Service端点摘除，不再接收流量但不重启。探针支持HTTP GET、TCP Socket和Exec三种检查方式。还有两个生命周期钩子：postStart在容器创建后执行，preStop在容器终止前执行，preStop是实现优雅停机的关键——可以在里面做连接排空、通知注册中心下线等操作，配合terminationGracePeriodSeconds设置等待时间。
追问与易错
追问方向：
- “preStop 和优雅停机怎么配合？”→ K8s 发 SIGTERM 前先执行 preStop（通常 sleep 5s 等 Service 摘除 endpoints，1.30+ 可直接写
lifecycle.preStop.sleep.seconds），然后应用收到 SIGTERM 开始拒绝新请求、完成进行中请求、关闭连接池；terminationGracePeriodSeconds 超时后强制 SIGKILL - “startupProbe 和 initialDelaySeconds 有什么区别？”→ initialDelaySeconds 是固定等待时间（设短了误杀、设长了浪费），startupProbe 在启动阶段持续探测直到成功，更灵活；推荐用 startupProbe 替代 initialDelaySeconds
- “Pod 状态一直 Pending 是什么原因？”→ 常见原因：节点资源不足（CPU/内存不够调度）、PVC 绑定失败（StorageClass 不存在或无可用 PV）、镜像拉取失败（ImagePullBackOff）、调度约束不满足（亲和性/污点）
易错点：
- ❌ 把 CrashLoopBackOff / ImagePullBackOff 当成 Pod 阶段——phase 只有 Pending/Running/Succeeded/Failed/Unknown，这些是容器 waiting 状态的 reason
- ❌ readiness 失败也会重启容器——readiness 只把 Pod 从 Service 后端摘除，只有 liveness（以及 startup）失败才触发重启
- ❌ liveness 里检查 DB/Redis 等外部依赖——依赖一抖所有 Pod 一起被重启，故障放大；liveness 只查进程自身是否假死