解决Kubernetes集群重启后控制平面无法自动恢复的问题

1. 问题现象与背景分析

最近在维护一个基于kubeadm部署的Kubernetes生产集群时，遇到了一个令人头疼的启动依赖问题。这个集群的底层容器运行时采用的是Docker，并通过cri-dockerd作为CRI接口来桥接kubelet与Docker。在服务器重启或关机再开机的场景下，控制平面组件（kube-apiserver、kube-controller-manager、kube-scheduler）经常无法自动恢复，导致整个集群处于不可用状态。

具体表现为：

• 服务器重启后，虽然已经配置了systemd依赖（After=cri-dockerd.service），但控制平面Pod仍然无法自动拉起
• 关机后再开机的场景下，问题更加严重，必须手动执行systemctl restart docker cri-dockerd kubelet命令才能恢复集群
• 查看服务状态时，经常看到"activating (auto-restart)"的提示，表明服务在尝试自动恢复但未成功

2. 依赖关系与问题根源

2.1 组件依赖链条分析

要理解这个问题，首先需要理清各个组件之间的启动依赖关系：

code复制kubelet → cri-dockerd → docker

在这个依赖链中：

1. kubelet是Kubernetes的节点代理，负责管理Pod和容器
2. cri-dockerd是Docker的CRI接口实现，作为kubelet和Docker之间的桥梁
3. Docker是实际的容器运行时

2.2 问题根本原因

经过多次测试和分析，发现问题主要出在以下几个方面：

1. systemd服务依赖配置不完整：虽然已经配置了kubelet对cri-dockerd的依赖，但未充分考虑所有可能的启动场景

2. 关机与重启的差异：

   • 服务器重启时，systemd会尝试保持服务间的依赖顺序
   • 完全关机后再开机，systemd的依赖管理可能不会按预期工作

3. 服务启动超时：某些服务在依赖服务未完全就绪时启动，导致超时失败

4. 资源竞争：多个服务同时启动可能导致资源竞争，特别是网络资源

3. 解决方案与配置调整

3.1 修改kubelet服务配置

首先需