新容器继承了 Started

容器因 liveness 失败而重启，新容器还没通过 startupProbe，liveness 却已经执行。先对齐新旧 containerID 与 started 状态：Kubernetes 1.36.1、1.36.2 的一个回归会把旧实例的启动状态带给同名新实例。

启动状态属于实例

正常规则是有 startup probe 时，liveness 和 readiness 等到它成功才开始。受影响路径为了在 kubelet 重启后保留状态，按容器名称继承旧 Started，却没有确认新旧 containerID 相同。

当旧实例已启动、新实例刚创建时，这个继承会短暂让探测器把新实例也视为已启动。随后探测结果初始化可能纠正状态，所以只查询一次看到 started=false，不能排除此前已经跑过 liveness。

记录同一个 Pod UID 下的容器 ID 变化、启动时间和实际探测日志，判断是不是这个先后顺序。普通启动耗时超过阈值、健康接口写错，仍是其他原因。节点上的 kubelet 版本和相关特性门也要核对，不能只看 kubectl 版本。

修的是 kubelet 的身份判断

代码修复要求仅在新旧 ID 相同时保留 Started，新实例必须通过自己的 startup probe。主线修复已合并，但截至 2026 年 10 月 14 日，核对的 1.37.1 标签仍没有该检查，旧分支回移请求也不能当成已经发布的修复。

采用节点发行版或补丁版本前，确认它确实包含这项身份判断，按原节点升级与版本相容约定更新 kubelet。仅升级命令行客户端不会更换节点的状态处理代码。

暂时恢复不等于修复回归

业务必须恢复、且工作负载允许安全替换时，可通过已有控制器做受控的 Pod 替换。新 Pod UID 没有旧 Pod 那份容器状态，可以避开这一次继承；但之后若再发生容器内重启，旧版本仍可能重现问题。

替换前需要确认副本可用性和状态存放位置。新 Pod 可能重新调度，emptyDir 内容会失去，单实例也会中断；不能为了重置状态反复强删 Pod，更不能把有状态业务当无状态样例处理。

增加 liveness 的初始延迟可能减少命中窗口，却没有修正状态身份。关闭全部探测则会改变故障恢复和流量保护，也不能作为这项回归的正式处理。

验收修复时，在隔离工作负载触发一次已知 liveness 重启，确认新实例在自己的 startup 成功前保持未启动，且 liveness、readiness 没有提前运行。同时检查真正启动成功和启动失败的情况，不能只以重启次数没有继续增加作为成功标准。仅含 readiness、同时经历 kubelet 与 API 状态滞后的另一类问题，需要另行核对。