Kubernetes容器编排故障诊断实战：从Pod异常到集群级联故障的排查手册

Pod异常状态的分级诊断流程

Kubernetes运维中，Pod异常是最常见也最基础的问题。不同状态码对应完全不同的排查路径，盲目查日志只会浪费时间。以下是按状态分级的诊断流程：

Pending状态：Pod未被调度到任何节点。原因只有两类——资源不足和调度约束。

# 查看调度失败原因
kubectl describe pod <pod-name> -n <namespace> | grep -A20 Events

# 常见输出：
# 0/3 nodes are available: 3 Insufficient cpu
# 0/3 nodes are available: 3 node(s) didn't match node selector

# 资源不足排查
kubectl top nodes  # 查看各节点资源使用率
kubectl describe node <node> | grep -A5 Allocatable  # 查看可分配资源

# 调度约束排查
kubectl get pod <pod-name> -o yaml | grep -A10 affinity
kubectl get pod <pod-name> -o yaml | grep -A5 tolerations

CrashLoopBackOff状态：容器启动后反复崩溃。这是最需要冷静分析的，因为CrashLoop的退避时间会递增，不能靠反复重启解决问题。

# 查看容器退出码
kubectl get pod <pod-name> -o jsonpath='{.status.containerStatuses[0].lastState.terminated.exitCode}'

# 退出码含义：
# 0: 正常退出（可能是健康检查失败导致被杀）
# 1: 应用通用错误
# 137: OOMKilled（内存超限）
# 139: Segfault（段错误）
# 143: SIGTERM（优雅终止超时后被强杀）

# 查看前一次容器的日志（不是当前容器的日志）
kubectl logs <pod-name> --previous

# OOM排查
kubectl describe pod <pod-name> | grep -A5 "Last State"
# 若OOMKilled，检查limits设置与实际内存消耗
kubectl top pod <pod-name> --containers

ImagePullBackOff状态：镜像拉取失败。在企业内网环境通常与镜像仓库认证或网络策略有关。

# 查看详细错误
kubectl describe pod <pod-name> | grep -A5 Events
# 常见：Failed to pull image: rpc error: code = Unknown

# 检查镜像拉取密钥
kubectl get secret <pull-secret> -o yaml
# 验证密钥是否有效
docker login registry.example.com -u <user> -p <token>

Service与Ingress连通性故障的逐层排查

当服务不可达时，从客户端到Pod的链路中任何一层都可能出问题。按照网络分层逐级排查：

第一层：DNS解析

# 从集群内部测试DNS
kubectl run dns-test --image=busybox:1.36 --rm -it --restart=Never -- \
  nslookup <service-name>.<namespace>.svc.cluster.local

# 常见问题：
# 1. CoreDNS Pod异常
kubectl get pods -n kube-system -l k8s-app=kube-dns
# 2. namespace拼写错误
# 3. 自定义DNS配置覆盖了集群DNS
kubectl get cm coredns -n kube-system -o yaml

第二层：Service Endpoints

# 查看Service是否有后端Pod
kubectl get endpoints <service-name> -n <namespace>

# 如果Endpoints为none，说明没有Pod匹配Service的selector
# 对比Service selector和Pod labels
kubectl get svc <service-name> -o jsonpath='{.spec.selector}'
kubectl get pods -l app=<app-name> -n <namespace> --show-labels

第三层：kube-proxy与iptables/IPVS规则

# 检查kube-proxy状态
kubectl get pods -n kube-system -l k8s-app=kube-proxy

# 在节点上查看iptables规则
iptables -t nat -L KUBE-SERVICES | grep <service-cluster-ip>

# IPVS模式查看
ipvsadm -Ln | grep <service-cluster-ip>

第四层：Ingress控制器

# 检查Ingress资源状态
kubectl get ingress -n <namespace>
kubectl describe ingress <ingress-name> -n <namespace>

# 常见问题：
# 1. Ingress class不匹配控制器
# 2. TLS证书过期
# 3. 后端Service端口不匹配
kubectl get ingress <ingress-name> -o yaml | grep -A5 backend

节点NotReady引发的级联故障分析

节点变为NotReady状态后，Kubernetes会启动Pod驱逐流程。如果多个节点同时NotReady，会引发服务大面积不可用。排查重点：

# 查看节点状态和条件
kubectl describe node <node-name> | grep -A10 Conditions

# 关键条件字段：
# Ready=False: kubelet与API Server通信中断
# MemoryPressure=True: 节点内存压力
# DiskPressure=True: 节点磁盘压力
# NetworkUnavailable=True: 节点网络未就绪

# 查看kubelet日志
journalctl -u kubelet --since "10 minutes ago"

# 检查节点资源压力
kubectl describe node <node-name> | grep -A5 "Allocated resources"

节点NotReady的常见根因及处置：

• kubelet进程崩溃：systemctl status kubelet查看状态，检查配置文件是否有语法错误或证书过期
• 磁盘满：df -h检查/var/lib/kubelet和容器运行时目录。docker system prune清理无用镜像和容器
• 网络插件异常：Calico/Flannel Pod重启或配置变更可能导致节点网络中断
• 内核死锁：dmesg查看是否有kernel panic或soft lockup信息

基于eBPF的深度网络诊断

传统排查手段在复杂网络策略场景下可能不够用。eBPF工具可以在内核层面捕获网络包的实际路径：

# 使用kubectl trace在目标节点注入eBPF探针
# 监控Pod网络命名空间的TCP连接
kubectl trace node <node-name> -e "kprobe:tcp_connect"

# 或使用Cilium的Hubble UI可视化服务网格流量
# 部署Hubble
helm install hubble cilium/hubble --set hubble.ui.enabled=true

# 用BPF跟踪iptables丢包点
# 编译BPF程序挂载到tc hook
tc filter add dev eth0 bpf obj drop-trace.o section trace

eBPF方案的优势是零侵入、低开销，可以在生产环境持续运行，捕获间歇性网络问题的现场。但eBPF工具链的部署和调试门槛较高，建议在标准化运维流程中预留eBPF诊断工具的快速部署通道。

混沌工程验证故障响应能力

排查能力需要在实战中锤炼。在生产环境主动注入故障，验证监控告警和应急响应的完整性：

# 使用Chaos Mesh注入Pod故障
apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: pod-failure-test
  namespace: chaos-testing
spec:
  action: pod-failure
  mode: one
  selector:
    namespaces: [production]
    labelSelectors:
      app: critical-service
  duration: "60s"
  scheduler:
    cron: "@weekly"

混沌实验的关键指标：

• 告警触发时间：Pod异常到告警通知到达的时间，目标<2分钟
• 故障定位时间：告警到达后到确认故障根因的时间，目标<5分钟
• 服务恢复时间：从故障发生到服务SLA恢复的时间，目标<10分钟

每个混沌实验后需要做复盘，更新SOP文档和Runbook。故障排查能力的提升不在于记住多少命令，而在于形成系统化的诊断路径和可复用的应急响应流程。