Kubernetes Pod 生命周期详解:阶段、状态与完整流转过程
在 Kubernetes 中,Pod 是最小的调度单元。理解 Pod 的生命周期、其经历的各个阶段(Phases)、内部容器的状态(States)以及启停过程中的机制,对于排查生产问题、优化应用部署至关重要。
一、 Pod 的高层阶段 (Pod Phases)
Pod 的生命周期通过 status.phase 字段来表示。这是一个高层次的概括,反应了 Pod 当前所处的整体状况。Pod 的阶段数量是有限且固定的,具体包括以下 5 种:
| 阶段 (Phase) | 说明 |
|---|---|
| Pending (挂起) | Pod 已被 Kubernetes 系统接受,但有一个或多个容器镜像尚未创建。这包括等待调度的实践以及通过网络下载镜像的过程。 |
| Running (运行中) | Pod 已经绑定到了一个节点,所有容器都已被创建。至少有一个容器正在运行,或者正处于启动或重启状态。 |
| Succeeded (成功) | Pod 中的所有容器都已成功终止(退出状态码为 0),且不会再重启。这通常常见于 Job 或 CronJob 任务。 |
| Failed (失败) | Pod 中的所有容器都已终止,并且至少有一个容器是因为失败而终止的(退出状态码非 0,或被系统强行终止)。 |
| Unknown (未知) | 因为某些原因(通常是与 Node 的通信失联)无法获取该 Pod 的状态。 |
二、 容器状态 (Container States)
除了 Pod 级别的 Phase,Kubernetes 还会跟踪 Pod 内部每个具体容器的状态。通过 kubectl describe pod <pod-name> 可以查看 containerStatuses 字段。
容器状态主要有以下三种:
1. Waiting (等待)
- 描述:容器仍在运行其启动完毕所需的准备工作,例如:拉取镜像(ImagePullBackOff)、挂载卷(Volume)、或者是等待依赖的密钥(Secret/ConfigMap)等。
- 常见原因:
ErrImagePull、ImagePullBackOff、ContainerCreating。
2. Running (运行中)
- 描述:容器正在正常运行,没有中断。如果配置了
postStart回调,该回调已经执行完毕。
3. Terminated (已终止)
- 描述:容器已开始执行销毁流程,或者已经执行完毕。
- 标识:会记录容器的
ExitCode(退出码)、开始时间、结束时间以及终止原因(如OOMKilled、Completed)。
三、 Pod 状况 (Pod Conditions)
在 Pod 处于生命周期的某个 Phase 时,Kubernetes 还会记录更详细的 Conditions(状况列表),用来展示 Pod 是否通过了某些里程碑。主要包括:
- PodScheduled:Pod 是否已经被调度到某个 Node。
- Initialized:所有的 Init 容器是否已经成功启动并退出。
- ContainersReady:Pod 中的所有容器是否都已准备就绪。
- Ready:Pod 是否能够对外提供服务(即通过了 Readliness Probe,已被加入 Service 的 Endpoints 列表)。
四、 Pod 完整的生命周期流程
一个 Pod 从提交给 API Server 到最后被销毁,会经历以下一系列复杂的步骤:
+-----------------------------------------------------------------------------------+
| 1. 调度与准备 (Pending) |
| [ 提交 Pod ] --> [ Scheduler 调度 ] --> [ Kubelet 接管 ] --> [ 拉取镜像/挂载卷 ] |
+-----------------------------------------------------------------------------------+
|
v
+-----------------------------------------------------------------------------------+
| 2. 初始化容器 (Init) |
| [ 运行第一个 Init 容器 ] --> [ ... ] --> [ 运行最后一个 Init 容器 ] |
+-----------------------------------------------------------------------------------+
| (全部成功退出)
v
+-----------------------------------------------------------------------------------+
| 3. 应用容器启动 (Running) |
| +---------------------------+ +---------------------------+ +----------------+ |
| | 应用容器启动 (Entry) | | PostStart 钩子执行 | | 启动探针检测 | |
| +---------------------------+ +---------------------------+ +----------------+ |
+-----------------------------------------------------------------------------------+
|
v
+-----------------------------------------------------------------------------------+
| 4. 运行中健康检测 (Ready) |
| [ 存活探针 (Liveness) ] & [ 就绪探针 (Readiness) ] |
+-----------------------------------------------------------------------------------+
| (触发删除操作)
v
+-----------------------------------------------------------------------------------+
| 5. 优雅退出 (Terminating) |
| +---------------------------+ +---------------------------+ +----------------+ |
| | 从 Endpoints 中移除该 Pod | | PreStop 钩子执行 | | 发送 SIGTERM | |
| +---------------------------+ +---------------------------+ +----------------+ |
| | |
| v (宽限期结束) |
| [ 发送 SIGKILL 强行杀死容器 ] |
+-----------------------------------------------------------------------------------+
1. 调度与准备阶段
- API Server 接收请求:客户端(如 kubectl 或 Controller)提交 Pod 声明,数据写入 etcd。
- Scheduler 调度:kube-scheduler 监听未调度的 Pod,根据调度算法选择合适的 Node,并将绑定结果写回 API Server。
- Kubelet 接管:目标 Node 上的 kubelet 探测到该 Pod 被分配给自己,开始接管。
- 初始化环境:Kubelet 调用容器运行时(CRI,如 containerd/Docker)下载镜像、准备容器存储卷以及配置网络环境。
2. 初始化容器阶段 (Init Containers)
- 如果 Pod 定义了 Init 容器,它们会按顺序串行启动。
- 每个 Init 容器必须成功退出(Exit Code 为 0),下一个 Init 容器才会启动。
- 如果任意一个 Init 容器失败,Pod 会根据
restartPolicy进行重试,直到成功或限制次数达到。在所有 Init 容器成功结束前,应用容器不会启动。
3. 应用容器启动与钩子
- 应用容器并行启动。
- PostStart 钩子:容器启动后,Kubernetes 会立即执行
PostStart钩子(如果定义了)。- 注意:
PostStart是与容器的主进程异步执行的,无法保证它在主进程(ENTRYPOINT)之前执行。
- 注意:
- 启动探针 (Startup Probe):如果配置了启动探针,Kubelet 会优先执行该探针。在启动探针通过之前,其他所有探针(Liveness/Readiness)都会被禁用。
4. 运行中健康检测
当容器正常运行后,Kubelet 会定期执行以下两类探针:
- 存活探针 (Liveness Probe):判断容器是否存活。如果探测失败,Kubelet 会杀掉该容器并根据重启策略进行重建。
- 就绪探针 (Readiness Probe):判断容器是否准备好接收流量。如果探测失败,该 Pod 会从关联的 Service Endpoints 中移除,停止接收新的请求,但容器本身不会被重启。
5. 终止与销毁阶段 (Graceful Shutdown)
当 Pod 被删除(如通过 kubectl delete 或 Deployment 滚动更新)时,Kubernetes 采用了一种确保应用无损落地的优雅退出机制:
- Pod 状态变更:API Server 将 Pod 的状态标记为
Terminating,设置一个宽限期(Grace Period,默认 30 秒)。 - 移除流量映射:Endpoint Controller 监听到 Pod 处于 Terminating 状态,将该 Pod 的 IP 从关联的 Service 列表中移除。此时,新的请求不会再路由到该 Pod。
- 执行 PreStop 钩子:Kubelet 在容器内执行
PreStop钩子。这常用于优雅下线服务(例如向注册中心注销、等待现有连接处理完成)。 - 发送 SIGTERM:PreStop 结束后(或者没有定义时),Kubelet 向容器内的 1 号进程发送
SIGTERM信号,通知应用程序开始进行清理工作。 - SIGKILL 强制终止:如果在宽限期(默认 30 秒,包含 PreStop 执行时间)结束后,容器依然在运行,Kubelet 会向容器发送
SIGKILL信号强制杀掉进程。 - 资源清理:Kubelet 告知 API Server 容器已停止,API Server 将 Pod 对象从 etcd 中彻底移除。
五、 常见故障状态排查对照表
在维护 Kubernetes 集群时,常会遇到非正常状态的 Pod,以下是常见情况的原因对照:
| Pod 显示状态 | 容器当前状态 | 可能的原因 |
|---|---|---|
| CrashLoopBackOff | Waiting / Terminated | 容器启动后频繁崩溃退出(如配置错误、内存溢出 OOM、缺少启动参数)。 |
| ImagePullBackOff | Waiting | 无法下载镜像(镜像名错误、标签不存在、未配置私有仓库凭证、网络超时)。 |
| CreateContainerConfigError | Waiting | 找不到容器启动所需的 ConfigMap 或 Secret。 |
| OOMKilled | Terminated | 容器使用的物理内存超过了 resources.limits.memory 设定的上限。 |
| ContainerCannotRun | Terminated | 容器由于权限问题(如安全上下文限制)、文件系统问题等无法启动。 |
浙公网安备 33010602011771号