Kubernetes Pod 深入实战：生命周期、探针、资源与优雅终止

实验基线：Kubernetes v1.37.0、kubectl v1.37.0。先在测试环境执行，记录变更前状态与回滚点；生产集群不得直接照抄节点地址、网段、存储类或资源额度。

不要把 Pod Phase 当作应用健康

Running只表示 Pod 已绑定节点且至少一个容器已运行或启动中，不代表业务已可服务。应用健康要结合容器状态、Ready 条件、重启次数、探针和事件判断。

可验证的 Pod 清单

apiVersion: v1
kind: Pod
metadata:
  name: web
  namespace: lab
spec:
  terminationGracePeriodSeconds: 30
  containers:
  - name: web
    image: nginx:1.27-alpine
    ports:
    - containerPort: 80
    resources:
      requests: {cpu: 50m, memory: 32Mi}
      limits: {cpu: 200m, memory: 128Mi}
    startupProbe:
      httpGet: {path: /, port: 80}
      periodSeconds: 2
      failureThreshold: 30
    readinessProbe:
      httpGet: {path: /, port: 80}
      periodSeconds: 5
    livenessProbe:
      httpGet: {path: /, port: 80}
      periodSeconds: 10

startupProbe 成功前，其他两种探针不会干扰慢启动。readiness 失败只摘除流量；liveness 连续失败会重启容器。探针路径必须廉价且不依赖不可控的下游，否则会把局部故障放大为重启风暴。

观察与制造可控故障

kubectl apply -f pod.yaml
kubectl wait -n lab --for=condition=Ready pod/web --timeout=90s
kubectl get pod web -n lab -o jsonpath='{.status.containerStatuses[0].restartCount}'
kubectl describe pod web -n lab
kubectl exec -n lab web -- rm /usr/share/nginx/html/index.html
kubectl get pod web -n lab -w

删除首页后 readiness/liveness 会失败；观察事件与重启计数，再重建 Pod 恢复。生产应用还应处理 SIGTERM：先停止接收新流量，再在宽限期内结束请求。不要把 preStop: sleep当作真正的优雅关闭。

从 Conditions 读懂 Pod

排障时同时看 PodScheduled、Initialized、ContainersReady、Ready。PodScheduled=False 是调度问题；Initialized=False 多半是 init container；ContainersReady=False 看各容器状态；Ready=False 还可能由自定义 readiness gate 导致。

kubectl get pod web -n lab -o jsonpath='{range .status.conditions[*]}{.type}{"="}{.status}{" reason="}{.reason}{"\n"}{end}'
kubectl get pod web -n lab -o jsonpath='{range .status.containerStatuses[*]}{.name}{" waiting="}{.state.waiting.reason}{" terminated="}{.lastState.terminated.reason}{" restarts="}{.restartCount}{"\n"}{end}'

Init Container 与启动依赖

initContainers:
- name: wait-backend
  image: busybox:1.36
  command: ["sh","-c","until nslookup backend.lab.svc.cluster.local; do sleep 2; done"]

init container 串行执行，全部成功后主容器才启动。等待必须有明确超时或外部告警，否则错误依赖会让 Pod 永久 Init。不要把数据库迁移放到每个副本都会执行的 init container 中。

探针参数如何计算

允许失败窗口约等于 failureThreshold × periodSeconds，首次检查还受 initialDelaySeconds 影响。startupProbe 应覆盖最慢可信启动时间；readiness 要比客户端超时更快发现不可服务；liveness 只检测“重启能恢复”的故障。先用日志和指标确认阈值，再上线。

资源与 OOM 排查

kubectl top pod web -n lab --containers
kubectl describe pod web -n lab | sed -n '/Limits:/,/Conditions:/p'
kubectl get pod web -n lab -o jsonpath='{.status.containerStatuses[0].lastState.terminated.reason}'
kubectl get events -n lab --field-selector involvedObject.name=web

CPU 超限通常表现为 throttling，不会直接重启；内存超限会 OOMKill。Java 等运行时还要确保进程能识别容器限制。requests 依据稳定负载的高分位使用量设置，limits 需要结合突发和节点保护。

优雅终止实验

应用捕获 SIGTERM 并停止接收新请求。
readiness 尽快失败，使 Service 摘除端点。
在 terminationGracePeriodSeconds 内完成在途请求。
超过宽限期后 kubelet 才发送 SIGKILL。

kubectl delete pod web -n lab --grace-period=30
kubectl get pod web -n lab -w
kubectl get endpointslice -n lab -l kubernetes.io/service-name=web -w

验收要同时观察 Pod 终止时间、端点摘除和客户端错误率，而不是只看 Pod 消失。

可复现记录模板

每次实验记录：集群版本、容器运行时、CNI/CSI 版本、命名空间、使用的 YAML Git 提交、开始与结束时间。命令输出至少保留对象状态、事件、关键日志和回滚结果。文中的占位符必须替换成自己的值，生产执行前应由第二人复核。

故障处理原则

先缩小影响面，不删除现场。
按对象状态—事件—日志—依赖顺序收集证据。
提出可证伪假设，一次只改变一个变量。
验证恢复后清理临时权限、调试 Pod、端口转发和测试数据。

完成检查

命令退出码为 0，目标对象状态与预期一致。
保存执行前后 YAML、事件与关键日志，确认没有把测试命名空间以外的对象改动。
故障演练完成后执行清理或回滚，再进行下一章。