Kubernetes故障排查实战：Pod异常退出诊断与集群级问题定位

Kubernetes容器编排平台在生产环境中承载着大量业务服务，Pod异常退出、节点NotReady、网络不通等问题在日常运维中频繁出现。高效的故障排查需要系统化的诊断方法论和工具链支撑。本文以实际生产故障为线索，梳理从Pod级别到集群级别的诊断流程。

Pod异常退出诊断流程

Pod异常退出是最常见的K8s故障类型。排查的第一步是确定退出状态码和原因。

# 查看Pod状态
kubectl get pods -n production
NAME                     READY   STATUS             RESTARTS   AGE
api-server-7d4f-abc12    0/1     CrashLoopBackOff   7          12m
worker-batch-5e2c-def34  0/1     OOMKilled          0          8m
nginx-ingress-3a1b-ghi56  1/1     Running            0          5h

# 查看Pod详细事件
kubectl describe pod api-server-7d4f-abc12 -n production

# 关键信息在Events部分:
# Warning  BackOff    2m (x5)  kubelet  Back-off restarting failed container
# Normal   Pulled     2m (x6)  kubelet  Container image already present on host
# Normal   Created    2m (x6)  kubelet  Created container api-server
# Normal   Started    2m (x6)  kubelet  Started container api-server

常见的Pod退出状态码及含义：

• Exit Code 0：正常退出，检查是否被探针误判
• Exit Code 1：应用错误，查看容器日志
• Exit Code 137：SIGKILL（128+9），通常是OOMKiller或手动kill
• Exit Code 139：SIGSEGV（128+11），段错误，通常是依赖库版本不兼容
• Exit Code 143：SIGTERM（128+15），正常终止信号，检查preStop钩子

CrashLoopBackOff排查方法

CrashLoopBackOff表示Pod反复崩溃重启。诊断步骤：

# 第一步：查看容器日志
kubectl logs api-server-7d4f-abc12 -n production
kubectl logs api-server-7d4f-abc12 -n production --previous
# --previous 查看上一次崩溃前的日志

# 第二步：检查容器命令和参数
kubectl get pod api-server-7d4f-abc12 -n production -o jsonpath='{.spec.containers[*].command}'
kubectl get pod api-server-7d4f-abc12 -n production -o jsonpath='{.spec.containers[*].args}'

# 第三步：检查环境变量和配置
kubectl exec api-server-7d4f-abc12 -n production -- env | grep DB_

# 第四步：检查资源限制
kubectl get pod api-server-7d4f-abc12 -n production -o jsonpath='{.spec.containers[0].resources}'
# {"limits":{"cpu":"2","memory":"4Gi"},"requests":{"cpu":"500m","memory":"2Gi"}}

实际案例：Java应用启动时OOMKilled。原因是JVM堆内存设置为3Gi，但容器内存限制为4Gi，JVM的Metaspace和线程栈额外占用约1.5Gi，导致总内存超过限制。

# 修复方案：调整JVM参数和容器限制
# 方法1：使用容器感知的JVM参数（JDK 8u191+）
env:
  - name: JAVA_OPTS
    value: "-XX:+UseContainerSupport -XX:MaxRAMPercentage=75.0 -XX:InitialRAMPercentage=50.0"

# 方法2：增大容器内存限制
resources:
  requests:
    cpu: "1"
    memory: "2Gi"
  limits:
    cpu: "4"
    memory: "8Gi"  # 留足JVM非堆内存空间

节点NotReady问题定位

节点状态变为NotReady会导致Pod被驱逐，影响服务可用性。常见原因包括kubelet异常、容器运行时故障、磁盘压力等。

# 查看节点状态
kubectl get nodes
NAME           STATUS                     ROLES    AGE    VERSION
worker-node-1  Ready                      worker   120d   v1.28.4
worker-node-2  Ready,SchedulingDisabled   worker   120d   v1.28.4
worker-node-3  NotReady                   worker   118d   v1.28.4

# 查看节点详细状态和条件
kubectl describe node worker-node-3

# 重点关注Conditions部分:
# Conditions:
#   Type             Status  LastHeartbeatTime
#   MemoryPressure   True    2026-07-29T08:00:00Z
#   DiskPressure     False   2026-07-29T08:00:00Z
#   PIDPressure      False   2026-07-29T08:00:00Z
#   Ready            False   2026-07-29T08:00:00Z
#   Message: Kubelet stopped posting node status

SSH到故障节点进行深入诊断：

# 检查kubelet服务状态
systemctl status kubelet
# 如果kubelet已停止:
systemctl restart kubelet

# 检查kubelet日志
journalctl -u kubelet --since "30 min ago" | tail -50

# 常见错误1: 内存不足导致kubelet被OOMKiller杀死
dmesg | grep -i "oom killed"
# [12345.678] Killed process 2345 (kubelet) total-vm:500000kB

# 常见错误2: 容器运行时不可用
crictl ps  # 检查容器运行时是否响应
systemctl status containerd
systemctl restart containerd

# 常见错误3: 磁盘空间不足
df -h /var/lib/containerd
df -h /var/lib/kubelet
# 清理未使用的容器镜像
crictl rmi --prune

网络连通性诊断

Pod间网络不通是另一类高频故障。诊断需要逐层检查：Pod网络、Service转发、NetworkPolicy策略。

# 步骤1: 在Pod内测试连通性
kubectl exec -it debug-pod -- /bin/sh
# 测试DNS解析
nslookup api-server.production.svc.cluster.local
# 测试TCP连通性
wget -qO- --timeout=3 http://api-server.production.svc.cluster.local:8080/health

# 步骤2: 检查Service和Endpoints
kubectl get svc api-server -n production
kubectl get endpoints api-server -n production
# 如果ENDPOINTS为空，说明没有Pod匹配Service的selector

# 步骤3: 检查NetworkPolicy
kubectl get networkpolicy -n production
# 查看具体策略
kubectl describe networkpolicy deny-all -n production

# 步骤4: 使用临时Pod进行网络诊断
kubectl run netshoot --image=nicolaka/netshoot --rm -it --restart=Never -- /bin/sh
# 在netshoot中执行诊断
ip addr
ip route
tcpdump -i eth0 -nn port 8080
traceroute api-server.production.svc.cluster.local

CNI插件故障排查。以Calico为例：

# 检查calico-node Pod状态
kubectl get pods -n kube-system | grep calico

# 查看calico节点状态
kubectl exec -n kube-system calico-node-xxxx -- calicoctl node status

# 检查BGP对等状态
kubectl exec -n kube-system calico-node-xxxx -- calicoctl node status
# Calico process is running.
# IPv4 BGP status:
# +--------------+---------------+-------+----------+-------------+
# | PEER ADDRESS |   PEER TYPE   | STATE |  SINCE   |     INFO    |
# +--------------+---------------+-------+----------+-------------+
# | 10.0.1.2     | node specific | ESTAB | 06:00:00 | Up 05:00:00 |
# | 10.0.1.3     | node specific | START | 06:00:00 | Connecting  |
# +--------------+---------------+-------+----------+-------------+
# 如果某个节点状态为Connecting，说明BGP会话未建立

监控告警体系配置

建立有效的监控告警体系可以在故障影响用户前发现问题。Prometheus + AlertManager的核心告警规则：

# prometheus-rules.yaml
groups:
- name: kubernetes-alerts
  rules:
  # Pod频繁重启告警
  - alert: PodHighRestartRate
    expr: rate(kube_pod_container_status_restarts_total[15m]) > 0
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "Pod {{ $labels.pod }} 频繁重启"
      description: "命名空间 {{ $labels.namespace }} 中的 Pod {{ $labels.pod }} 在15分钟内重启"

  # 节点内存压力告警
  - alert: NodeMemoryPressure
    expr: kube_node_status_condition{condition="MemoryPressure",status="true"} == 1
    for: 2m
    labels:
      severity: critical
    annotations:
      summary: "节点 {{ $labels.node }} 内存压力"

  # Pod CPU使用率过高
  - alert: PodHighCPU
    expr: sum(rate(container_cpu_usage_seconds_total{container!="POD"}[5m])) by (pod, namespace) / sum(kube_pod_container_resource_limits{resource="cpu"}) by (pod, namespace) > 0.8
    for: 10m
    labels:
      severity: warning
    annotations:
      summary: "Pod {{ $labels.pod }} CPU使用率超过80%"

故障排查是SRE工作的核心能力。建立标准化的诊断流程——从Pod状态码入手，逐层向上排查容器、节点、网络、存储，配合Prometheus监控指标和历史告警数据，可以将平均故障恢复时间（MTTR）显著降低。每个故障案例都应记录到事后复盘文档中，形成团队的知识积累。