cgroup残留引发软死锁本质是旧目录未清理导致新容器复用异常状态，表现为节点负载飙升、Pod无法就绪、kubelet失联但docker ps显示Running；需通过dmesg日志、/sys/fs/cgroup残留目录检查及cgroup挂载点对比确认，并手动卸载、强制删除后重建。
在K8s集群中，Docker容器因底层cgroup残留引发软死锁，本质是旧cgroup目录未清理干净，导致新容器启动时复用异常状态（如freezer冻结、kmem泄漏、devices黑名单残留），内核在资源分配或进程调度阶段卡在不可中断等待（D状态），表现为节点负载飙升、Pod无法就绪、kubelet失联，但docker ps仍显示Running——这是典型的“伪运行”。
确认是否为cgroup残留导致的软死锁
先排除硬件、驱动等干扰因素，聚焦cgroup层：
- 检查节点dmesg日志是否有
SLUB: Unable to allocate memory on node -1或freezer.state: write failed类报错 - 进入
/sys/fs/cgroup/，执行find . -name "*<container-id>*" -type d | head -10</container-id>，若发现大量残留目录（尤其含freezer或devices子系统路径），说明cgroup未被containerd/docker彻底释放 - 对比
cat /proc/$(pgrep kubelet)/cgroup与cat /proc/$(pgrep dockerd)/cgroup，若两者挂载点混杂或嵌套过深（如多次出现system.slice/docker-xxx.scope），表明cgroup树污染
清理顽固cgroup残留目录
不能仅靠docker system prune，需手动干预内核视图：
- 停止相关服务：
systemctl stop kubelet docker containerd - 卸载所有cgroup子系统挂载点：
umount $(grep cgroup /proc/mounts | awk '{print $2}') 2>/dev/null || true - 强制删除残留目录：
rm -rf /sys/fs/cgroup/*/docker-* /sys/fs/cgroup/*/kubepods-*（注意：确保无正在运行的关键容器） - 重新挂载cgroup v1（若使用）：
mkdir -p /sys/fs/cgroup/{cpu,cpuacct,memory,devices,freezer} && mount -t cgroup -o cpu,cpuacct none /sys/fs/cgroup/cpu,cpuacct等
禁用高风险cgroup特性防止复发
某些内核版本（如CentOS 7 + kernel 3.10）的kmem account存在内存泄露，会逐步耗尽slab缓存，最终触发软死锁：
- 检查是否启用：
zcat /proc/config.gz | grep CONFIG_MEMCG_KMEM（若为y或m，即开启） - 临时关闭：
echo 0 > /sys/fs/cgroup/memory/memory.kmem.limit_in_bytes（需cgroup v1） - 永久禁用：在
/etc/default/grub中添加cgroup_enable=memory swapaccount=1 kmem=0，再grubby --update-kernel=ALL --args="..." && reboot - 对麒麟V10等定制系统，还需补加
cgroup_enable=cpu参数，否则freezer等子系统初始化失败
加固容器运行时配置
避免新容器再次陷入同类问题：
- 升级containerd至v1.7+，启用
systemd_cgroup = true并配合unified_cgroup_hierarchy=1（cgroup v2），减少子系统冲突 - 在
/etc/containerd/config.toml中设置[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]，添加SystemdCgroup = true - K8s层面，为Node设置
node.kubernetes.io/not-ready:NoExecute容忍，并配置pod-eviction-timeout缩短异常节点影响窗口
