Master故障，该如何快速响应

当Master真的挂了：Kubernetes灾难恢复实战手册

---

凌晨3点，告警突然响起
监控大屏一片血红：

• 🔴 API Server 全部实例不可用
• 🔴 etcd 集群写入超时
• 🔴 所有控制平面组件离线

这是每个Kubernetes运维工程师的噩梦时刻。本文将用实战操作手册的形式，带你一步步完成从灾难检测到完整恢复的全过程。

---

第一阶段：冷静诊断（5分钟内必须完成）

1. 快速判断故障等级

# 检查API Server状态（从任意Worker节点执行）
curl -k https://<LB-VIP>:6443/livez
# 预期输出：ok

# 检查etcd健康状态（需SSH到Master节点）
ETCDCTL_API=3 etcdctl endpoint status \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key -w table

故障等级判定表：

现象	等级	应对策略
单个Master节点宕机	T1	自动恢复
多数etcd节点失联	T2	手动介入
全Master节点不可用	T3	灾难恢复

2. 收集关键证据（黄金8分钟原则）

# 抓取控制平面日志
journalctl -u kubelet -u etcd -u kube-apiserver --since "10 minutes ago" > /tmp/disaster.log

# 备份当前etcd数据（即使可能损坏）
ETCDCTL_API=3 etcdctl snapshot save /tmp/emergency.db \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

---

第二阶段：六大灾难场景恢复指南

场景1：etcd全盘故障（最危险！）

特征：etcdserver: mvcc: database space exceeded 或 etcdserver: corrupt

恢复步骤：

1. 从最新快照重建集群

# 在所有etcd节点执行
ETCDCTL_API=3 etcdctl snapshot restore emergency.db \
  --name infra-1 \
  --initial-cluster infra-1=https://10.0.1.10:2380,infra-2=https://10.0.1.11:2380 \
  --initial-cluster-token etcd-cluster-1 \
  --initial-advertise-peer-urls https://10.0.1.10:2380

# 重启etcd服务
systemctl restart etcd

2. 强制恢复quorum（当多数节点丢失时）

# 在存活节点上执行
etcdctl alarm disarm
etcd --force-new-cluster

场景2：所有Master节点物理损毁

恢复流程：

关键操作：

# 使用kubeadm重建第一个Master
kubeadm init phase certs all --config kubeadm-config.yaml
kubeadm init phase control-plane all --config kubeadm-config.yaml

# 让Worker重新信任新集群
kubeadm alpha certs renew all
systemctl restart kubelet

场景3：证书集体过期（隐蔽杀手！）

典型报错：x509: certificate has expired or is not yet valid

紧急续签方案：

# 1. 续签所有证书
kubeadm alpha certs renew all

# 2. 更新kubeconfig文件
cp -i /etc/kubernetes/admin.conf ~/.kube/config

# 3. 滚动重启组件
for comp in kube-apiserver kube-controller-manager kube-scheduler; do
  kubectl rollout restart deploy $comp -n kube-system
done

场景4：误删关键资源（如kube-system命名空间）

恢复技巧：

# 从etcd直接恢复被删对象
ETCDCTL_API=3 etcdctl get /registry/namespaces/kube-system \
  --print-value-only | jq . > kube-system.json

# 重建资源
kubectl replace -f kube-system.json

场景5：网络割接导致脑裂

修复流程：

1. 确定权威Master

kubectl get lease -n kube-system kube-controller-manager -o yaml

2. 清理异常状态

kubectl delete pods --all -n kube-system --grace-period=0 --force

场景6：内核故障引发的雪崩

应对策略：

# 临时启用静态Pod维持基础服务
cp /etc/kubernetes/manifests/etcd.yaml /etc/kubernetes/manifests-backup/
systemctl restart kubelet

---

第三阶段：恢复后的必修课

1. 验证集群健康度

# 核心检查清单
kubectl get componentstatuses
kubectl get --raw='/readyz?verbose'
etcdctl check perf

2. 根因分析模板

## RCA报告模板

**故障时间**: 2023-08-20 02:00-04:00  
**影响范围**: API Server不可用持续118分钟  
**根本原因**: 
  - [ ] etcd存储过载  
  - [ ] 证书过期  
  - [ ] 网络分区  
  - [ ] 人为误操作  
**改进措施**:
  - [ ] 增加etcd存储预警阈值  
  - [ ] 实施证书自动轮换  
  - [ ] 完善权限审批流程

3. 预防体系升级

1. 混沌工程注入计划

# 使用chaos-mesh模拟Master故障
kubectl apply -f network-partition.yaml -n chaos-testing

2. Golden Image制作规范

# Master节点镜像模板
FROM ubuntu:20.04
COPY kubeadm-config.yaml /root/
RUN kubeadm config images pull --config /root/kubeadm-config.yaml

3. SOP检查清单

[ ] etcd每日快照验证  
[ ] 证书过期倒计时监控  
[ ] LB健康检查配置审核  
[ ] 跨AZ拓扑验证

---

真实战场：某电商大促期间Master恢复实录

时间线：

• 00:12 监控发现API Server 5xx错误率飙升
• 00:15 确认3个etcd节点磁盘写满
• 00:22 启动紧急恢复预案
• 00:45 从S3恢复2小时前快照
• 01:30 业务完全恢复

关键决策点：

• 放弃部分日志数据，优先恢复交易核心服务
• 临时关闭HPA控制器防止调度风暴
• 保留故障现场供后续分析

---

终极防御：让故障成为可选项

1. 跨集群热备方案

# Cluster API配置示例
apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: prod-cluster-backup
spec:
  infrastructureRef:
    kind: AWSCluster
    name: prod-cluster-backup

2. 自愈系统设计

func autoHealMaster() {
    if checkAPIServerHealth() == false {
        spinUpNewMaster()
        updateLoadBalancerPool()
    }
}

---