企业官网建设流程全解析

深圳网站设计服,广东建设企业网站哪家好,app详情页设计,搜索历史记录一.问题现象k8s集群业务最近反馈在业务pod部署或者更新的时候#xff0c;频繁出现failed to write 10087 to cgroup.procs具体报错信息如下47m Warning Unhealthy pod/cwdz-f4b54c9d5-nrzb4 Readiness probe failed: OCI runtime exec failed: exec failed…一.问题现象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\: unknown11m 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\: unknown58m 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# 删除异常 PodDeployment 会自动重建 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-driversystemdDocker 的 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。完成后建议删除之前异常的 Podkubectl 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: \ linecgroupDriver: systemd \ backupyes #重启kubelet服务 ansible k8s -m systemd \ -a namekubelet staterestarted daemon_reloadyes批量修改的backupyes 会在修改前生成 .bak 后缀的备份文件若修改出错可通过 cp /var/lib/kubelet/config.yaml.bak-$date /var/lib/kubelet/config.yaml 恢复恢复后再重启kubelet即可