Kubernetes Master节点失联应急恢复方案

一、故障概要

1.1 现象描述

• Master节点完全失联，控制平面不可用

• 微服务因无法加载ConfigMap而启动失败

• Service服务发现机制中断

1.2 适用场景

✅ ​推荐使用​

• 关键业务服务需在2小时内紧急恢复​

• 服务间依赖简单（≤3个微服务）

• 可容忍临时降级服务

⛔ ​不推荐使用​

• 复杂微服务调用链（＞3个服务）

• 需长期运行（＞6小时）

• 依赖自动扩缩容/服务发现

🛠 ​实施风险清单​

✨ ​推荐执行方案​

1. ​短期（<2h）应急​：

   # 1. 提取最新ConfigMap
   ETCDCTL_API=3 etcdctl get /registry/configmaps/<namespace>/<name> \
     --endpoints=http://backup-etcd-ip:2379 | hexdump -C
   
   # 2. 固定IP启动容器（需创建单独docker网络）
   docker network create --subnet=172.18.0.0/16 k8s-rescue
   docker run -d --net k8s-rescue --ip 172.18.0.100 \
     -p 30080:8080 \
     -v /rescue/config:/cfg \
     your-image --spring.config.location=/cfg/

   临时apiserver

   # 在健康节点启动临时控制平面（关键！）
   docker run -d --name=rescue-apiserver -p 6443:6443 \
     -v /etc/kubernetes/pki:/etc/kubernetes/pki \
     k8s.gcr.io/kube-apiserver:v1.24.0 \
     --etcd-servers=https://<etcd-ip>:2379 \
     --tls-cert-file=/etc/kubernetes/pki/apiserver.crt \
     --tls-private-key-file=/etc/kubernetes/pki/apiserver.key
   
   # 所有Node修改kubelet参数
   sed -i 's/--api-servers=.*/--api-servers=https:\/\/rescue-apiserver-ip:6443/' /etc/systemd/system/kubelet.service

💎 最终结论

​优先用临时API-Server恢复集群​​ ，比维护手动IP映射更可靠。若超过3个微服务待恢复，手动方案的综合运维成本将超过重建控制平面。

基于目前微服务多且互相调用依赖复杂，最终启动后可能还是导致系统无法恢复可用。