现场是这样的。K8s 1.26 的节点跑了三个月后突然变成 NotReady，kubelet 日志里反复出现 failed to get cgroup stats for /system.slice/kubelet.service，节点还能 ssh 进去，containerd 也活得好好的。
中间走过弯路，把「cadvisor 的端口被别的进程占用，统计请求一直超时」当成主因，改完现象没变。
这类报错背后常见的原因有几处，逐个排除就行。systemd 的 cgroup 驱动和 kubelet 配的 cgroupfs 不一致，统计路径对不上；节点用了 cgroup v2，kubelet 还在读 /sys/fs/cgroup 下的旧目录结构；节点磁盘压力触发了驱逐，kubelet 自己被拖慢后心跳超时。
先看 kubelet 日志里的完整报错
journalctl -u kubelet -n 50 --no-pager | grep -iE 'cgroup|cadvisormetrics'然后确认运行时用的 cgroup 驱动
crictl info | grep -E 'cgroupDriver|runtimeName'随后核对 kubelet 的驱动配置
grep -rn -E 'cgroupDriver|cgroup-driver' /var/lib/kubelet/config.yaml /etc/systemd/system/kubelet.service.d/剩下的就是重启 kubelet 并观察节点状态
systemctl daemon-reload && systemctl restart kubelet && kubectl get node -o wide改之前我把相关日志按时间截了一段存着，事后对时间线用得上。
怎么算真的好了，看的是同一批现象。kubectl get node 回到 Ready，kubelet 日志不再刷 cgroup stats 报错，节点上的 Pod 状态陆续恢复。
这里还有个坑。1.26 之后默认走 systemd 驱动，containerd 和 kubelet 两边必须一致；cgroup 版本切换要先把节点排空，别在线上直接改。同一份配置在测试环境跑通，不代表线上没事，两边的默认值经常不一样。