Kubernetes容器编排排障手册：从Pod CrashLoopBackOff到集群级故障诊断

Kubernetes容器编排排障的典型场景

Kubernetes集群跑起来不难，难的是出问题后快速定位。Pod无限重启、Service访问不通、节点NotReady、资源耗尽OOMKilled——这些问题在SRE稳定性工程实践中反复出现。这篇排障手册把K8s运维中最常见的故障模式和诊断方法系统化梳理，遇到问题时可以逐项排查。

Pod CrashLoopBackOff排查路径

CrashLoopBackOff是出现频率最高的Pod异常状态，核心原因是容器进程启动后退出。

诊断流程：

# 查看Pod状态和重启次数
kubectl get pods -n production

# 查看事件
kubectl describe pod <pod-name> -n production

# 查看容器日志（当前容器）
kubectl logs <pod-name> -n production

# 查看上一次崩溃的日志（关键！）
kubectl logs <pod-name> -n production --previous

常见原因及对应处理：

1. 配置错误：环境变量缺失、ConfigMap/Secret未挂载 → 检查describe输出中的Events和Environment
2. 应用启动失败：数据库连接不上、端口被占用 → 看previous日志定位具体报错
3. 存活探针配置过激：initialDelaySeconds太短，应用还没初始化完就被K8s杀掉 → 调大initialDelaySeconds和timeoutSeconds

探针调优示例：

livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10
  timeoutSeconds: 5
  failureThreshold: 3

Pod OOMKilled诊断与资源规划

容器内存使用超过limits限制就会被OOMKilled，restartCount持续增长。

# 查看Pod的资源使用
kubectl top pod <pod-name> -n production

# 查看OOM事件
kubectl get events -n production --field-selector reason=OOMKilling

处理方式：

– 短期：调大resources.limits.memory
– 长期：分析应用内存泄漏，使用pprof或JVM heap dump定位问题代码

资源规划原则：requests按P50使用量设置，limits按P99设置。requests设太大会导致集群调度效率低下，设太小会在资源争抢时被驱逐。

Service与Ingress连通性诊断

Service访问不通是另一个高频问题，排查路径：

# 1. 确认Service有后端Endpoints
kubectl get endpoints <svc-name> -n production

# 2. 无Endpoints → 检查selector标签是否匹配
kubectl get pods -n production -l app=my-app

# 3. 有Endpoints → 从集群内部测试连通性
kubectl run tmp --image=busybox --rm -it --restart=Never -- wget -qO- http://<svc-name>:8080/health

# 4. Ingress问题 → 检查Ingress规则
kubectl describe ingress <ingress-name> -n production

Endpoints为空时，90%的原因是selector标签拼写错误或Pod不在同一namespace。Ingress层面常见问题：IngressClass未指定、TLS证书过期、annotation配置与Ingress Controller不匹配。

节点NotReady与集群级故障

节点状态变成NotReady，意味着Kubelet与API Server通信中断或节点资源耗尽。

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

# 关键看Conditions部分
# Ready=False → Kubelet失联
# MemoryPressure=True → 内存不足
# DiskPressure=True → 磁盘不足

Kubelet失联排查：

# 登录到NotReady节点
systemctl status kubelet
journalctl -u kubelet --since "10 minutes ago"

# 常见原因：证书过期
openssl x509 -in /var/lib/kubelet/pki/kubelet-client-current.pem -checkend 0

磁盘压力排查：

# 查看Docker占用
docker system df

# 清理未使用的镜像和容器
docker system prune -a --volumes -f

混沌工程验证高可用

排障能力需要在日常中持续验证。混沌工程的核心思路：在受控环境下主动注入故障，验证系统的自愈能力。

Chaos Mesh是K8s原生混沌工具：

# 安装Chaos Mesh
kubectl apply -f https://mirrors.chaos-mesh.org/v2.6.0/chaos-mesh.yaml

# 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: my-app
  duration: "30s"

验证指标：Pod是否自动重建、Service是否自动路由到健康副本、P99延迟是否在SLA内。

CI/CD流水线中的自动化健康检查

部署完成后自动验证集群状态，避免人工遗漏：

# 在CI/CD pipeline中添加
- name: smoke-test
  run: |
    kubectl wait --for=condition=ready pod -l app=my-app -n production --timeout=120s
    curl -sf http://<svc-name>/health | jq .status | grep -q "UP"

K8s排障的本质是：从Pod → Service → Node → Cluster逐层排查，利用describe/logs/events/top四个命令获取信息，配合资源配额、探针、网络策略三道防线预防问题。掌握这套方法论，绝大多数K8s故障都能在15分钟内定位到根因。