说实话，没有什么比在大半夜收到“Node NotReady”的报警geng让人心跳加速的了。尤其是当你面对的是一套架构略显陈旧、版本偏低的 Kubernetes 集群时这种感觉简直就像是在开一辆年久失修的老爷车在高速公路上狂飙——你永远不知道哪个零件会在下一秒罢工。

Zui近我就遇到了这么一个棘手的案子。背景是这样的：集群里频繁地进行 Pod 的创建与销毁，网络插件用的是 Calico，底层环境还混杂了 ARM64 架构，配合的 Docker 版本居然是 23.x。这种组合在低版本的 K8s 环境下简直就是一场灾难的预演。节点莫名其妙地卡死，常规的重启手段完全失效，那种无力感，相信各位运维兄弟dou懂。

今天我就把这次“生死救援”的完整复盘分享出来。我们不谈那些虚头巴脑的理论，直接上干货，kankan当 Docker 和 Kubelet 彻底“死锁”时我们该如何通过外科手术般的操作，把节点从鬼门关拉回来。

一、 现象还原：当“原子操作”变成死循环

一切的开始，通常dou伴随着一些kan似不起眼却又极其诡异的报错。Ru果你在日志里kan到下面这段话，那么恭喜你，你中招了。

Error  deleting object  retrying....

这行字kan着简单，背后的含义却让人头秃。这是 Docker 的网络 endpoint 或者对象数据库Calico 网络回收机制试图去修改某个 key，结果发现它Yi经被占用了或者状态不一致。

geng糟糕的是当你遇到 ARM64 架构加上 Docker 23 这种略显激进的组合时兼容性的坑会被无限放大。网络层直接陷入了死锁，就像早高峰的十字路口，红绿灯全坏，谁也动不了。这时候，你会发现不管怎么重试，网络资源就是无法释放，整个集群陷入了泥潭。

二、 深入病灶：Shim 进程的“僵尸化”

网络卡死只是表象，随之而来的往往是容器运行时的崩溃。这时候你去查 systemd 的日志，大概率会kan到这么一段：

docker.service: Unit process xxx  remains running after unit stopped.
This usually indicates unclean termination of a previous run

kan到没？Docker 明明Yi经执行了 stop 命令，但是 containerd-shim 这个进程却像是个顽固的钉子户，死活不肯走。这不仅仅是进程残留那么简单，这些所谓的“僵尸进程”会牢牢占用 CRI链路，甚至把命名空间和网络栈dou锁死。

这就导致了一个直接的恶果：当你试图重启 Docker 时之前的资源锁根本没有释放。所有的容器操作dou开始阻塞，Kubelet 调用 CRI 超时Zui终导致“容器运行时检测失败”，节点状态无可挽回地变成了 NotReady。这时候，简单的 `systemctl restart` Yi经没有任何意义了就像给一个断气的人Zuo心肺复苏，得先找到病因。

三、 绝地求生：强制清理挂载与进程

既然常规手段无效，那我们就得动用“非常规手段”了。这一步操作有点暴力，但为了恢复服务，我们必须狠下心来。我们的目标是：清理所有残留的挂载点，杀掉所有不听话的 shim 进程。

我们得处理那些因为容器异常而遗留下来的挂载点。Ru果你直接去删 Docker 的目录，系统一定会嘲笑你：

# rm -rf containers/ overlay2/
rm: cannot remove 'containers/xxx/mounts/shm': Device or resource busy

“Device or resource busy”，这报错太熟悉了。这是因为 `merged` 这个目录作为容器运行时的挂载点，还被内核死死抓着呢。这时候千万别硬删，硬删只会让文件系统状态geng乱。正确的姿势是使用 `umount` 命令，而且要加上 `-lf` 参数，也就是 lazy unmount，强制切断引用。

来执行下面这套组合拳，先把挂载点给卸了：

# 强制卸载所有挂载占用
umount -lf /var/lib/docker/containers/*/mounts/shm
umount -lf /var/lib/docker/overlay2/*/merged
# 批量强制卸载所有 kubelet 挂载
mount | grep kubelet | awk '{print $3}' | xargs -I {} umount -l {}

注意到了吗？这里我用 `awk '{print $3}'` 是为了精准定位挂载点目录，避免误伤。卸载完挂载点，接下来就是清理进程了。那些残留的 containerd-shim 和 runc 进程，必须一个不留地清除干净。

# 杀死残留 shim 与 runc 僵尸进程
ps -ef | grep -E 'containerd-shim|runc' | grep -v grep | awk '{print $2}' | xargs kill -9

这一步执行完，你会感觉整个世界dou清净了。那些赖着不走的进程终于被终结了。这时候，我们再尝试重启服务，成功率就会大大提升。

四、 常规重启流程：别急着高兴，按顺序来

虽然上面的清理操作hen解气，但还没到庆祝的时候。重启服务也是有讲究的，不Neng乱来。Ru果顺序不对，可Neng会导致资源 冲突。

建议按照以下步骤，稳扎稳打：

1. 先把所有容器停下来

不管容器是运行中还是Yi经停止了我们先发个停止信号，确保逻辑上的关闭：

docker stop $

2. 再删除所有容器

这一步是为了彻底清理 Docker 守护进程眼中的容器列表，为后续的重建扫清障碍：

docker rm $

3. Zui后重启 Docker 和 Kubelet

这时候再重启服务，就是顺理成章的事情了：

systemctl restart docker && systemctl restart kubelet

执行完这一套，稍微等个几十秒，再去 `kubectl get node` kankan。Ru果运气好，节点状态应该Yi经变回 Ready 了。Kubelet 会自动把之前删掉的容器重新拉起来虽然业务会有一瞬间的中断，但总比整个节点挂掉强吧？

五、 兜底方案：当一切手段dou失效时

当然运维的世界里总是充满了意外。有时候，情况比我们想象的还要糟糕。Ru果你发现上面的方法试了一遍又一遍，节点依然处于一种“半死不活”的状态，那就得祭出我们的终极兜底方案了。

这个方案的特征非常明显，当你的日志里反复出现以下核心异常点时就说明常规手段Yi经无效了：

cleaning up after shim disconnected

或者 Kubelet 一直在报错：

KubeletNotReady container runtime status check may not have completed yet

甚至：

Skipping pod synchronization err="container runtime status check failed"

这时候，别犹豫了直接进行彻底清理。所谓的彻底清理，就是强制删除所有容器、所有进程，不管它是不是还在运行。这有点像重装系统前的格式化，虽然听起来hen吓人，但在低版本 K8s 遇到这种死锁时这往往是唯一的出路。

建议直接执行：

systemctl restart docker && systemctl restart kubelet

等等，你可Neng会问，这不就是普通的重启吗？不这里的区别在于心态和前提。在使用兜底方案时我们默认之前的容器状态Yi经不可信了。kubelet 重启后会根据 Etcd 里的期望状态，强制在节点上重新拉起所有容器。这就相当于把节点上的运行时环境重置了一遍，虽然暴力，但有效。

六、 写在Zui后

处理低版本 K8s 的节点问题，从来dou不是一件优雅的事。我们就像是在废墟上重建城市，既要小心翼翼地处理残留的挂载点，又要果断地杀掉那些僵死的进程。ARM64 和 Docker 23 的兼容性坑，加上 Calico 网络的复杂性，让这一切变得geng加难缠。

但好消息是只要掌握了这套“清理挂载 -> 杀掉进程 -> 强制重启”的逻辑，绝大多数的卡死问题douNeng迎刃而解。希望这篇文章Neng帮到那些正在深夜里对着报错日志发愁的兄弟们。记住遇到问题别慌，先kan日志，再找挂载点，实在不行就重启，大不了重装，没什么过不去的坎。

---