Kubernetes集群健康检查：SRE工作的第一道防线

Kubernetes集群的稳定性运维从健康检查开始。一个完整的健康检查体系覆盖三层：节点级、Pod级、服务级。节点级检查依赖Node Condition机制，核心关注Ready、MemoryPressure、DiskPressure、NetworkUnavailable四个条件。SRE团队需要做的不是盯Kubernetes自带的Status字段，而是建立主动探测+告警的闭环。

节点健康检查的自动化脚本，配合Prometheus Node Exporter指标：

# node_health_check.yaml
apiVersion: batch/v1
kind: CronJob
metadata:
  name: node-health-check
  namespace: monitoring
spec:
  schedule: "*/5 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          serviceAccountName: node-checker
          containers:
          - name: checker
            image: bitnami/kubectl:latest
            command:
            - /bin/bash
            - -c
            - |
              NOT_READY=$(kubectl get nodes --no-headers | grep -v Ready | awk '{print $1}')
              if [ -n "$NOT_READY" ]; then
                echo "ALERT: NotReady nodes: $NOT_READY"
                for node in $NOT_READY; do
                  kubectl describe node $node | grep -A5 "Conditions"
                done
              fi
              kubectl get nodes -o json | jq -r '.items[] |
                select(.status.conditions[] | select(.type=="DiskPressure" and .status=="True")) |
                .metadata.name' | while read node; do
                echo "ALERT: DiskPressure on $node"
              done
          restartPolicy: OnFailure

Pod级健康检查必须配置livenessProbe和readinessProbe，这是很多团队容易遗漏的。没有readinessProbe的Pod在启动慢的应用（如Java Spring Boot）中会导致流量打到还没初始化完成的服务上，瞬间大量5xx。最佳实践：

# Pod健康探针配置
livenessProbe:
  httpGet:
    path: /actuator/health/liveness
    port: 8080
  initialDelaySeconds: 60
  periodSeconds: 15
  failureThreshold: 3
readinessProbe:
  httpGet:
    path: /actuator/health/readiness
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10
  failureThreshold: 3
startupProbe:
  httpGet:
    path: /actuator/health/liveness
    port: 8080
  failureThreshold: 30
  periodSeconds: 10

startupProbe是很多人忽视的配置。它与livenessProbe的配合逻辑是：启动阶段只检测startupProbe，通过后才切到livenessProbe。这避免了应用启动慢被livenessProbe误杀的问题。

监控告警体系：从指标定义到告警分级

SRE的监控体系核心是四个黄金信号：延迟（Latency）、流量（Traffic）、错误（Errors）、饱和度（Saturation）。Kubernetes环境下的指标采集链路：cAdvisor → kubelet → Prometheus → Alertmanager → 通知渠道。关键告警规则定义：

# k8s_sre_alerts.yaml
groups:
- name: k8s_sre_critical
  rules:
  - alert: PodCrashLooping
    expr: rate(kube_pod_container_status_restarts_total[15m]) > 0
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "Pod {{ $labels.namespace }}/{{ $labels.pod }} 正在CrashLoop"

  - alert: HighErrorRate
    expr: |
      sum(rate(http_requests_total{code=~"5.."}[5m]))
      / sum(rate(http_requests_total[5m])) > 0.05
    for: 2m
    labels:
      severity: critical
    annotations:
      summary: "5xx错误率超过5%"

  - alert: PodNotScheduled
    expr: kube_pod_status_unschedulable > 0
    for: 10m
    labels:
      severity: warning
    annotations:
      summary: "Pod {{ $labels.pod }} 无法调度"

告警分级的核心原则：Critical级别必须在5分钟内响应，Warning级别30分钟内确认。避免告警风暴的方法是设置for窗口——持续N分钟后才触发，避免瞬时抖动触发无效告警。

混沌工程：用故障注入验证SRE体系的有效性

监控告警建好了，但你怎么知道它在真实故障时能正常工作？答案是混沌工程。Chaos Mesh是Kubernetes生态中最成熟的混沌工程框架，支持Pod故障、网络故障、I/O故障、时间偏移等多种注入类型。

一个典型的混沌工程实验流程：定义稳态假设 → 注入故障 → 观察系统行为 → 验证假设 → 修复改进。

# chaos_experiment.yaml
# 实验场景：随机杀死核心服务的Pod，验证自动恢复能力
apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: service-pod-kill
  namespace: chaos-testing
spec:
  action: pod-kill
  mode: one
  selector:
    namespaces:
      - production
    labelSelectors:
      app: order-service
  scheduler:
    cron: "@every 300s"
  duration: "0s"

网络故障注入用于验证服务降级和熔断策略：

# 网络延迟注入
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: payment-service-latency
  namespace: chaos-testing
spec:
  action: delay
  mode: all
  selector:
    namespaces:
      - production
    labelSelectors:
      app: payment-service
  delay:
    latency: "500ms"
    jitter: "100ms"
  direction: to
  duration: "300s"

混沌工程实验不是一次性操作，而是持续集成到SRE工作流中的常规实践。建议的执行节奏：每周一次小范围实验（单服务级），每月一次跨服务实验（链路级），每季度一次大范围演练（区域级故障模拟）。每次实验后输出报告，记录故障现象、告警触发情况、恢复时间、改进项。

CI/CD流水线中的SRE质量门禁

稳定性工程不只关注线上，还需要前移到发布环节。在CI/CD流水线中加入SRE质量门禁，阻止不符合稳定性标准的版本上线：

# GitLab CI SRE质量门禁
sre_quality_gate:
  stage: validation
  script:
    - |
      MISSING_PROBES=$(kubectl apply --dry-run=client -f deployment.yaml -o json |         jq '.spec.template.spec.containers[] |
        select(.livenessProbe == null or .readinessProbe == null) | .name')
      if [ -n "$MISSING_PROBES" ]; then
        echo "BLOCKED: 以下容器缺少健康探针: $MISSING_PROBES"
        exit 1
      fi
    - |
      NO_LIMITS=$(kubectl apply --dry-run=client -f deployment.yaml -o json |         jq '.spec.template.spec.containers[] |
        select(.resources.limits == null) | .name')
      if [ -n "$NO_LIMITS" ]; then
        echo "BLOCKED: 以下容器未设置资源限制: $NO_LIMITS"
        exit 1
      fi
    - |
      if ! kubectl get pdb -n ${NAMESPACE} ${APP_NAME} &/dev/null; then
        echo "WARN: 未配置PodDisruptionBudget，强烈建议补充"
      fi

SRE稳定性工程不是一套工具，而是一套贯穿集群健康检查、监控告警、混沌工程和CI/CD质量门禁的完整体系。每个环节都在回答同一个问题：系统出了问题，多快能发现、多快能恢复、多大概率不再复发。