最稳妥做法是将 Docker 的 cgroup driver 改为 systemd 以与 kubelet 对齐;混用 cgroupfs 和 systemd 易导致统计偏差、OOM 异常或节点失联;需通过 docker info 和 kubelet 启动参数或配置文件确认驱动是否一致;首选统一为 systemd,修改 /etc/docker/daemon.json 并重启 Docker;备选方案为统一为 cgroupfs,但不推荐新集群使用;最后须验证节点状态为 Ready、CNI Pod 运行正常且 kubelet 日志无 cgroup 相关报错。

直接改 Docker 的 cgroup driver 为 systemd,和 kubelet 对齐,是最稳妥、最推荐的做法。系统级资源管理必须统一入口,混用 cgroupfs 和 systemd 容易在高负载下出现统计偏差、OOM 触发异常甚至节点失联。
快速确认是否是驱动不一致
登录故障节点,执行两条命令:
-
查 Docker 当前驱动:
docker info | grep "Cgroup Driver"—— 输出应为cgroupfs或systemd -
查 kubelet 当前驱动:
ps aux | grep kubelet | grep -o 'cgroup-driver=[^[:space:]]*'或检查配置文件(如/var/lib/kubelet/config.yaml中的cgroupDriver字段)
两者结果不同,就是根因。常见组合是 Docker 用 cgroupfs、kubelet 用 systemd,尤其在 CentOS 7 / Ubuntu 20.04+ 上默认如此。
首选方案:统一为 systemd(推荐)
systemd 是现代 Linux 发行版的 init 系统,与 cgroup v2 兼容性更好,且由系统服务统一管控,稳定性更高。操作分三步:
在 Linux 上通过 Docker 运行 OpenClaw,并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
- 编辑
/etc/docker/daemon.json,加入或修改:{"exec-opts": ["native.cgroupdriver=systemd"]}
注意:如果文件已有其他配置,确保 JSON 格式合法(逗号、引号、括号匹配) - 重载并重启 Docker:
sudo systemctl daemon-reload && sudo systemctl restart docker - 验证生效:
docker info | grep "Cgroup Driver"应输出systemd;再确认 kubelet 启动参数中也含--cgroup-driver=systemd(通常 kubeadm 部署默认已设)
备选方案:统一为 cgroupfs(仅限特殊场景)
若环境强制依赖旧版工具链(如某些嵌入式容器运行时),或 systemd 驱动引发兼容问题,可反向对齐到 cgroupfs。但需同步调整 kubelet:
- 修改 kubelet 启动参数,在
/etc/systemd/system/kubelet.service.d/10-kubeadm.conf的Environment=行中添加:--cgroup-driver=cgroupfs - 执行:
sudo systemctl daemon-reload && sudo systemctl restart kubelet - 注意:Docker 无需改(默认即 cgroupfs),但此方案在 cgroup v2 环境下可能报错,不建议新集群使用
验证与收尾
改完后不要只看服务状态,要真正验证节点回归 Ready:
- 等 1–2 分钟,执行
kubectl get nodes,状态应变为Ready - 检查 Flannel/Calico 等 CNI 插件 Pod 是否 Running(NotReady 节点常导致 CNI Pod Pending)
- 观察日志是否还有
cgroup driver相关报错:journalctl -u kubelet -n 50 --no-pager | grep -i cgroup
节点闪退往往不是单次失败,而是持续 CrashLoopBackOff。驱动对齐后,kubelet 才能稳定上报心跳,资源限制、Pod 驱逐、监控指标才能准确工作。


















