Kubernetes集群故障应急响应手册：从告警分级到混沌工程验证的完整SRE实践

Kubernetes集群故障应急响应是SRE团队的核心能力。生产环境中Pod频繁CrashLoopBackOff、节点NotReady、API Server超时等问题随时可能发生，缺乏标准化的响应流程会导致故障时间拉长、影响面扩大。本文从告警分级、常见故障排查路径、应急修复操作到混沌工程验证，给出一套可落地的SRE稳定性工程实践方案。

告警分级体系：P0-P3的响应标准

建立四级告警体系是应急响应的基础。P0级告警（5分钟内响应）：API Server不可达、ETCD集群多数节点失联、核心业务全部5xx。P1级告警（15分钟内响应）：单节点NotReady、关键Deployment全部Pod不可用、Ingress流量异常下跌超50%。P2级告警（1小时内响应）：Pod重启次数超过阈值、HPA频繁触发、PVC空间使用率超85%。P3级告警（4小时内响应）：非关键组件资源使用率偏高、日志中出现非致命错误。

# Prometheus告警规则示例
groups:
- name: kubernetes-critical
  rules:
  - alert: APIServerDown
    expr: up{job="kubernetes-apiservers"} == 0
    for: 1m
    labels:
      severity: P0
    annotations:
      summary: "API Server不可达"
      runbook: "https://wiki/runbook/apiserver-down"

  - alert: NodeNotReady
    expr: kube_node_status_condition{condition="Ready",status="true"} == 0
    for: 3m
    labels:
      severity: P1
    annotations:
      summary: "节点 {{ $labels.node }} NotReady"

  - alert: PodCrashLooping
    expr: rate(kube_pod_container_status_restarts_total[15m]) * 60 * 5 > 0
    for: 5m
    labels:
      severity: P2
    annotations:
      summary: "Pod {{ $labels.namespace }}/{{ $labels.pod }} 处于CrashLoop状态"

Pod CrashLoopBackOff排查路径

CrashLoopBackOff是最常见的Kubernetes故障之一，排查遵循固定路径。第一步查看容器日志，定位崩溃原因；第二步检查Events，查看调度和启动阶段异常；第三步检查资源限制是否导致OOMKilled。

# 1. 查看Pod状态和重启次数
kubectl get pods -n production -o wide | grep -E "CrashLoop|Error|OOM"

# 2. 查看容器日志（前一次崩溃的日志）
kubectl logs <pod-name> -n production --previous

# 3. 查看Pod Events
kubectl describe pod <pod-name> -n production | grep -A 20 "Events:"

# 4. 常见OOMKilled确认
kubectl describe pod <pod-name> -n production | grep -A 5 "Last State"
# 输出中 OOMKilled: true 表示内存超限

# 5. 临时增加资源限制快速恢复
kubectl set resources deployment/<deploy-name> -n production \
    --containers=<container-name> \
    --requests=memory=512Mi,cpu=250m \
    --limits=memory=1Gi,cpu=500m

节点NotReady的应急处理流程

节点NotReady通常由kubelet失联、磁盘压力或网络分区导致。处理时先隔离再排查：将节点标记为不可调度，防止新Pod调度到故障节点；排空节点上的工作负载；排查根因。

# 1. 标记节点不可调度
kubectl cordon <node-name>

# 2. 驱逐节点上的Pod（注意PodDisruptionBudget）
kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data --timeout=120s

# 3. SSH到节点检查kubelet状态
ssh <node-name> "systemctl status kubelet"
ssh <node-name> "journalctl -u kubelet --since '10 minutes ago' --no-pager"

# 4. 检查磁盘压力
df -h /var/lib/kubelet /var/lib/docker

# 5. 检查网络连通性
ssh <node-name> "curl -sk https://<api-server-ip>:6443/healthz"

# 6. 修复后恢复节点
kubectl uncordon <node-name>

ETCD集群故障的紧急恢复

ETCD是Kubernetes的控制面存储，多数节点失联会导致整个集群不可用。关键应急操作：检查成员健康状态、重建失联成员、极端情况从快照恢复。

# 查看ETCD成员状态
ETCDCTL_API=3 etcdctl member list \
    --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

# 查看ETCD端点健康
ETCDCTL_API=3 etcdctl endpoint health \
    --endpoints=https://etcd1:2379,https://etcd2:2379,https://etcd3:2379 \
    --cacert=/etc/kubernetes/pki/etcd/ca.crt \
    --cert=/etc/kubernetes/pki/etcd/peer.crt \
    --key=/etc/kubernetes/pki/etcd/peer.key

# 从快照恢复（极端场景）
ETCDCTL_API=3 etcdctl snapshot restore /backup/etcd-snapshot.db \
    --data-dir=/var/lib/etcd-restore \
    --name=etcd1 \
    --initial-cluster=etcd1=https://etcd1:2380,etcd2=https://etcd2:2380,etcd3=https://etcd3:2380 \
    --initial-cluster-token=etcd-cluster

混沌工程验证：故障预案的可信度保证

应急预案写好了不等于能用，混沌工程通过主动注入故障来验证系统韧性和响应流程。Chaos Mesh是Kubernetes生态中最成熟的混沌工程工具，支持Pod故障、网络延迟与分区、磁盘压力等故障注入。

# Chaos Mesh安装
kubectl apply -f https://mirrors.chaos-mesh.org/v2.6.1/chaos-mesh.yaml

# Pod Kill混沌实验：验证Deployment自愈能力
apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: pod-kill-test
  namespace: chaos-testing
spec:
  action: pod-kill
  mode: one
  selector:
    namespaces:
      - production
    labelSelectors:
      app: api-server
  scheduler:
    cron: "@every 5m"
  duration: "30s"

---
# 网络延迟注入：验证超时和降级策略
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: network-delay-test
  namespace: chaos-testing
spec:
  action: delay
  mode: all
  selector:
    namespaces:
      - production
    labelSelectors:
      app: api-server
  delay:
    latency: "500ms"
    jitter: "100ms"
  duration: "3m"
  scheduler:
    cron: "0 2 * * *"  # 每天凌晨2点低峰期执行

故障复盘与SOP沉淀

每次P0/P1故障恢复后，24小时内完成复盘。复盘模板包含：故障时间线（发现-响应-定位-恢复）、根因分析（5-Whys法）、影响范围（用户数、请求量、业务损失）、改进措施（短期止血+长期根治）、SOP更新。将排查命令和修复操作沉淀为可执行的Runbook，下次同类故障时直接执行脚本即可。口袋网运维团队采用GitOps管理Runbook仓库，每次复盘后提交更新，确保SOP始终保持最新。