Kubernetes 生产环境排障实录：典型故障案例与诊断方法论
Kubernetes 生产环境排障实录：典型故障案例与诊断方法论
一、引言痛点：K8s 故障为何难以定位
Kubernetes 已成为云原生时代的事实标准，但它的复杂性也带来了独特的故障排查挑战。一个请求失败可能涉及网络、存储、计算、调度等多个层面，而 K8s 的分层抽象和组件众多使得问题定位变得困难。
相比传统运维，K8s 故障排查需要掌握更多的工具和方法。在 K8s 中，故障可能发生在 Pod 层面、Service 层面、Ingress 层面、NetworkPolicy 层面，甚至是云厂商的负载均衡器层面。
本文将系统复盘 K8s 生产环境的典型故障案例，从 Pod 启动失败、Service 无法访问、到网络分区故障，提供完整的诊断思路和解决路径。
二、K8s 故障诊断框架
2.1 故障定位决策树
flowchart TD A[请求失败] --> B{Pod 是否 Running?} B -->|否| C[Pod 启动失败] B -->|是| D{Pod 是否在 Endpoint 中?} D -->|否| E[Selector 不匹配] D -->|是| F{网络连通性?} F -->|否| G[网络策略/防火墙] F -->|是| H{应用正常?} H -->|否| I[应用日志分析] H -->|是| J[上游服务故障] C --> C1{kubectl describe} C1 --> C2[事件信息] C2 --> C3{ExitCode?} C3 -->|非零| C4[应用错误] C3 -->|137| C5[OOMKilled] C3 -->|128| C6[镜像拉取失败] style C5 fill:#ffcdd2 style C4 fill:#ffecb32.2 核心诊断命令速查
# 1. Pod 状态检查 kubectl get pods -n <namespace> -o wide kubectl describe pod <pod-name> -n <namespace> kubectl logs <pod-name> -n <namespace> --previous # 上一个容器的日志 # 2. Service 连通性检查 kubectl get endpoints <service-name> -n <namespace> kubectl get svc <service-name> -n <namespace> kubectl get networkpolicies -n <namespace> # 3. 节点状态检查 kubectl get nodes -o wide kubectl describe node <node-name> kubectl top node <node-name> # 需要 metrics-server # 4. 事件总览 kubectl get events -n <namespace> --sort-by='.lastTimestamp' # 5. 资源配额检查 kubectl describe resourcequota -n <namespace> kubectl describe limitrange -n <namespace>三、典型故障案例复盘
3.1 案例一：Pod OOMKilled
# 故障现象 # Pod 状态为 Running，但立即被终止，RestartCount 持续增加 # 诊断步骤 $ kubectl get pod memory-intensive-app -n production NAME READY STATUS RESTARTS AGE memory-intensive-app 0/1 OOMKilled 5 10m $ kubectl describe pod memory-intensive-app -n production ... Last State: Terminated Reason: OOMKilled Exit Code: 137 Started: Mon, 01 Jan 2024 10:00:00 +0000 Finished: Mon, 01 Jan 2024 10:00:30 +0000 # 检查资源限制配置 $ kubectl get pod memory-intensive-app -n production -o jsonpath='{.spec.containers[0].resources}' {"limits":{"memory":"256Mi"},"requests":{"memory":"128Mi"}} # 解决方案： # 1. 确认应用真实内存需求 # 2. 调整 limits.memory 到合理值 # 3. 优化应用内存使用# 修复后的资源配置 apiVersion: v1 kind: Pod metadata: name: memory-intensive-app namespace: production spec: containers: - name: app image: memory-intensive:latest resources: requests: memory: "512Mi" # 调整 requests limits: memory: "1Gi" # 设置合理的 limits # 建议 limits 不要超过 node 可用内存的 80%3.2 案例二：Service 无法访问
# 故障现象 # 从 Pod 内访问 Service 失败，但 Service 存在 # 诊断步骤 $ kubectl get svc -n production NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) my-service ClusterIP 10.96.0.100 <none> 8080/TCP # 检查 Endpoints（关键！） $ kubectl get endpoints my-service -n production NAME ENDPOINTS AGE my-service 10.244.1.15:8080,10.244.2.20:8080 1d # 如果 ENDPOINTS 为空，说明 selector 没有匹配到任何 Pod # 检查 Pod 的 labels $ kubectl get pods -n production --show-labels | grep my-app my-app-pod-1 1/1 Running ... app=my-app,version=v1 my-app-pod-2 1/1 Running ... app=my-app,version=v1 # 检查 Service 的 selector $ kubectl get svc my-service -n production -o jsonpath='{.spec.selector}' {"app":"my-app"} # 发现问题：Pod labels 是 app=my-app，但版本 label 不一致 # 进一步测试 DNS 解析 $ kubectl run dnsutils -n production --image=tutum/dnsutils -- sleep 3600 $ kubectl exec -it dnsutils -n production -- nslookup my-service.production.svc.cluster.local # 解决方案：修复 selector 或 Pod labels 使其匹配3.3 案例三：镜像拉取失败
# 故障现象 # Pod 一直处于 ContainerCreating 状态 $ kubectl describe pod my-app -n production ... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning Failed 2m kubelet Failed to pull image "registry.example.com/my-app:v2": Error response from daemon: pull access denied, repository does not exist or may require authorization: denied: requested access to the resource is denied # 诊断步骤 # 1. 检查镜像地址是否正确 # 2. 检查 ImagePullSecret 是否配置 # 3. 检查 SA 的 imagePullSecrets $ kubectl get pod my-app -n production -o jsonpath='{.spec.imagePullSecrets}' [{"name":"regcred"}] $ kubectl get secret regcred -n production --output="jsonpath={.data.\.dockerconfigjson}" | base64 -d # 解决方案 # 1. 确认 Secret 中的凭证有效 # 2. 创建新的 Secret kubectl create secret docker-registry regcred \ --docker-server=registry.example.com \ --docker-username=<user> \ --docker-password=<password> \ --namespace=production # 3. 关联到 ServiceAccount kubectl patch serviceaccount default -n production \ -p '{"imagePullSecrets":[{"name":"regcred"}]}'3.4 案例四：网络策略导致的通信中断
# 故障现象 # 服务间通信突然中断，但 Pod 和 Service 都正常 # 诊断步骤 $ kubectl get networkpolicies -n production NAME POD-SELECTOR AGE deny-all <none> 30d allow-frontend app=frontend 30d # 检查 deny-all 策略 $ kubectl get networkpolicy deny-all -n production -o yaml # 发现问题：deny-all 策略阻止了所有流量，但没有相应的 allow 规则允许后端通信 # 解决方案：添加允许规则 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-backend namespace: production spec: podSelector: matchLabels: app: backend policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: app: frontend ports: - protocol: TCP port: 8080四、生产级监控与预警
4.1 关键监控指标
# Prometheus 告警规则 apiVersion: monitoring.coreos.com/v1 kind: PrometheusRule metadata: name: k8s-critical-alerts namespace: monitoring spec: groups: - name: k8s.pod.status rules: - alert: PodNotReady expr: | kube_pod_status_phase{phase=~"Pending|Unknown"} > 0 for: 5m labels: severity: critical annotations: summary: "Pod 处于非就绪状态超过 5 分钟" - alert: PodRestartingTooMuch expr: | rate(kube_pod_container_status_restarts_total[15m]) > 0.1 for: 5m labels: severity: warning annotations: summary: "Pod 重启过于频繁" - alert: PodOOMKilled expr: | kube_pod_container_status_last_terminated_reason{reason="OOMKilled"} > 0 for: 0m labels: severity: warning annotations: summary: "Pod 因 OOM 被终止"4.2 日志聚合架构
flowchart TD A[应用日志] --> B[Fluent Bit] B --> C[Fluentd] C --> D[Elasticsearch] D --> E[Kibana] F[集群事件] --> G[EventRouter] G --> C五、总结
K8s 故障排查的核心是系统化的诊断方法。核心要点可以归纳为三点：
第一，从症状到根因的逐步验证。使用决策树结构化诊断流程，从 Pod 状态到网络连通性逐层排查。
第二，善用 K8s 内建工具。kubectl describe、kubectl logs、kubectl events 是诊断的基础。
第三，预防优于排查。完善的监控预警和日志聚合可以让故障在发生初期就被发现。
K8s 的复杂性是双刃剑：它提供了强大的编排能力，但也需要运维团队具备相应的诊断能力。