K8s 滚动更新时老 Pod 卡 Terminating 5 分钟才被 SIGKILL，describe 看不出原因，该按什么顺序排查？

背景 我做了 15 年运维，最近团队一个 3 副本的 Java 业务（K8s 1.28.9，containerd 1.7.13，cgroup v2）做 rolling update 时翻车：老 Pod 卡在 Terminating 状态整整 5 分 12 秒才被 SIGKILL，期间 readiness 已经摘除，但 LB 侧还有 30 秒左右的 502 尾巴（客户端重试放大）。新 Pod 正常起来，业务最终没丢数据，但每次发布都这样，运维窗口被拖长。

现象

• kubectl get pod 显示老 Pod Terminating，READY 0/1，RESTARTS 不变
• kubectl describe pod 里 Events 只有一条 Stopping container，再往下没了
• kubectl get events --sort-by=.lastTimestamp 也看不到 Killing container 或 Container terminated 事件
• 容器日志在卡住期间是空的（进程已收到 SIGTERM 但还没退出）
• 节点 dmesg 没有 OOM，journalctl -u kubelet 里能看到 Stopping container 但看不到后续
• crictl ps -a 能看到容器状态是 Exited，但 Pod 对象还挂着

已尝试的排查

1. terminationGracePeriodSeconds 默认 30s，没改过；preStop hook 没配
2. 检查 finalizers：kubectl get pod -o yaml | grep finalizers 只有默认的 kubernetes.io/pod
3. 抓 kubelet 日志（--v=4），看到 Stopping container 后卡了约 4 分多钟，然后才 Killing container——说明卡点在 kubelet → containerd 的 ContainerStop RPC 这一跳，但 containerd 侧 journalctl -u containerd 里对应时间段是空的
4. 怀疑是 CNI 网络清理或 volume unmount 卡，但这个 Pod 没有挂载任何 PVC，CNI 是 Calico
5. 重启 kubelet 能立刻解开，但生产不敢这么干

期望得到的答案形态 希望各位能给一份有序的排查清单，至少覆盖：

• 哪些命令/字段/日志位置能直接定位"卡在 kubelet→containerd 这一跳"还是"卡在 CNI/volume 这一跳"
• 每个常见卡点（containerd shim 卡、CNI 网卡清理卡、volume unmount 卡、finalizer 卡、kubelet PLEG 卡）的典型特征（哪个日志行、哪个字段、哪个 crictl/ctr 命令能看到）
• 生产环境遇到这种卡住，应急动作该怎么做：是 kubectl delete pod --force --grace-period=0 直接强删，还是先 crictl stop 容器、还是重启 kubelet？各自的副作用是什么？
• 有没有预防性配置（比如 kubelet 的 --container-runtime-timeout、containerd 的 shutdown_timeout）能兜底？

我倾向认为这是 containerd shim 的僵尸进程问题，但没拿到 containerd 侧的对应日志，没法坐实。想听听大家生产里踩过的坑，以及你们怎么定位的。