16.9.9 故障演练与应急预案

本节聚焦生产环境中 Kubernetes 故障演练与应急预案建设，目标是通过常态化演练提升团队对集群级、节点级与应用级故障的快速识别与处置能力，确保业务连续性与可恢复性。

故障演练目标与范围#

  • 目标定义：验证高可用架构有效性、RTO/RPO 达成情况、自动化修复能力与人工处置流程。
  • 演练范围：控制平面组件（apiserver/etcd/scheduler/controller-manager）、节点故障、网络分区、存储故障、应用级异常、镜像/制品异常、配置/密钥误改。
  • 演练原则：最小影响、可回滚、全链路观察、可复盘、可改进。
文章图片

演练类型与典型场景#

  • 节点级故障：节点宕机、资源耗尽、kubelet 异常、时钟漂移。
  • 控制面故障：etcd 节点失联、apiserver 异常、证书过期。
  • 网络故障：CNI 异常、网络分区、DNS 解析失败、服务发现故障。
  • 存储故障：PV 失联、CSI 异常、卷只读、存储延迟飙升。
  • 应用故障：容器崩溃循环、镜像拉取失败、配置错误导致服务不可用。
  • 安全事件：密钥泄露、误操作删除关键资源、异常流量攻击。

演练流程与执行规范#

  1. 演练准备：明确演练目标、影响范围、回滚策略、负责人与沟通机制。
  2. 演练实施：按场景注入故障并实时监控指标、日志、事件与追踪。
  3. 应急处置：执行预案操作，记录操作时间线与关键决策。
  4. 验证恢复：验证业务功能、性能指标、数据一致性与 SLA。
  5. 复盘改进：输出复盘报告，固化改进项与自动化能力。

应急预案关键内容#

  • 分级响应机制：按影响范围划分 P1/P2/P3，明确升级与通知链路。
  • 关键系统清单：核心命名空间、关键服务、依赖中间件与外部系统。
  • 回滚策略：镜像回滚、配置回滚、版本回退、流量切换。
  • 快速处置手册：常见故障定位与修复步骤，包含命令与验证检查。
  • 数据保护策略：etcd 备份与恢复流程、PV 快照策略与恢复演练。

监控与告警联动#

  • 告警触发：节点不可达、Pod 异常重启、API 请求失败率上升、etcd 延迟升高。
  • 自动化响应：结合自动化脚本/Runbook 执行，缩短 MTTR。
  • 指标验证：恢复后关键指标（延迟、错误率、吞吐）恢复到基线。

持续改进与演练制度化#

  • 演练频率：关键场景季度演练，基础场景月度演练。
  • 演练覆盖率：按系统与业务重要性评估覆盖情况。
  • 知识库沉淀：将演练结果纳入运维知识库与标准化流程。
  • 指标量化：以 RTO/RPO、MTTR、告警命中率为衡量指标持续优化。

演练工具与安装示例（可选）#

建议在测试或预发环境引入轻量故障注入工具，避免直接在生产环境“裸注入”。

安装 Chaos Mesh（示例）#

# 1) 安装 Helm（若已安装可跳过）
curl -fsSL https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

# 2) 添加仓库并安装到 chaos-testing 命名空间
helm repo add chaos-mesh https://charts.chaos-mesh.org
helm repo update

kubectl create ns chaos-testing
helm install chaos-mesh chaos-mesh/chaos-mesh -n chaos-testing \
  --set dashboard.create=true

# 3) 验证安装
kubectl -n chaos-testing get pods
# 预期：chaos-controller-manager/chaos-daemon/chaos-dashboard 正常 Running

典型演练一：节点不可达（节点级故障）#

目标#

验证节点宕机后 Pod 迁移、服务恢复与告警链路。

故障注入（在测试节点执行）#

# 模拟节点不可达：停止 kubelet
sudo systemctl stop kubelet

# 观察节点状态
kubectl get nodes
# 预期：该节点变为 NotReady

排错与恢复步骤#

# 1) 查看节点事件
kubectl describe node <node-name> | tail -n +1

# 2) 查看该节点上的 Pod 迁移情况
kubectl get pods -A -o wide | grep <node-name>

# 3) 恢复 kubelet
sudo systemctl start kubelet

# 4) 验证节点恢复
kubectl get nodes
# 预期：节点恢复 Ready，Pod 重建完成

练习#

  • 在不同节点分别执行一次，记录 Pod 迁移耗时（RTO）。
  • 比较有 PDB 与无 PDB 的迁移差异。

典型演练二：etcd 延迟与不可用（控制面故障）#

原理草图（组件关系）#

文章图片

故障注入（示例：阻断 API Server 访问 ETCD 端口）#

仅建议在测试环境执行；生产请用变更窗口与回滚预案。

# 1) 找到 etcd 监听端口（常见 2379）
ss -lntp | grep etcd

# 2) 临时阻断访问（iptables 示例）
sudo iptables -I INPUT -p tcp --dport 2379 -j DROP

# 3) 观察 apiserver 请求失败
kubectl get --raw /healthz
# 预期：healthz 非 ok 或超时

恢复#

# 移除阻断规则
sudo iptables -D INPUT -p tcp --dport 2379 -j DROP

# 验证恢复
kubectl get --raw /healthz
# 预期：返回 ok

排错命令解释#

  • kubectl get --raw /healthz：直接访问 API Server 健康检查端点。
  • iptables -I/D：插入/删除规则，模拟网络分区。

典型演练三：配置误改导致服务不可用（应用级故障）#

故障注入与回滚（示例）#

# 1) 查看 Deployment 与 ConfigMap
kubectl -n prod get deploy web -o wide
kubectl -n prod get cm web-config -o yaml > /tmp/web-config.bak.yaml

# 2) 故障注入：写入错误配置
kubectl -n prod patch cm web-config --type merge -p \
  '{"data":{"UPSTREAM_URL":"http://127.0.0.1:1"}}'

# 3) 触发滚动更新（若应用依赖配置重启）
kubectl -n prod rollout restart deploy web

# 4) 观察服务异常
kubectl -n prod logs deploy/web --tail=50

回滚恢复#

# 使用备份恢复 ConfigMap
kubectl apply -f /tmp/web-config.bak.yaml

# 再次滚动更新
kubectl -n prod rollout restart deploy web

# 验证恢复
kubectl -n prod rollout status deploy web

快速处置手册（Runbook 示例）#

# 1) 定位故障范围
kubectl get nodes
kubectl get pods -A | grep -E 'CrashLoopBackOff|ImagePullBackOff|Pending'

# 2) 关键组件状态
kubectl -n kube-system get pods | grep -E 'apiserver|etcd|scheduler|controller'

# 3) 关键事件
kubectl get events -A --sort-by=.metadata.creationTimestamp | tail -n 20

# 4) 回滚部署
kubectl -n prod rollout history deploy web
kubectl -n prod rollout undo deploy web --to-revision=2

应急预案模板（可直接落地）#

  • P1 触发条件：核心业务不可用、全局 API 不可用、etcd 多数不可达。
  • 联系人：值班 SRE、平台负责人、业务负责人、网络/存储负责人。
  • 执行路径：
    1. 冻结变更、停止自动发布；
    2. 执行 Runbook，优先恢复控制面；
    3. 业务侧验证关键路径；
    4. 复盘与问题单闭环。

实战练习与验收标准#

  • 练习 1：模拟 1 个节点 NotReady，记录 Pod 重建耗时与告警时间。
  • 练习 2：模拟 ConfigMap 误改并回滚，验证服务 5 分钟内恢复。
  • 验收标准：
  • P1 事件 RTO ≤ 10 分钟；
  • 告警命中率 ≥ 95%；
  • 复盘报告 24 小时内完成。