📚 课程目录第3章 Pod基础与生命周期

3、Pod基础与生命周期：Pod定义、Init容器、静态Pod、Pod生命周期阶段与重启策略

3.1 Pod 定义：Kubernetes 最小调度单元

Pod 是 Kubernetes 中可创建和部署的最小计算单元，代表集群上运行的一个进程。一个 Pod 封装一个或多个容器（通常为一个主容器），共享存储网络和运行容器的规范。在平台工程值班场景中，Pod 是故障排查的第一入口。

  值班要点： 80% 的应用故障首先表现为 Pod 状态异常。掌握 Pod 定义字段是定位问题的基本功。

3.1.1 核心 Pod YAML 定义

apiVersion: v1
kind: Pod
metadata:
  name: web-app-pod
  labels:
    app: web
    tier: frontend
spec:
  containers:
  - name: nginx-container
    image: nginx:1.25
    ports:
    - containerPort: 80
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
    livenessProbe:
      httpGet:
        path: /healthz
        port: 80
      initialDelaySeconds: 3
      periodSeconds: 5
  restartPolicy: Always

3.1.2 Pod 定义关键字段速查表

字段路径	说明	值班常见问题
`metadata.name`	Pod 名称，集群内唯一	命名冲突导致创建失败
`metadata.labels`	标签，用于 Service/Deployment 选择	标签不匹配导致流量不通
`spec.containers[].image`	容器镜像地址	镜像拉取失败（ImagePullBackOff）
`spec.containers[].resources`	资源请求与限制	OOMKilled 或 CPU 节流
`spec.restartPolicy`	重启策略	CrashLoopBackOff 循环

3.2 Init 容器：前置依赖初始化

Init 容器是一种专用容器，在主容器启动之前运行，用于完成初始化任务（如等待数据库就绪、初始化配置文件、执行数据迁移）。Init 容器按顺序依次执行，只有所有 Init 容器成功退出后，主容器才会启动。

最佳实践： 使用 Init 容器替代应用代码中的启动等待逻辑，使主容器镜像保持简洁，且初始化失败时可被 Kubernetes 自动重试。

3.2.1 Init 容器 YAML 示例

apiVersion: v1
kind: Pod
metadata:
  name: init-demo
spec:
  initContainers:
  - name: init-myservice
    image: busybox:1.28
    command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
  - name: init-mydb
    image: busybox:1.28
    command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']
  containers:
  - name: main-app
    image: nginx:1.25
    ports:
    - containerPort: 80

3.2.2 Init 容器与主容器对比

特性	Init 容器	主容器
启动顺序	按定义顺序依次执行	所有 Init 容器成功后启动
重启行为	失败后按 Pod 重启策略重试	受 restartPolicy 控制
资源限制	支持 resources 字段	支持 resources 字段
存活/就绪探针	不支持	支持
生命周期钩子	不支持	支持 postStart/preStop

3.3 静态 Pod：由 kubelet 直接管理的特殊 Pod

静态 Pod 不由 API Server 控制，而是由 kubelet 直接通过读取指定目录下的 Pod 清单文件来管理。静态 Pod 常用于运行控制平面组件（如 kube-apiserver、etcd）或集群关键基础设施。

值班注意： 静态 Pod 的名称会自动附加所在节点名称后缀。无法通过 kubectl delete 删除静态 Pod，只能删除对应清单文件。

3.3.1 静态 Pod 工作机制

清单路径： kubelet 通过 --pod-manifest-path 或 --config 指定静态 Pod 目录（通常为 /etc/kubernetes/manifests）。
自动创建： kubelet 定期扫描目录，将 YAML/JSON 文件自动创建为 Pod。
镜像 Pod： API Server 上会生成一个只读的镜像 Pod，名称格式为 <static-pod-name>-<node-name>。
删除方式： 从清单目录中移除文件，kubelet 自动删除对应 Pod。

3.4 Pod 生命周期阶段

Pod 从创建到终止经历一系列状态阶段。值班工程师通过 kubectl get pods 看到的 STATUS 列即 Pod 生命周期阶段。

3.4.1 Pod 生命周期阶段详解

阶段	状态值	说明	值班处理建议
Pending	Pending	Pod 已被接受，但容器尚未全部创建（调度中或镜像拉取中）	检查调度事件：`kubectl describe pod`
Running	Running	至少一个容器正在运行或正在启动/重启	正常状态，关注资源使用率
Succeeded	Completed	所有容器成功退出且不再重启（Job 场景）	确认任务日志
Failed	Error/CrashLoopBackOff	至少一个容器以非零状态退出	查看日志：`kubectl logs --previous`
Unknown	Unknown	无法获取 Pod 状态（节点通信故障）	检查节点健康：`kubectl get nodes`

3.4.2 Pod 生命周期状态机

3.5 重启策略：控制容器故障后的行为

Pod 的 spec.restartPolicy 决定容器退出后 kubelet 如何处理。重启策略作用于 Pod 内的所有容器，适用于主容器和 Init 容器。

3.5.1 三种重启策略对比

策略	行为	适用场景	退出码影响
`Always`	容器退出后总是重启（默认策略）	长期运行的服务（Web、API）	无论退出码，均重启
`OnFailure`	仅当容器以非零退出码退出时重启	批处理任务、数据迁移	0 退出不重启，非 0 退出重启
`Never`	容器退出后从不重启	一次性 Job、测试 Pod	无论退出码，均不重启

3.5.2 重启退避机制（CrashLoopBackOff）

当容器反复崩溃时，kubelet 会应用指数退避延迟：第一次重启立即执行，后续延迟为 10s、20s、40s、80s、160s，最大 300s。延迟在容器成功运行超过 10 分钟后重置。

  值班排查命令：

  kubectl describe pod <pod-name> — 查看 Last State 和 Restart Count

  kubectl logs <pod-name> --previous — 查看崩溃前容器日志

  kubectl get events --field-selector involvedObject.name=<pod-name> — 查看 Pod 事件

3.6 值班核验清单：Pod 生命周期排查

检查 Pod 状态： kubectl get pods -o wide 查看 STATUS 和 NODE。
查看详细事件： kubectl describe pod <name> 关注 Events 段。
检查容器日志： kubectl logs <name> -c <container> 定位应用错误。
确认重启策略： 检查 restartPolicy 是否符合预期。
验证 Init 容器： kubectl get pod <name> -o jsonpath='{.status.initContainerStatuses}'。
静态 Pod 定位： 检查 /etc/kubernetes/manifests/ 目录是否存在对应清单。