CPU softlockup（软锁定）

CPU softlockup（软锁定）是 Linux 内核 watchdog 机制报出的“某颗 vCPU 在内核态连续 20 s（默认）没有发生任务切换”的异常。
本质是：内核线程/中断上下文长时间关抢占（或死循环），导致该核上的 watchdog 线程得不到调度，从而在日志里打印

watchdog: BUG: soft lockup - CPU#X stuck for 22s! [process:PID]

 

一、对 K8s 与 etcd 的直接影响

1. kubelet 卡死：
   • 无法按时向 apiserver 发送心跳 → 节点被标记为 NotReady，触发 Pod 驱逐。
2. etcd 卡死：
   • 它的 raft goroutine 若正好落在受害 CPU，会因 20 s 内无磁盘 I/O 或网络回应而被同伴视为“失联”，触发新一轮 leader 选举，造成 etcd 主从频繁切换；严重时整个 apiserver 出现 5xx，集群控制面抖动。
3. 容器运行时（containerd/docker）同样可能因 runc 卡住而无法创建/销毁容器，Pod 一直 ContainerCreating 或 Terminating。

二、常见根因（结合近期案例）

• 内核模块死循环或自旋锁长期未释放

   

  ；
• cgroup 读取路径（kubelet 统计内存/CPU 用量）在 5.10 以下内核有已知锁竞争，64 核以上机器极易触发；
• 驱动 bug、IPI 风暴、过量 iptables 规则导致 softirq 占用过高

   

  ；
• 虚拟机场景下宿主机过载，vCPU 被抢占，Guest 侧看就是“softlockup”。

三、快速止血与后续规避

1. 立即恢复
   • 登录节点 echo 3 >/proc/sys/vm/drop_caches 清缓存，减少 cgroup 遍历量；
   • 若 repeatable，可临时 echo 30 >/proc/sys/kernel/watchdog_thresh 把阈值放宽到 30 s，避免立刻 panic。
2. 根因处理
   • 升级内核 ≥ 5.10.134（官方修复了大量 cgroup 锁竞争）；
   • 给 kubelet 加参数 --housekeeping-interval=30s --cgroups-per-qos=false 降低扫描频率；
   • 检查是否有过多的 iptables 规则/内核模块（nf_conntrack 等），按需精简；
   • 对 VM 节点，确保宿主机不超载，开启硬件辅助虚拟化特性。
3. 监控
   • 对 /var/log/messages 或 journalctl -k 做日志告警：watchdog.*soft lockup；
   • 通过 node_exporter + Prometheus 监控 node_softlockup_seconds（需自己写脚本解析 dmesg）。

只要出现 softlockup，该节点上所有需要时间片及时响应的组件（kubelet、etcd、容器运行时）都会连带受害，因此务必把内核版本、驱动、系统负载控制在官方建议区间内，才能彻底消除 etcd 因“假死”而频繁重新选主的问题。

这就是 cgroup 锁竞争 → softlockup → etcd/kubelet 被误认为宕机 → 主从频繁切换。

一句话：

64 核以上机器，老内核 + 万级 cgroup，并发抢“一把大锁”，把 CPU 憋死，表现为 softlockup，连带拖垮 etcd 选主。