Kubernetes 1.35 中 Pod 重启语义有哪些常见误解

Kubernetes 1.35 讨论“Pod 重启”时，最容易犯的错误是把四种不同动作叫成同一个名字：容器进程在原 Pod 内重启、控制器删除并创建新 Pod、资源原地调整，以及 1.35 新增的原地重启全部容器。它们对 Pod UID、IP、卷、sandbox 和 restartCount 的影响并不相同，值班判断不能只看 Pod 名称。

最稳妥的第一判断是看 Pod UID：UID 不变而 restartCount 增加，通常是同一 Pod 内的容器重启；UID 变化，则是新 Pod 对象。Kubernetes 1.35 的原地全容器重启仍保留 UID，不能称为 Pod 重建。

Kubernetes 1.35 生命周期文档：https://v1-35.docs.kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/

CNCF 维护者文章：https://www.cncf.io/blog/2026/03/17/when-kubernetes-restarts-your-pod-and-when-it-doesnt/

判断重启首先要保住哪些身份信号

运维记录中至少要同时保存 Pod 名称、UID、IP、节点、各容器的 restartCount 与事件。名称不是可靠身份：StatefulSet 重建后可以继续使用同一个序号名称，Deployment 的新 Pod 名称也可能看起来相近，但 UID 才是 Kubernetes 对象身份。

同一 Pod 内重启容器时，Pod 对象、UID、IP 和大多数 Pod 级资源保持不变；控制器替换 Pod 时，新对象获得新 UID，调度、网络与启动序列重新进行。1.35 的原地全容器重启介于两者之间：所有容器重新启动，但 Pod 身份和关键资源被保留。

误解一：restartPolicy 会重建 Pod

spec.restartPolicy 控制的是 Pod 内容器终止后的处理方式，不是让 kubelet 删除并重建 Pod。Always 在任何退出后重启容器，OnFailure 只在非零退出码时重启，Never 不自动重启。kubelet 执行这类重启时，替换的是同一 Pod、同一节点里的容器实例。

因此 CrashLoopBackOff 的典型信号是 UID 不变、容器 restartCount 持续增加，并伴随指数退避。它不是控制器不断创建新 Pod。若只看名称和 Ready 状态，很容易把根因错误归到 Deployment 滚动更新。

误解二：配置变化都会触发重启

更新 ConfigMap 或 Secret 不等于更改已有 Pod 的 spec。通过环境变量注入的值在进程启动时确定，更新来源对象后，旧进程不会自动获得新值，也不会自动重启。要让环境变量变化生效，通常需要控制器执行一次 rollout，创建新 Pod。

以 volume 方式挂载的 ConfigMap 或 Secret 则可能由 kubelet同步到挂载目录，但文件更新本身仍不会自动重启应用。应用是否热加载，取决于它有没有正确监听目录变化并重新读取配置。路由规则、NetworkPolicy、Service 端口或 RBAC 等控制面变化也各有自己的下发路径，不能统一推断为“Pod 会重启”。

这类误判的风险在于：配置已经更新，但进程仍使用旧环境变量；或者文件已经更新，应用却没有重新加载。防护措施不是盲目执行重启，而是明确配置消费方式，并为热加载成功或 rollout 完成建立可观测信号。

误解三：滚动更新就是同一个 Pod 重启

Deployment 的滚动更新会创建新的 ReplicaSet 和新 Pod，再逐步终止旧 Pod。这是对象替换，不是同一 Pod 内的容器重启。新 Pod 的 UID 会变化，restartCount 从新对象重新统计；一次成功滚动更新完全可能看到“新 Pod restartCount 为 0”。

StatefulSet 保留序号名称和 PVC 绑定，也不意味着 Pod 对象始终不变。Pod 被删除后重新创建，名称可以仍是 worker-0，但 UID 已经变化。把“稳定网络身份”理解为“同一 Pod 从未重建”，会污染可用性和故障统计。

Kubernetes 1.35 的容器级规则不是全 Pod 重启

Kubernetes 1.35 将 ContainerRestartRules 推进到 Beta，并默认启用。它允许普通应用容器和普通 init 容器设置自己的 restartPolicy 与 restartPolicyRules，覆盖 Pod 级策略。规则按顺序匹配退出码；第一个匹配项执行动作，没有规则命中时再回退到容器自己的策略。

这仍是“按容器决定是否重启”。例如 Pod 级策略为 Never，某个容器仍可只在退出码 42 时原地重启：

apiVersion: v1
kind: Pod
metadata:
  name: restart-on-exit-code
spec:
  restartPolicy: Never # Pod 级默认不重启容器
  containers:
    - name: worker
      image: registry.k8s.io/busybox:1.27.2
      command: ["sh", "-c", "sleep 60; exit 42"]
      restartPolicy: Never # 未命中规则时回退到 Never
      restartPolicyRules:
        - action: Restart
          exitCodes:
            operator: In
            values: [42] # 只有可重试退出码才重启这个容器

原生 Sidecar 是 initContainers 中设置了容器级 restartPolicy: Always 的容器，它不遵循 Pod 级 restartPolicy。把 Sidecar 当成普通 init 容器，也会导致完成条件和重启判断错误。

原地重启全部容器也不等于重建 Pod

Kubernetes 1.35 还提供 RestartAllContainers 动作，用于在某个容器退出码命中规则时，让 kubelet 原地终止并重新启动 Pod 内全部容器。它由 RestartAllContainersOnContainerExits 特性门控控制，在 1.35 中是 Alpha，默认关闭，不能因为集群已经升级到 1.35 就假定可直接使用。

这项机制保留 Pod UID、IP、网络命名空间、sandbox、已挂载设备和卷，包括 emptyDir 与 PVC。随后 init 容器重新按顺序执行，Sidecar 和普通容器再次启动。也就是说，它实现的是“同一 Pod 身份上的完整启动序列”，而不是删除旧对象再调度新对象。

代价同样需要明确：官方 v1.35 生命周期文档说明，这类快速终止不遵守 terminationGracePeriodSeconds，也不会执行 preStop。应用必须能够处理突然终止，初始化动作必须可重入，外部系统也要能接受 init 容器再次执行。否则所谓快速恢复可能放大重复写入、锁未释放或外部资源泄漏。

用审计记录而不是口头描述定位动作

下面三组命令足以建立最小证据链。第一组记录对象身份与重启计数，第二组看事件，第三组检查实际策略。每个命令都应在变更前后各执行一次，并把结果关联到同一时间窗口。

# 记录 Pod 身份、IP 与每个容器的重启计数
kubectl get pod my-pod -n my-namespace -o custom-columns='NAME:.metadata.name,UID:.metadata.uid,IP:.status.podIP,RESTARTS:.status.containerStatuses[*].restartCount'

# 查看 kubelet、调度与控制器留下的事件证据
kubectl describe pod my-pod -n my-namespace

# 核对 Pod 级策略、容器级规则和当前状态
kubectl get pod my-pod -n my-namespace -o yaml

• UID 不变、某个 restartCount 增加：优先判断为同一 Pod 内的容器重启。
• UID 变化、restartCount 从新对象重新统计：判断为 Pod 重建或控制器替换。
• UID 与 IP 不变、所有相关容器重启且 init 再次执行：再结合特性门控和 Pod 条件判断是否触发原地全容器重启。
• 配置值变化但 UID、restartCount 都不变：检查应用是否采用热加载，不要先假定 kubelet 漏掉了重启。

上线前验证清单

• 先确认集群和节点确实运行 Kubernetes 1.35，并分别核对 Beta 与 Alpha 特性门控状态。
• 为告警同时采集 Pod UID、节点、IP、容器名、退出码、restartCount 和事件，避免只写“Pod 重启”。
• 区分普通 init 容器、原生 Sidecar 与普通应用容器的策略来源。
• 使用 restartPolicyRules 时，为未命中规则的回退策略写清预期。
• 试用 RestartAllContainers 前，验证初始化可重入、重复写入安全，并确认应用不依赖 preStop 完成关键清理。
• 滚动更新、节点驱逐、镜像拉取失败与 CrashLoopBackOff 分别建立独立运行手册，不共用模糊的“重启失败”告警。

常见问题

Pod 名字没变，能证明没有重建吗？

不能。StatefulSet 可以重建同名 Pod。应比较 metadata.uid，而不是只看名称。

restartCount 为 0，能证明没有发生过替换吗？

不能。新 Pod 对象的计数重新开始，滚动更新后看到 0 很正常。应同时检查 UID、创建时间和控制器事件。

1.35 的 RestartAllContainers 可以直接用于生产吗？

它在 1.35 中仍是 Alpha 且默认关闭，应先在隔离环境验证特性门控、可重入性、突然终止与观测兼容，再决定是否采用。

结语

Kubernetes 1.35 没有让“Pod 重启”变成一个更宽泛的万能词，反而要求运维把语义分得更细：容器级规则解决单容器退出后的动作，原地全容器重启解决保留 Pod 身份时的整体复位，控制器重建则生成新对象。把 UID 放在判断入口，再结合 restartCount、事件与策略字段，才能让告警、复盘和自动化处理指向真正发生的生命周期动作。