CPU softlockup（软锁定）是 Linux 内核 watchdog 机制报出的“某颗 vCPU 在内核态连续 20 s（默认）没有发生任务切换”的异常。
本质是：内核线程/中断上下文长时间关抢占（或死循环），导致该核上的 watchdog 线程得不到调度，从而在日志里打印
本质是：内核线程/中断上下文长时间关抢占（或死循环），导致该核上的 watchdog 线程得不到调度，从而在日志里打印
watchdog: BUG: soft lockup - CPU#X stuck for 22s! [process:PID]
一、对 K8s 与 etcd 的直接影响
-
kubelet 卡死：
-
无法按时向 apiserver 发送心跳 → 节点被标记为
NotReady，触发 Pod 驱逐。
-
-
etcd 卡死：
-
它的 raft goroutine 若正好落在受害 CPU，会因 20 s 内无磁盘 I/O 或网络回应而被同伴视为“失联”，触发新一轮 leader 选举，造成 etcd 主从频繁切换；严重时整个 apiserver 出现 5xx，集群控制面抖动。
-
-
容器运行时（containerd/docker）同样可能因 runc 卡住而无法创建/销毁容器，Pod 一直
ContainerCreating或Terminating。
二、常见根因（结合近期案例）
-
内核模块死循环或自旋锁长期未释放；
-
cgroup 读取路径（kubelet 统计内存/CPU 用量）在 5.10 以下内核有已知锁竞争，64 核以上机器极易触发；
-
驱动 bug、IPI 风暴、过量 iptables 规则导致 softirq 占用过高；
-
虚拟机场景下宿主机过载，vCPU 被抢占，Guest 侧看就是“softlockup”。
三、快速止血与后续规避
-
立即恢复
-
登录节点
echo 3 >/proc/sys/vm/drop_caches清缓存，减少 cgroup 遍历量； -
若 repeatable，可临时
echo 30 >/proc/sys/kernel/watchdog_thresh把阈值放宽到 30 s，避免立刻 panic。
-
-
根因处理
-
升级内核 ≥ 5.10.134（官方修复了大量 cgroup 锁竞争）；
-
给 kubelet 加参数
--housekeeping-interval=30s --cgroups-per-qos=false降低扫描频率； -
检查是否有过多的 iptables 规则/内核模块（nf_conntrack 等），按需精简；
-
对 VM 节点，确保宿主机不超载，开启硬件辅助虚拟化特性。
-
-
监控
-
对
/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 选主。