Kubernetes Pod 重启和容器重启怎样区分排查

先给结论：同一个 Pod 里的容器可以重启，但这不等于 Pod 对象被重建。判断时不要只看列表里的 Running、CrashLoopBackOff 或 READY 列，而要把 Pod UID、创建时间和每个容器的 restartCount 放在一起看。Pod UID 没变、容器重启次数增加，通常是容器级问题；Pod UID 变了，才说明当前对象已经不是原来的 Pod。

官方地址：https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/

我排查这类问题时，会先把“对象身份”和“容器状态”分开，再决定看日志还是看控制器事件。这样可以避免把一次应用崩溃，误判成调度、滚动更新或节点故障。

先分清 Pod 对象和容器实例

Pod 是 Kubernetes API 中的对象，也是一个或多个容器共享网络和存储上下文的运行环境；它不是一个可以直接重启的单一进程。容器退出后，kubelet 可以按照 restartPolicy 在同一个 Pod中创建新的容器实例。此时 Pod 名称和 UID 通常仍然保持不变，但容器的启动时间、容器 ID 和 restartCount 会变化。

相反，Deployment 滚动更新、Pod 被驱逐、节点失联后由控制器补建副本等场景，往往会产生新的 Pod 对象。新 Pod 可能沿用相同的标签和控制器引用，但 UID、创建时间通常不同。日常口语里的“Pod 重启”，需要先确认它究竟指的是容器重启，还是旧 Pod 被删除后出现了替代 Pod。

第一步：先确认当前 Pod 还是不是原来的对象

下面的命令只读取状态，不会修改集群。先记录名称、UID、创建时间、节点和控制器引用，再去看容器状态。

# 先记录对象身份，便于和告警或上一次采集结果比较
kubectl get pod POD_NAME -n NAMESPACE \
  -o jsonpath='{.metadata.name}{"\n"}{.metadata.uid}{"\n"}{.metadata.creationTimestamp}{"\n"}{.spec.nodeName}{"\n"}'

# 查看它由哪个控制器管理，避免把控制器补建误认为 kubelet 重启
kubectl get pod POD_NAME -n NAMESPACE \
  -o jsonpath='{range .metadata.ownerReferences[*]}{.kind}{"/"}{.name}{"\n"}{end}'

如果两次采集的 UID 一样，优先按“同一个 Pod 内的容器重启”排查；如果 UID 不一样，先沿着 Deployment、StatefulSet、Job 或其他 owner 的变更和事件追踪。节点变化也是线索，但不能单独作为“Pod 被重建”的证据：同一个 Pod 通常不会在节点之间直接搬迁，真正的结论仍应以对象 UID 和控制器记录为准。

第二步：按容器读取 restartCount 和上一次终止信息

kubectl describe pod 会把每个容器的状态、就绪情况、重启次数和事件放在一起；排查多容器 Pod 时，不能只盯着主容器。容器状态常见为 Waiting、Running 或 Terminated，而 lastState.terminated 保存着上一轮终止的原因、退出码和时间。

# 先看每个容器的当前状态、上一次终止原因和累计重启次数
kubectl get pod POD_NAME -n NAMESPACE -o json \
  | jq '.status.containerStatuses[] | {
      name,
      restartCount,
      state,
      lastState
    }'

# describe 同时显示容器状态和按时间排列的事件
kubectl describe pod POD_NAME -n NAMESPACE

重点看这几组组合：

• restartCount 增加，Pod UID 不变：优先检查进程退出、探针失败、内存限制或配置读取失败。
• lastState.terminated.exitCode 非零：说明上一次容器实例以失败状态结束，但退出码仍需结合应用日志解释。
• 状态显示 CrashLoopBackOff：它描述的是容器反复失败后的退避状态，不等价于 Pod 对象已换新。
• 多个容器中只有一个的 restartCount 增长：先查该容器以及它依赖的共享卷、探针和 sidecar 关系。

第三步：用上一轮日志和事件补齐原因

如果容器刚刚被替换，当前日志可能只显示新实例已经启动。对仍保留上一轮日志的容器，可以使用 --previous 读取前一个实例的输出；多容器 Pod 要显式指定 -c，否则很容易看错容器。

# 读取指定容器上一个实例的日志，定位退出前最后一段输出
kubectl logs POD_NAME -n NAMESPACE -c CONTAINER_NAME --previous

# 只筛选最近事件，重点观察 BackOff、Killing、Unhealthy、Evicted 等线索
kubectl get events -n NAMESPACE \
  --field-selector involvedObject.name=POD_NAME \
  --sort-by='.lastTimestamp'

日志负责解释“应用在退出前做了什么”，lastState 负责说明“容器以什么状态结束”，事件负责补充“kubelet、调度器或控制器观察到了什么”。三者不一定都存在：日志可能已被轮换，事件也可能过期，所以要把采集动作尽量放在发现重启之后。

第四步：当 UID 变化时沿着控制器排查

确认 UID 已变化后，不要继续在旧 Pod 的 restartCount 上消耗时间。此时问题转到“谁创建了新 Pod、为什么旧 Pod 消失”。先看 owner 引用，再查看控制器的状态和同一时间段的事件：

# 查看控制器引用和当前 Pod 的关键时间点
kubectl get pod POD_NAME -n NAMESPACE -o json \
  | jq '{uid: .metadata.uid,
         created: .metadata.creationTimestamp,
         owners: .metadata.ownerReferences,
         node: .spec.nodeName,
         phase: .status.phase}'

# 按控制器类型选择只读检查入口；不要把占位名称原样复制到生产命令
kubectl describe deployment DEPLOYMENT_NAME -n NAMESPACE
kubectl describe statefulset STATEFULSET_NAME -n NAMESPACE

如果事件出现 Evicted、节点不可用、滚动更新或镜像拉取相关原因，应回到对应控制器、节点和资源配置继续查；如果只是同一 UID 下的容器失败，则回到上一节的容器日志、探针和退出码。二者的修复责任边界不同，混在一起会让排查记录失去可复用性。

一张表做最后判断

常见问题

看到 CrashLoopBackOff 就是 Pod 重启吗？

不是。它通常表示某个容器不断退出，kubelet 正在按退避策略等待下一次启动。先比较 Pod UID；UID 不变时，应按容器重启排查。

为什么当前日志里没有崩溃前的错误？

当前日志属于新的容器实例。可以在日志仍被保留时用 kubectl logs --previous 读取上一实例；如果已经轮换或容器从未成功启动，则需要结合 lastState 和事件。

最后记住一个顺序：先比 UID，再看 restartCount；再看 lastState 和上一轮日志，最后沿控制器和事件追踪 Pod 替换原因。