Kubernetes集群故障应急响应实战：从Pod崩溃排查到自动化自愈的SRE实践

Kubernetes故障应急为什么需要标准化流程

在Kubernetes集群中，一次Pod崩溃可能只是冰山一角。如果不按标准流程排查，很容易在表象上打转而错过根因。SRE团队处理K8s故障的核心原则是：快速止血、精准定位、系统修复、防止复发。本文按故障响应的时序阶段，给出一套可直接复用的应急响应操作手册。

第一阶段：5分钟快速止血

故障发生后的前5分钟决定了影响范围的上限。

1. 确认故障范围

# 检查节点状态
kubectl get nodes -o wide

# 检查所有命名空间的Pod状态
kubectl get pods -A --field-selector=status.phase!=Running

# 查看最近5分钟的事件
kubectl get events -A --sort-by='.lastTimestamp'   --field-selector=lastTimestamp>=$(date -u -d '5 min ago' +'%Y-%m-%dT%H:%M:%SZ')

2. 判断故障层级
按以下决策树快速定位故障层级：
– 节点NotReady → 节点层故障（kubelet异常/网络分区/资源耗尽）
– Pod全部CrashLoopBackOff → 应用层故障（镜像/配置/依赖问题）
– Pod Running但服务不可达 → 网络层故障（Service/Ingress/CNI问题）
– 单个Pod异常 → 隔离处理，影响有限

3. 紧急降级与流量切换

# 紧急缩容故障部署
kubectl scale deployment <app> --replicas=0 -n <namespace>

# 切换流量到备用集群（如果配置了多集群）
kubectl patch virtualservice <vs-name> -n istio-system   --type merge -p '{"spec":{"hosts":["*"],"http":[{"route":[{"destination":{"host":"backup-svc","port":80}}]}]}}'

# 或直接修改Service指向健康Pod
kubectl edit svc <svc-name> -n <namespace>

第二阶段：Pod级故障诊断

Pod CrashLoopBackOff是最常见的故障状态，按以下步骤逐层排查：

1. 查看Pod事件和状态

# 查看Pod详细状态
kubectl describe pod <pod-name> -n <namespace>

# 重点看Events部分和Last State
# 常见退码：
#   OOMKilled → 内存超限
#   Error/Exit 1 → 应用启动失败
#   ContainerConfigError → 配置错误
#   ImagePullBackOff → 镜像拉取失败

2. 获取容器日志

# 当前容器日志
kubectl logs <pod-name> -n <namespace> --tail=200

# 上一次崩溃的容器日志（关键！）
kubectl logs <pod-name> -n <namespace> --previous --tail=200

# 多容器Pod指定容器
kubectl logs <pod-name> -n <namespace> -c <container-name> --previous

3. 临时调试容器

当Pod持续崩溃无法进入时，使用Ephemeral Container进行调试：

# K8s 1.25+ 支持临时容器
kubectl debug <pod-name> -n <namespace>   --image=busybox:1.36 --target=<container-name> -it -- /bin/sh

# 或复制Pod进行调试
kubectl debug <pod-name> -n <namespace>   --copy-to=debug-pod --container=debug   --image=busybox:1.36 -it -- /bin/sh

第三阶段：节点级故障诊断

当多个Pod同时异常，且分布在同一节点上时，问题往往在节点层。

1. 节点资源耗尽排查

# 查看节点资源使用
kubectl top nodes

# 查看节点详细资源分配
kubectl describe node <node-name> | grep -A 20 "Allocated resources"

# SSH到节点查看系统资源
ssh <node-ip> "free -h && df -h && top -bn1 | head -20"

# 检查是否有Pod超过资源请求
kubectl get pods -A -o json | jq '.items[] | select(.spec.nodeName=="<node>") | {name: .metadata.name, cpu_req: .spec.containers[].resources.requests.cpu, mem_req: .spec.containers[].resources.requests.memory}'

2. Kubelet异常排查

# 检查kubelet状态
ssh <node-ip> "systemctl status kubelet"

# 查看kubelet日志
ssh <node-ip> "journalctl -u kubelet --since '10 min ago' --no-pager"

# 常见kubelet问题：
# - 证书过期：certificate has expired
# - 磁盘压力：DiskPressure / PIDPressure
# - 网络CNI插件失败：network plugin returns error

3. 驱逐故障节点上的Pod

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

# 驱逐节点上的Pod
kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data --timeout=120s

# 如果drain卡住，强制删除
kubectl delete pod <pod-name> -n <namespace> --force --grace-period=0

第四阶段：网络层故障诊断

Pod运行正常但服务不可达，排查K8s网络链路。

1. Service端点检查

# 检查Service是否有后端端点
kubectl get endpoints <svc-name> -n <namespace>

# 如果Endpoints为空，检查标签选择器
kubectl get pods -n <namespace> --show-labels | grep <selector-key>=<selector-value>

# 常见原因：标签不匹配、Pod不Ready（readinessProbe失败）

2. CoreDNS解析验证

# 创建调试Pod测试DNS
kubectl run dns-test --image=busybox:1.36 --rm -it --restart=Never --   nslookup <svc-name>.<namespace>.svc.cluster.local

# 检查CoreDNS日志
kubectl logs -n kube-system -l k8s-app=kube-dns --tail=50

3. CNI插件排查

# 检查CNI Pod状态
kubectl get pods -n kube-system -l k8s-app=<cni-name>

# 检查网络策略
kubectl get networkpolicies -A

# 验证Pod间网络连通性
kubectl exec <pod-a> -n <namespace> -- curl -s -o /dev/null -w "%{http_code}" http://<pod-b-ip>:8080/health

自动化自愈机制建设

故障响应的最终目标是减少人工介入。以下三种自愈机制应在生产集群中部署：

1. Horizontal Pod Autoscaler（HPA）

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: <app>-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: <app>
  minReplicas: 3
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
    - type: Pods
      pods:
        metric:
          name: http_requests_per_second
        target:
          type: AverageValue
          averageValue: "1000"

2. PodDisruptionBudget（PDB）

防止 voluntary disruption 导致服务不可用：

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: <app>-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: <app>

3. Node Problem Detector + 自愈Controller

部署Node Problem Detector监控节点级异常，配合自愈Controller自动驱逐故障节点上的Pod：

# 部署Node Problem Detector
kubectl apply -f https://raw.githubusercontent.com/kubernetes/node-problem-detector/master/deployment/node-problem-detector.yaml

# 配合Descheduler实现自动重平衡
# 安装Descheduler
kubectl apply -k github.com/kubernetes-sigs/descheduler/manifests/base

故障复盘与防护网

每次故障响应结束后，必须在24小时内完成复盘，输出以下内容：
1. 故障时间线（从发现到完全恢复）
2. 根因分析（5-Why方法）
3. 修复措施（已实施 + 待实施）
4. 防复发措施（监控告警、自愈机制、配置变更）

将复盘结论转化为自动化测试用例，注入混沌工程框架（如Chaos Mesh），定期验证集群的自愈能力。这才是SRE故障应急响应的闭环：不是每次都在救火，而是让系统自己学会灭火。