一.问题现象
k8s集群业务最近反馈在业务pod部署或者更新的时候，频繁出现failed to write 10087 to cgroup.procs
具体报错信息如下
47m Warning Unhealthy pod/cwdz-f4b54c9d5-nrzb4 Readiness probe failed: OCI runtime exec failed: exec failed: container_linux.go:348: starting container process caused "process_linux.go:90: adding pid 10087 to cgroups caused \"failed to write 10087 to cgroup.procs: write /sys/fs/cgroup/cpu,cpuacct/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podaa6efa94_5aef_4f5a_8a0a_eb73a719bfea.slice/docker-47dcf1949ef1792e7b4629c7b333b75e07f3f49c9ed30fca33919e4beff779bd.scope/cgroup.procs: invalid argument\"": unknown
11m Warning Unhealthy pod/cwdz-f4b54c9d5-nrzb4 Readiness probe failed: OCI runtime exec failed: exec failed: container_linux.go:348: starting container process caused "process_linux.go:90: adding pid 30822 to cgroups caused \"failed to write 30822 to cgroup.procs: write /sys/fs/cgroup/cpu,cpuacct/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podaa6efa94_5aef_4f5a_8a0a_eb73a719bfea.slice/docker-47dcf1949ef1792e7b4629c7b333b75e07f3f49c9ed30fca33919e4beff779bd.scope/cgroup.procs: invalid argument\"": unknown
58m Warning Unhealthy pod/ydapp2015-c4db49687-lfrhh Readiness probe failed: OCI runtime exec failed: exec failed: container_linux.go:348: starting container process caused "process_linux.go:90: adding pid 7792 to cgroups caused \"failed to write 7792 to cgroup.procs: write /sys/fs/cgroup/cpu,cpuacct/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod89607629_8b92_418c_b56a_d781267af97e.slice/docker-60aedbc30af5b28caf0e89e00393c07df9a281330d2dda7d349e5c8692b2d521.scope/cgroup.procs: invalid argument\"": unknown
二.原因分析
这个错误本质上和 Linux cgroup 子系统的限制有关，常见原因包括
- cgroup 版本不兼容 ：你的节点可能混合使用了 cgroup v1 和 v2，或者容器运行时（Docker/containerd）的 cgroup 驱动与 Kubernetes 节点的 cgroup 驱动不匹配（比如节点用
systemd而容器运行时用cgroupfs）。 - 资源限制 / 权限问题：Pod 的 CPU / 内存资源限制配置不合理，或 cgroup 目录的权限被篡改，导致无法写入 PID。
- 就绪探针配置不当：探针的执行命令过于复杂、执行频率过高，或探针超时时间过短，加剧了 cgroup 操作的失败概率。
三.解决办法
1.临时缓解方式：重启问题Pod
# 删除异常 Pod（Deployment 会自动重建）
kubectl delete pod cwdz-f4b54c9d5-nrzb4但由于出现问题的Pod的比较多，在前期未完全定位原因的情况下的临时缓解措施
2.检查cgroup的兼容性，并修复兼容匹配问题（最终原因）
-
检查kubelet的cgroup驱动
查看 kubelet 配置（不同集群部署方式路径可能不同）
cat /var/lib/kubelet/config.yaml | grep cgroupDriver
或直接查看 kubelet 启动参数
ps -ef | grep kubelet | grep -i cgroup
#查看 Docker 的 cgroup 驱动
docker info | grep -i cgroup
经检查发现在/var/lib/kubelet/config配置的 cgroupDriver 是 cgroupfs，而kubelet的启动参数又指定了--cgroup-driver=systemd，Docker 的 cgroup 驱动 是 systemd。
相当于 kubelet 同时被配置了两种不同的 cgroup 驱动（配置文件里的 cgroupfs + 启动参数里的 systemd），这种冲突会导致 kubelet 与容器运行时（Docker）的 cgroup 管理逻辑不一致，进而触发 cgroup.procs 写入失败的错误。
-
解决办法是需要统一 kubelet 的 cgroup 驱动配置（保持和 Docker 一致的
systemd）#修改 kubelet 配置文件，把 cgroupDriver 改成 systemd
vi /var/lib/kubelet/config.yaml
#将其中的 cgroupDriver: cgroupfs 改为：systemd
cgroupDriver: systemd#重启kubelet
systemctl restart kubelet -
重启后，再次检查 kubelet 的 cgroup 驱动是否统一：
检查配置文件
cat /var/lib/kubelet/config.yaml | grep cgroupDriver
检查启动参数（确认无冲突）
ps -ef | grep kubelet | grep -i cgroup
正常情况下，两者都应该显示 systemd。完成后，建议删除之前异常的 Pod（kubectl delete pod cwdz-f4b54c9d5-nrzb4），让 Deployment 重建 Pod，就绪探针的问题应该会解决。
四.批量执行
由于k8s集群涉及的node节点较多，如果一台台去执行，很浪费时间，可通过ansible批量执行
#查看kubelet配置文件的cgroup
ansible k8s -m shell -a 'cat /var/lib/kubelet/config.yaml | grep cgroupDriver'
#查看kubelet启动参数的cgroup
ansible k8s -m shell -a 'ps -ef | grep kubelet | grep -i cgroup'
#查看docker的cgroup
ansible k8s -m shell -a 'docker info | grep -i cgroup'
#批量修改/var/lib/kubelet/config.yaml
ansible k8s -m lineinfile -a "path=/var/lib/kubelet/config.yaml \
regexp='^cgroupDriver:' \
line='cgroupDriver: systemd' \
backup=yes"
#重启kubelet服务
ansible k8s -m systemd \
-a "name=kubelet state=restarted daemon_reload=yes"批量修改的backup=yes 会在修改前生成 .bak 后缀的备份文件，若修改出错可通过 cp /var/lib/kubelet/config.yaml.bak-$date /var/lib/kubelet/config.yaml 恢复，恢复后再重启kubelet即可