1. 问题现象与背景分析最近在维护一套基于Docker cri-dockerd的Kubernetes生产环境时遇到了一个令人头疼的问题每当服务器执行计划内重启或意外断电后kube-apiserver、controller-manager和scheduler这三个核心控制平面组件总是无法自动恢复。这直接导致整个集群处于不可用状态需要人工介入才能恢复服务。通过systemctl status命令检查发现这些组件的systemd服务单元虽然显示为active (running)状态但实际功能并未正常工作。更诡异的是手动执行systemctl restart却能立即恢复正常。这种现象在Ubuntu 20.04和CentOS 7.9系统上均有复现使用的Kubernetes版本为v1.24.3Docker版本为20.10.17cri-dockerd版本为v0.2.5。2. 根因定位过程2.1 服务启动顺序依赖分析首先排查系统启动日志journalctl -b发现关键线索kubelet服务启动时报错Failed to get system container stats。深入分析发现这是因为containerd和docker服务尚未完全就绪时kubelet就已经开始尝试创建Pod。虽然这些错误在后续docker服务启动成功后会自动恢复但控制平面组件的启动已经受到影响。经验提示在基于systemd的系统中服务启动顺序由After/Requires等指令控制。默认的Kubernetes服务单元文件往往缺乏对容器运行时就绪状态的明确依赖。2.2 cri-dockerd的启动时序问题cri-dockerd作为Docker和Kubelet之间的适配层其systemd服务cri-docker.service需要确保在docker.service之后启动。但实际观察发现由于缺乏显式依赖声明有时会出现以下启动序列kubelet启动cri-dockerd启动docker启动这种错序会导致kubelet初期连接cri-dockerd失败进而影响控制平面组件的初始化。2.3 控制平面组件的自愈机制缺失Kubernetes控制平面组件默认以静态Pod方式运行由kubelet直接管理。理论上kubelet应该持续监控并确保这些Pod的运行状态但实际测试发现当组件因底层运行时问题崩溃时kubelet的重启机制有时会失效组件进程存在但服务无响应的情况zombie状态无法被有效检测日志中频繁出现connection refused错误表明组件间健康检查失败3. 解决方案与实施步骤3.1 修正systemd单元依赖关系为每个相关服务添加正确的启动依赖# 修改cri-docker.service sudo tee /etc/systemd/system/cri-docker.service.d/10-depends-on-docker.conf /dev/null EOF [Unit] Requiresdocker.service Afterdocker.service EOF # 修改kubelet.service sudo tee /etc/systemd/system/kubelet.service.d/10-depends-on-cri-docker.conf /dev/null EOF [Unit] Requirescri-docker.service Aftercri-docker.service EOF sudo systemctl daemon-reload3.2 配置kubelet健康检查参数调整kubelet配置以增强对控制平面组件的监控# /var/lib/kubelet/config.yaml 添加 healthzBindAddress: 0.0.0.0 healthzPort: 10248 imageGCHighThresholdPercent: 85 imageGCLowThresholdPercent: 80 evictionHard: memory.available: 100Mi nodefs.available: 10% nodefs.inodesFree: 5% imagefs.available: 15%3.3 控制平面Pod的livenessProbe强化修改/etc/kubernetes/manifests下的静态Pod定义文件为每个组件添加健壮的存活探针# kube-apiserver.yaml示例 spec: containers: - name: kube-apiserver livenessProbe: httpGet: path: /livez port: 8080 scheme: HTTP initialDelaySeconds: 30 timeoutSeconds: 15 periodSeconds: 10 failureThreshold: 33.4 系统级监控与恢复机制创建systemd定时检查服务作为最后保障# /etc/systemd/system/k8s-controlplane-watchdog.service [Unit] DescriptionKubernetes Control Plane Watchdog Afternetwork.target [Service] Typeoneshot ExecStart/usr/local/bin/k8s-controlplane-check.sh # /etc/systemd/system/k8s-controlplane-watchdog.timer [Unit] DescriptionRun control plane check every 5 minutes [Timer] OnBootSec5m OnUnitActiveSec5m [Install] WantedBytimers.target配套的检查脚本示例#!/bin/bash # /usr/local/bin/k8s-controlplane-check.sh if ! kubectl get --raw/readyz /dev/null; then logger k8s-controlplane-watchdog: API server unresponsive, restarting components systemctl restart kubelet sleep 30 systemctl restart docker cri-docker fi4. 验证与测试方案4.1 模拟故障测试人为停止docker服务sudo systemctl stop docker观察组件状态watch -n 1 kubectl get pods -n kube-system恢复docker服务后验证自动恢复sudo systemctl start docker4.2 压力测试验证使用kube-burner工具制造API负载同时重启节点kube-burner init --configstress-config.yml --uuid$(uuidgen) sudo reboot监控指标包括控制平面组件重启次数kube_pod_container_status_restarts_totalAPI响应延迟apiserver_request_duration_seconds_bucket节点就绪时间从重启到kube-node-ready事件4.3 长稳运行验证持续运行72小时检查journalctl -u kubelet --since 72 hours ago | grep -i backoff\|error\|fail kubectl get events -A --sort-by.lastTimestamp | grep -i unhealthy5. 生产环境增强建议5.1 多节点高可用部署对于生产环境建议至少部署3个控制平面节点配置kube-apiserver负载均衡如HAProxy keepalivedetcd集群跨节点分布使用--pod-infra-container-image指定专用pause镜像5.2 关键参数调优在/var/lib/kubelet/kubeadm-flags.env中添加--max-pods150 --kube-api-qps50 --kube-api-burst100 --serialize-image-pullsfalse5.3 日志与监控增强部署以下监控方案Prometheus采集kubelet、docker、cri-dockerd指标Grafana仪表盘监控容器运行时状态控制平面组件健康度资源水位线关键告警规则KubeletNotReady超过5分钟ContainerRuntimeDownControlPlaneUnavailable6. 典型故障处理记录6.1 案例1cri-dockerd端口冲突现象服务器重启后kubelet日志显示failed to connect to CRI socket 排查ss -lntp | grep 10010 ps aux | grep cri-dockerd解决sudo sed -i s/--network-plugin/--pod-infra-container-imageregistry.aliyuncs.com\/google_containers\/pause:3.7 --network-plugin/ /etc/systemd/system/cri-docker.service sudo systemctl daemon-reload6.2 案例2Docker存储驱动不兼容现象重启后docker服务正常但无法创建新容器 排查docker info | grep Storage Driver lsblk -f解决sudo mkdir -p /etc/docker sudo tee /etc/docker/daemon.json EOF { storage-driver: overlay2, storage-opts: [ overlay2.override_kernel_checktrue ] } EOF6.3 案例3系统资源不足导致启动超时现象journalctl显示Start request repeated too quickly 调整服务启动超时sudo mkdir -p /etc/systemd/system/kubelet.service.d sudo tee /etc/systemd/system/kubelet.service.d/20-timeout.conf EOF [Service] TimeoutStartSec300 EOF