Kubernetes生产故障排查：Pod CrashLoopBackOff深度实战

场景

某电商平台Kubernetes集群中，多个Pod持续进入CrashLoopBackOff状态，导致服务不可用。

症状

• kubectl get pods 显示状态为 CrashLoopBackOff
• kubectl describe pod 中 Last State 为 Terminated 且 Reason: Error
• 应用日志中出现 OOMKilled 或 Exit Code 137

诊断

1. 查看Pod详情： bash kubectl describe pod <pod-name> -n <namespace> 关注 Containers.<container>.Last State 和 Events。
2. 检查资源限制： bash kubectl get pod <pod-name> -n <namespace> -o yaml | grep -A 5 resources 确认 limits.memory 是否过小。
3. 查看应用日志： bash kubectl logs <pod-name> -n <namespace> --previous 寻找异常堆栈或错误码。
4. 排查存活探针： yaml # 如果探针配置错误，可能导致容器被误杀 livenessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 5 periodSeconds: 10 检查路径和端口是否正确。

命令

• 临时增加资源限制（仅用于测试，不应在生产直接修改）： bash kubectl patch deployment <deployment> -n <namespace> -p '{"spec":{"template":{"spec":{"containers":[{"name":"<container>","resources":{"limits":{"memory":"512Mi"}}}]}}}}'
• 如果内存不足，建议调整 requests 和 limits。

风险控制

• 修改资源限制前，记录原始配置： bash kubectl get deployment <deployment> -n <namespace> -o yaml > original-deployment.yaml
• 先调整 requests 而不是 limits，避免立即杀死Pod。
• 使用 kubectl rollout pause 暂停回滚，防止自动扩缩容干扰。

回滚

• 如果修改导致更严重问题，回滚到上个版本： bash kubectl rollout undo deployment/<deployment> -n <namespace>
• 或者从备份文件恢复： bash kubectl apply -f original-deployment.yaml

验证

• 检查Pod状态： bash kubectl get pods -n <namespace> | grep <deployment>
• 确认所有Pod为 Running 且 READY 列正常。
• 访问应用健康端点或模拟用户请求。

何时提交OpsGlobal工单

• 当根因不明确（如节点资源竞争、存储故障、跨集群问题）。
• 当需要紧急恢复且内部团队无权限或工具。
• 当问题涉及复杂网络策略或安全上下文。

通过以上步骤，SRE团队可以系统性地解决Pod CrashLoopBackOff问题，并确保生产稳定性。

SEO标题

Kubernetes生产故障排查：Pod CrashLoopBackOff实战 | OpsGlobal

SEO描述

学习如何诊断和解决Kubernetes Pod CrashLoopBackOff问题，包括资源限制、健康检查、日志分析及恢复步骤。

标签

Kubernetes故障排查, CrashLoopBackOff, Pod调试, SRE实战