Kubernetes容器编排故障应急响应与混沌工程实战手册

Kubernetes故障应急响应体系构建

生产环境K8s集群故障不可避免，关键在于响应速度和处置流程的标准化。一个成熟的故障应急体系包含三个核心组件：监控告警（发现问题）、Runbook（标准处置流程）、演练机制（验证有效性）。

监控告警体系的分层设计：

# Prometheus告警规则 - K8s核心组件
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: k8s-critical-alerts
  namespace: monitoring
spec:
  groups:
    - name: k8s-cluster
      rules:
        - alert: NodeNotReady
          expr: kube_node_status_condition{condition="Ready",status="true"} == 0
          for: 3m
          labels:
            severity: critical
          annotations:
            summary: "节点 {{ $labels.node }} 不可达超过3分钟"
            runbook: "https://wiki.internal/runbook/node-not-ready"
        - alert: PodCrashLooping
          expr: rate(kube_pod_container_status_restarts_total[15m]) > 0
          for: 5m
          labels:
            severity: warning
          annotations:
            summary: "Pod {{ $labels.namespace }}/{{ $labels.pod }} 持续重启"
        - alert: PVCostSpaceWarning
          expr: kubelet_volume_stats_available_bytes / kubelet_volume_stats_capacity_bytes < 0.15
          for: 5m
          labels:
            severity: warning
          annotations:
            summary: "PVC {{ $labels.persistentvolumeclaim }} 可用空间不足15%"

故障分级与应急响应流程

按影响范围和业务损失，故障分为P0-P3四级：

# 故障分级标准
P0 - 核心业务完全不可用，影响全部用户
    → 5分钟内响应，30分钟内恢复或降级
    → 示例：API网关全挂、数据库主库宕机

P1 - 核心业务部分降级，影响大量用户
    → 15分钟内响应，1小时内恢复
    → 示例：单个可用区故障、某个核心服务OOM

P2 - 非核心业务异常或影响少量用户
    → 1小时内响应，4小时内恢复
    → 示例：监控组件异常、非核心微服务崩溃

P3 - 潜在风险，暂无业务影响
    → 当日处理
    → 示例：磁盘使用率超70%、证书即将过期

应急响应标准流程：

# 故障处置SOP
1. 告警触发 → OnCall确认（5min内）
2. 创建故障工单 → 通知相关团队
3. 初步定位 → kubectl/logs/metrics 三板斧
4. 止血优先 → 降级/限流/回滚/扩容
5. 根因分析 → 保留现场后深入排查
6. 修复验证 → 灰度恢复全量
7. 复盘文档 → 24小时内输出Post-mortem

高频故障场景的诊断与处置

场景一：Pod一直处于Pending状态

# 诊断步骤
kubectl describe pod <pod-name> -n <namespace>

# 常见原因与处置
# 1. 资源不足：CPU/Memory requests超出节点容量
kubectl top nodes                    # 查看节点资源使用
kubectl describe node <node> | grep -A5 Allocatable
# → 处置：扩容节点 或 降低requests 或 驱逐低优先级Pod

# 2. PVC Pending：StorageClass无可用PV
kubectl get sc                       # 检查StorageClass
kubectl get pv                       # 检查PV绑定状态
# → 处置：检查CSI驱动状态，确认后端存储容量

# 3. 节点选择器/Taint不匹配
kubectl get nodes --show-labels
# → 处置：检查nodeSelector和tolerations配置

场景二：服务间歇性超时

# 排查链路：DNS → Service → Endpoints → Pod → 容器

# 1. 检查DNS解析
dig <service-name>.<namespace>.svc.cluster.local

# 2. 检查Endpoints是否就绪
kubectl get endpoints <service-name> -n <namespace>

# 3. 检查Pod就绪状态
kubectl get pods -l app=<app> -n <namespace> -o wide

# 4. 检查Pod网络连通性
kubectl exec -it debug-pod -- curl -so /dev/null -w '%{http_code}' http://<service>:8080/health

# 5. 检查kube-proxy iptables/ipvs规则
kubectl logs -n kube-system -l component=kube-proxy --tail=100

混沌工程：主动注入故障验证韧性

混沌工程不是"搞破坏"，而是在受控条件下验证系统的容错能力。Chaos Mesh是K8s生态中使用最广泛的混沌工程工具。

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

# 网络延迟注入实验
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: api-latency-injection
  namespace: chaos-testing
spec:
  action: delay
  mode: one
  selector:
    namespaces: ["production"]
    labelSelectors:
      app: order-service
  delay:
    latency: "500ms"
    jitter: "100ms"
    correlation: "50"
  duration: "300s"

# Pod Kill实验
apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: pod-kill-test
  namespace: chaos-testing
spec:
  action: pod-kill
  mode: fixed
  value: "1"
  selector:
    namespaces: ["production"]
    labelSelectors:
      app: payment-service
  scheduler:
    cron: "@every 600s"
  duration: "30s"

CI/CD流水线集成混沌测试

将混沌实验集成到CI/CD流水线，在每次发布前自动验证核心服务的容错能力：

# GitLab CI混沌测试阶段
chaos_test:
  stage: resilience
  image: chaos-mesh/chaos-meshctl:latest
  script:
    - meshctl create -f chaos/network-delay.yaml
    - sleep 60
    - python3 e2e_test.py --timeout=120 --check-slo
    - meshctl delete -f chaos/network-delay.yaml
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
  artifacts:
    reports:
      junit: e2e_report.xml

监控告警体系与日志分析联动

告警与日志的联动是快速定位故障的关键。Prometheus AlertManager触发告警时，自动关联Loki日志查询：

# AlertManager Webhook → 自动触发日志查询
receivers:
  - name: 'auto-log-query'
    webhook_configs:
      - url: 'http://log-query-service:8080/alert'
        send_resolved: true

# 日志查询服务伪代码
@app.route('/alert', methods=['POST'])
def handle_alert():
    alert = request.json['alerts'][0]
    namespace = alert['labels']['namespace']
    pod = alert['labels']['pod']
    # 查询最近10分钟该Pod的错误日志
    query = f'{{namespace="{namespace}", pod="{pod}"}} |~ "error|panic|fatal"'
    logs = loki_query(query, time_range='10m')
    # 将日志追加到故障工单
    create_incident_note(alert, logs)
    return 'ok'

DevOps实践中，这类自动化联动能将故障定位时间从"分钟级"压缩到"秒级"。持续迭代Runbook、定期执行混沌实验、监控告警覆盖率达到95%以上——这三件事做到位，SRE团队才能在故障来临时从容应对。