容器cpu锁死本质是内核cgroup bug致进程被错误挂起或无限throttled而docker ps仍显示up；需通过cpu.max检查、线程状态分析及dmesg日志确认，临时重置配额或关闭throttling止血，并升级至已修复内核版本。
容器因宿主机内核 cgroup bug 导致 CPU 利用率突发性锁死，本质是内核在资源调度或状态同步环节出现竞态或逻辑缺陷，使容器进程被错误挂起、无限 throttled 或陷入不可中断睡眠（D 状态），但 docker ps 仍显示 Up —— 这不是应用问题，而是内核级资源控制器失能。
确认是否为内核 cgroup bug 触发
先排除配置和应用层干扰，聚焦内核行为异常：
- 检查容器 cgroup v2 的
cpu.max是否被意外重写为0 100000（即配额归零）：cat /sys/fs/cgroup/docker/<container-id>/cpu.max</container-id> - 查看该容器下所有线程状态：
ps -T -p $(docker inspect -f '{{.State.Pid}}' <container-name>) -o pid,tid,comm,state,%cpu --sort=-%cpu</container-name>，若大量线程卡在D或R+状态，且%cpu接近 0，高度可疑 - 查内核日志是否有 cgroup 相关报错：
dmesg -T | grep -i "cgroup\|throttle\|sched\|cpu\.max"，重点关注cfs_bandwidth_timer超时、cpu_cfs_throttled异常跳变等线索
临时止血：绕过故障 cgroup 控制路径
不重启容器、不杀进程，快速恢复 CPU 调度能力：
- 对容器所在 cgroup 目录，重置 CPU 配额为无限制（仅限紧急恢复）：
echo "max 100000" > /sys/fs/cgroup/docker/<container-id>/cpu.max</container-id> - 若使用 cgroups v1，可临时关闭 throttling：
echo 0 > /sys/fs/cgroup/cpu/docker/<container-id>*/cpu.cfs_quota_us</container-id> - 向容器主进程发送
SIGCONT（尤其当其处于T停止态时）：kill -CONT $(docker inspect -f '{{.State.Pid}}' <container-name>)</container-name>
规避与加固：降低内核 bug 触发概率
已知部分内核版本（如 5.10.0-1097-oem、4.19.232-1.el7）在高并发更新 cpu.max 时存在 race condition。建议：
- 禁用动态 CPU 限值调整：Kubernetes 中避免使用
topologyManagerPolicy: single-numa-node或cpuManagerPolicy: static配合频繁的 Pod 驱逐/重建 - 升级或降级内核：优先选用 LTS 内核中已明确修复 cgroup cpu controller 的版本（如 6.1.81+、5.15.148+），或回退至 5.4.231 等经大规模验证稳定的分支
- 容器启动时显式指定宽松配额，避免依赖 runtime 动态计算：
docker run --cpus=2.0 --cpu-quota=200000 --cpu-period=100000 ...
长期方案：启用 cgroup v2 + systemd 集成监控
cgroups v2 对控制器状态一致性更强，配合 systemd 可实现细粒度观测：
- 确保宿主机启用 cgroup v2：
cat /proc/cmdline | grep cgroup应含systemd.unified_cgroup_hierarchy=1 - 用
systemd-run启动容器并绑定 scope：systemd-run --scope --slice=docker.slice docker run ... - 实时观察 throttling 累计值：
systemctl show docker.slice --property=CPUAccounting,CPUUsageNSec,CPUThrottledTime
这类锁死通常不伴随 panic，但会持续恶化。关键是早识别、快隔离、稳版本。
