解决Kubernetes控制平面组件重启恢复问题

1. 问题现象与背景分析

最近在维护一套基于Docker和cri-dockerd的Kubernetes生产集群时，遇到了一个棘手的问题：每当服务器意外重启或计划性关机后，kube-apiserver、kube-controller-manager和kube-scheduler这三个核心控制平面组件总是无法自动恢复。这直接导致集群控制面瘫痪，需要手动干预才能恢复正常。

这种情况在传统systemd管理的Kubernetes集群中并不常见，因为systemd会默认自动重启这些关键服务。但在使用Docker容器运行时配合cri-dockerd的场景下，这些核心组件的生命周期管理出现了特殊的行为模式。

2. 根因深度剖析

2.1 组件运行方式差异

在标准的Kubernetes部署中，控制平面组件通常以三种方式运行：

1. 直接通过systemd管理的二进制进程
2. 作为静态Pod由kubelet托管
3. 在容器运行时中作为普通容器运行

我们的环境属于第三种情况，且使用了Docker作为容器运行时。这里的关键在于：当Docker服务重启时，默认不会自动恢复之前运行的容器，这与systemd的服务恢复机制有本质区别。

2.2 cri-dockerd的工作机制

cri-dockerd作为Docker和Kubernetes CRI接口之间的适配层，其行为会影响容器的生命周期管理。当节点重启时：

1. Docker服务需要时间启动
2. cri-dockerd随后启动并尝试连接Docker
3. 但默认配置下不会自动恢复之前的容器实例

2.3 Kubelet的恢复逻辑

Kubelet理论上应该负责重新创建这些组件容器，但在我们的场景中观察到：

• Kubelet启动时可能早于Docker/cri-dockerd就绪
• 组件容器的重启策略可能未被正确识别
• 证书过期等时间敏感问题可能阻碍自动恢复

3. 解决方案与实施步骤

3.1 方案一：配置Docker容器自动重启

最直接的解决方法是配置Docker的restart policy：

bash复制# 修改现有容器配置
docker update --restart=unless-stopped <container_id>

# 或者创建新容器时指定
docker run --restart=unless-stopped ...

对于已经部署的Kubernetes组件，可以通过修改它们的容器定义：

bash复制# 以kube-apiserver为例
docker inspect k8s_kube-apiserver | grep -A 10 RestartPolicy

3.2 方案二：改用静态Pod部署

更符合Kubernetes设计理念的方式是将这些组件转为静态Pod：

1. 在/etc/kubernetes/manifests/目录下创建Pod定义文件
2. 确保kubelet配置中包含：

   bash复制--pod-manifest-path=/etc/kubernetes/manifests
   

3. 示例apiserver静态Pod定义：

   yaml复制apiVersion: v1
   kind: Pod
   metadata:
     name: kube-apiserver
     namespace: kube-system
   spec:
     containers:
     - name: kube-apiserver
       image: k8s.gcr.io/kube-apiserver:v1.24.0
       ...
     restartPolicy: Always
   

3.3 方案三：完善systemd单元依赖

对于仍想保持Docker容器运行方式的场景，可以优化systemd单元配置：

1. 创建服务依赖：

   ini复制[Unit]
   After=docker.service cri-dockerd.service
   Requires=docker.service cri-dockerd.service
   

2. 添加健康检查脚本：

   bash复制ExecStartPost=/usr/local/bin/check-kube-components.sh
   

4. 验证与测试方案

4.1 测试重启恢复能力

1. 模拟意外重启：

   bash复制systemctl stop kubelet
   systemctl stop docker
   systemctl start docker
   systemctl start kubelet
   

2. 检查组件状态：

   bash复制kubectl get pods -n kube-system
   docker ps | grep -E 'apiserver|controller|scheduler'
   

4.2 关键指标监控

建议监控以下指标判断恢复是否成功：

5. 生产环境注意事项

5.1 证书有效期问题

在长时间停机后可能遇到证书过期问题：

bash复制# 检查证书有效期
openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -dates

# 提前续期证书
kubeadm alpha certs renew all

5.2 资源竞争风险

多个组件同时启动可能导致：

1. API Server启动时etcd尚未就绪
2. Controller Manager与Scheduler竞争API资源

建议在systemd单元中添加延迟启动：

ini复制[Service]
ExecStartPre=/bin/sleep 30

5.3 日志收集策略

配置完善的日志收集以便故障诊断：

bash复制# Docker日志驱动配置
{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m",
    "max-file": "3"
  }
}

6. 长期维护建议

1. 定期测试重启恢复流程（建议每季度一次）
2. 建立关键组件健康状态仪表盘
3. 编写自动化修复脚本应对常见故障场景
4. 考虑使用高可用部署架构减少单点故障影响

对于生产环境，我强烈建议采用静态Pod部署方案配合适当的监控告警。这种方案在我维护的多个集群中表现出最稳定的恢复特性，特别是在意外断电等极端场景下仍能保持较高的可用性。