在 Kubernetes（K8s）中，Pod 作为最小的部署和调度单元，其生命周期贯穿了 “创建→运行→终止→销毁” 的完整过程。理解 Pod 的生命周期，不仅能帮我们精准排查 Pod 启动失败、频繁重启等问题（如部署 TodoList 项目时遇到的 Pod 重启问题），更能通过生命周期钩子和探针设计高可用的应用部署策略。本文将从核心阶段、关键机制、实战案例三个维度，彻底讲透 Pod 生命周期。

一、Pod 生命周期核心阶段：从诞生到消亡

Pod 的生命周期由 K8s 的 kubelet 组件主导管理，核心分为 5 个阶段，每个阶段对应明确的状态标识和行为逻辑：

1. 挂起（Pending）

• 核心特征：Pod 已被 K8s API 服务器接受，但尚未被调度到具体 Node，或容器镜像正在拉取、初始化容器未完成。
• 常见场景：
  • 集群资源不足（CPU / 内存不够），调度器无法分配 Node；
  • 离线环境下镜像拉取失败（如部署 TodoList 时因 CentOS 基础镜像缺失导致 Pending）；
  • 初始化容器（Init Container）执行耗时过长。
• 排查命令：kubectl describe pod <pod-name>，查看 Events 字段中的 “FailedScheduling”“ImagePullBackOff” 等提示。

2. 运行中（Running）

• 核心特征：Pod 已被调度到 Node，所有容器（含初始化容器）已成功启动，至少有一个容器处于运行状态。
• 注意点：
  • “Running” 不代表应用可用（如 TodoList Pod 显示 Running 但因端口不匹配无法访问）；
  • 若配置了存活探针，需探针检测通过才能维持 Running 状态。

3. 成功（Succeeded）

• 核心特征：Pod 内所有容器（含初始化容器、业务容器）都已正常终止，且不会被重启。
• 适用场景：一次性任务（Job/CronJob），如数据库初始化、数据备份脚本执行完成。
• 示例：kubectl run job-pod --image=centos:7.9.2009 --command -- /bin/sh -c "echo '任务完成' && exit 0"，执行完成后 Pod 状态变为 Succeeded。

4. 失败（Failed）

• 核心特征：Pod 内至少有一个容器非正常终止（退出码非 0），且不会被自动重启（除非配置了重启策略）。
• 常见原因：
  • 容器启动命令错误（如执行不存在的脚本）；
  • 应用代码崩溃（如 TodoList 代码语法错误导致容器退出）；
  • 权限不足（如执行无权限的可执行文件）。

5. 未知（Unknown）

• 核心特征：K8s 无法获取 Pod 的状态（如 Node 节点失联、kubelet 组件故障）。
• 处理方式：检查 Node 状态（kubectl get nodes），重启失联 Node 的 kubelet 服务（systemctl restart kubelet）。

二、Pod 生命周期的关键机制：钩子与探针

除了基础阶段，K8s 通过生命周期钩子和容器探针，让我们能干预 Pod 的生命周期、检测容器健康状态，这是保障应用稳定性的核心手段。

1. 生命周期钩子（Lifecycle Hooks）

钩子函数允许在容器启动前、终止前执行自定义逻辑，分为两种类型：

钩子类型	执行时机	常用场景	实现方式示例
postStart	容器创建完成后立即执行	初始化配置（如修改应用配置文件）、注册服务	执行curl http://registry:8080/register
preStop	容器终止前执行（优雅退出）	数据持久化、关闭数据库连接、通知服务下线	执行/app/stop.sh（自定义停止脚本）

实战配置示例（TodoList Pod）：

yaml

apiVersion: v1
kind: Pod
metadata:
  name: todo-list-pod
spec:
  containers:
  - name: todo-list
    image: todo-list:v1.0
    ports:
    - containerPort: 8000
    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh", "-c", "chmod +x /app/todo && echo '容器启动完成' >> /var/log/start.log"]
      preStop:
        exec:
          command: ["/bin/sh", "-c", "curl http://172.16.2.47:30001/shutdown && sleep 5"]

2. 容器探针（Probes）

探针是 kubelet 对容器的周期性健康检查，通过检测结果决定容器的生命周期状态，分为三种类型：

（1）存活探针（livenessProbe）：检测容器是否 “存活”

• 作用：探针失败→kubelet 重启容器（核心用于恢复故障容器）。
• 常见错误案例：部署 TodoList 时，因存活探针配置的 8080 端口与应用实际监听的 8000 端口不匹配，导致 Pod 频繁重启。
• 配置示例：

yaml

livenessProbe:
  httpGet:  # 基于HTTP请求检测（也可使用exec、tcpSocket）
    path: /health  # 应用健康检查接口
    port: 8000
  initialDelaySeconds: 30  # 容器启动30秒后开始检测
  periodSeconds: 10        # 每10秒检测一次
  timeoutSeconds: 5        # 检测超时时间5秒
  failureThreshold: 3      # 连续3次失败则判定容器异常

（2）就绪探针（readinessProbe）：检测容器是否 “就绪（可提供服务）”

• 作用：探针失败→K8s 将 Pod 从 Service 的 Endpoints 中移除（停止转发流量），但不重启容器。
• 适用场景：应用启动后需要加载配置 / 数据（如数据库连接），加载完成前不接收流量。
• 配置示例：

yaml

readinessProbe:
  tcpSocket:  # 基于TCP端口检测
    port: 8000
  initialDelaySeconds: 10
  periodSeconds: 5

（3）启动探针（startupProbe）：检测容器是否 “启动完成”

• 作用：专用于慢启动应用（如大型 Java 应用），探针成功前，存活 / 就绪探针不生效；失败则重启容器。
• 配置示例：

yaml

startupProbe:
  exec:  # 基于命令执行结果检测
    command: ["/app/check-start.sh"]  # 自定义启动检测脚本
  failureThreshold: 30
  periodSeconds: 10

3. 重启策略（RestartPolicy）

Pod 的重启策略决定了容器异常时的重启逻辑，与探针配合使用，可选值：

策略值	核心逻辑
Always	容器无论因何原因终止，都自动重启（默认值，适用于无状态服务如 TodoList）
OnFailure	仅容器非正常终止（退出码非 0）时重启（适用于 Job 任务）
Never	容器终止后永不重启（适用于一次性初始化任务）

三、Pod 生命周期实战：典型问题与解决方案

结合部署 TodoList 项目的实战经验，梳理 Pod 生命周期相关的高频问题及解决思路：

问题 1：Pod 状态 Pending，提示 “ImagePullBackOff”

• 原因：离线环境下无法拉取镜像，或镜像名称 / 标签错误。
• 解决方案：
  1. 提前在 Node 节点导入镜像（docker load -i centos-7.9.2009-full.tar）；
  2. 检查镜像名称和标签（确保与docker images中的一致）。

问题 2：Pod 显示 Running 但 RESTARTS 持续增加

• 原因：存活探针配置错误（端口 / 路径不匹配），kubelet 判定容器异常并反复重启。
• 解决方案：
  1. 查看 Pod 日志（kubectl logs <pod-name> --previous），确认应用实际监听端口；
  2. 修正存活探针的 port/path，或临时注释探针（先保证 Pod 稳定）。

问题 3：Pod 状态 Running，但 Service 无法访问

• 原因：就绪探针失败，Pod 未被加入 Service 的 Endpoints。
• 解决方案：
  1. 检查就绪探针配置（确保与应用状态匹配）；
  2. 执行kubectl get endpoints <svc-name>，确认 Pod IP 已在列表中。

问题 4：Pod 终止时数据丢失

• 原因：未配置 preStop 钩子，容器被强制终止，未执行数据持久化逻辑。
• 解决方案：配置 preStop 钩子，执行数据备份、连接关闭等操作，预留足够的优雅退出时间（如 sleep 5）。