做 Kubernetes 运维的同学十有八九都遇到过 Pod 各种状态异常的问题。半夜三点收到告警发现 Pod 在 CrashLoopBackOff 里挣扎这种场景估计大家都经历过。本文结合实战经验梳理一套通用的 Pod 故障排查流程帮你快速定位问题。一、先看懂 Pod 状态Pod 的状态是排查的起点不同状态对应不同的排查方向。kubectl get pods -o wide重点关注STATUS和RESTARTS两列状态含义紧急程度CrashLoopBackOff容器持续崩溃重启 立刻处理ImagePullBackOff镜像拉取失败 立刻处理PendingPod 未被调度 30分钟内处理Running 但不健康容器在跑但服务异常 立刻处理Evicted节点资源不足被驱逐 30分钟内处理二、CrashLoopBackOff容器启动失败这是最常见的故障状态背后原因可能有多种。排查步骤1. 查看容器日志最先做# 查看当前日志 kubectl logs pod-name --tail100 # 查看上一次崩溃的日志关键 kubectl logs pod-name --previous # 实时追踪日志 kubectl logs pod-name -f2. 查看 Pod 事件kubectl describe pod pod-name重点看 Events 部分Kubernetes 会在这里给出失败原因的描述。3. 常见根因分析应用启动失败# 典型错误连接数据库超时 Error: Connection refused: mysql-service:3306解决方案检查依赖服务是否就绪配置合理的启动超时时间。OOMKilled内存溢出Exit Code: 137 OOMKilled: true解决方案合理设置 resources limitsExit Code: 137 OOMKilled: true健康检查配置不当livenessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 30 # 关键避免冷启动误杀 periodSeconds: 5 failureThreshold: 3三、ImagePullBackOff镜像拉取失败这个问题排查相对简单。1. 检查镜像地址# 查看 Pod 使用的镜像 kubectl get pod pod-name -o jsonpath{.spec.containers[].image}2. 常见原因原因现象解决方案镜像名拼写错误ErrImagePull修正镜像地址私有仓库无权限ImagePullBackOff配置 imagePullSecrets节点网络不通ImagePullBackOff检查网络策略镜像版本不存在ErrImagePull确认 tag 是否正确3. 私有仓库配置示例# 创建 Secret kubectl create secret docker-registry my-registry \ --docker-serverregistry.example.com \ --docker-usernameadmin \ --docker-passwordxxxxx # Pod 中引用 spec: imagePullSecrets: - name: my-registry四、Pending调度失败Pending 状态说明 Pod 还没被调度到节点上。1. 查看调度原因kubectl describe pod pod-name | grep -A 10 Events常见原因资源不足Insufficient CPU/Memory调度约束不满足nodeSelector、affinity、taints/tolerations 冲突PVC 未绑定存储依赖未就绪2. 节点资源检查kubectl describe node | grep -A 5 Allocated resources3. 污点和容忍度问题# Pod 需要的容忍度 spec: tolerations: - key: disk-pressure operator: Exists effect: NoSchedule五、Running 但不健康Pod 状态显示 Running但服务响应异常。1. 检查探针状态kubectl describe pod pod-name # 看 Containers 下的 Readiness 和 Liveness2. 端口配置核对Service 配置中容易混淆的三个端口字段含义示例portService 暴露端口80targetPort转发到 Pod 的端口8080containerPortPod 内应用监听的端口80803. Service Selector 检查# 查看 Pod 标签 kubectl get pods --show-labels # 查看 Service 的 selector kubectl get svc service-name -o jsonpath{.spec.selector}两者必须匹配否则流量无法到达 Pod。六、实用排查命令清单# 1. 快速定位所有异常 Pod kubectl get pods --field-selectorstatus.phase!Running -A # 2. 查看集群事件按时间排序 kubectl get events --sort-by.lastTimestamp # 3. 进入容器调试 kubectl exec -it pod-name -- sh # 4. 使用调试镜像临时进入 kubectl debug pod-name -it --imagenicolaka/netshoot # 5. 端口转发测试 kubectl port-forward pod-name 8888:8080 # 6. 网络连通性测试 kubectl exec pod-name -- curl -I http://service-name:80七、生产环境建议1. 完善监控告警# Prometheus 告警规则示例 - alert: PodCrashLoop expr: kube_pod_container_status_restarts_total 3 for: 5m labels: severity: critical2. 规范健康检查配置所有服务必须配置readinessProbe和livenessProbe关键服务建议加startupProbe。3. 资源配额规范resources: requests: cpu: 100m memory: 256Mi limits: cpu: 500m memory: 512Mi总结Pod 故障排查的核心是建立清晰的排查路径状态 → 事件 → 日志 → 配置 → 网络按这个顺序逐层排查能解决绝大多数问题。最后说一句转行做运维前期确实会遇到很多没见过的状态但只要掌握了排查方法论很多问题其实没那么可怕。有问题欢迎评论区交流。
Kubernetes Pod 故障排查指南：从状态识别到根因定位的完整实践
做 Kubernetes 运维的同学十有八九都遇到过 Pod 各种状态异常的问题。半夜三点收到告警发现 Pod 在 CrashLoopBackOff 里挣扎这种场景估计大家都经历过。本文结合实战经验梳理一套通用的 Pod 故障排查流程帮你快速定位问题。一、先看懂 Pod 状态Pod 的状态是排查的起点不同状态对应不同的排查方向。kubectl get pods -o wide重点关注STATUS和RESTARTS两列状态含义紧急程度CrashLoopBackOff容器持续崩溃重启 立刻处理ImagePullBackOff镜像拉取失败 立刻处理PendingPod 未被调度 30分钟内处理Running 但不健康容器在跑但服务异常 立刻处理Evicted节点资源不足被驱逐 30分钟内处理二、CrashLoopBackOff容器启动失败这是最常见的故障状态背后原因可能有多种。排查步骤1. 查看容器日志最先做# 查看当前日志 kubectl logs pod-name --tail100 # 查看上一次崩溃的日志关键 kubectl logs pod-name --previous # 实时追踪日志 kubectl logs pod-name -f2. 查看 Pod 事件kubectl describe pod pod-name重点看 Events 部分Kubernetes 会在这里给出失败原因的描述。3. 常见根因分析应用启动失败# 典型错误连接数据库超时 Error: Connection refused: mysql-service:3306解决方案检查依赖服务是否就绪配置合理的启动超时时间。OOMKilled内存溢出Exit Code: 137 OOMKilled: true解决方案合理设置 resources limitsExit Code: 137 OOMKilled: true健康检查配置不当livenessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 30 # 关键避免冷启动误杀 periodSeconds: 5 failureThreshold: 3三、ImagePullBackOff镜像拉取失败这个问题排查相对简单。1. 检查镜像地址# 查看 Pod 使用的镜像 kubectl get pod pod-name -o jsonpath{.spec.containers[].image}2. 常见原因原因现象解决方案镜像名拼写错误ErrImagePull修正镜像地址私有仓库无权限ImagePullBackOff配置 imagePullSecrets节点网络不通ImagePullBackOff检查网络策略镜像版本不存在ErrImagePull确认 tag 是否正确3. 私有仓库配置示例# 创建 Secret kubectl create secret docker-registry my-registry \ --docker-serverregistry.example.com \ --docker-usernameadmin \ --docker-passwordxxxxx # Pod 中引用 spec: imagePullSecrets: - name: my-registry四、Pending调度失败Pending 状态说明 Pod 还没被调度到节点上。1. 查看调度原因kubectl describe pod pod-name | grep -A 10 Events常见原因资源不足Insufficient CPU/Memory调度约束不满足nodeSelector、affinity、taints/tolerations 冲突PVC 未绑定存储依赖未就绪2. 节点资源检查kubectl describe node | grep -A 5 Allocated resources3. 污点和容忍度问题# Pod 需要的容忍度 spec: tolerations: - key: disk-pressure operator: Exists effect: NoSchedule五、Running 但不健康Pod 状态显示 Running但服务响应异常。1. 检查探针状态kubectl describe pod pod-name # 看 Containers 下的 Readiness 和 Liveness2. 端口配置核对Service 配置中容易混淆的三个端口字段含义示例portService 暴露端口80targetPort转发到 Pod 的端口8080containerPortPod 内应用监听的端口80803. Service Selector 检查# 查看 Pod 标签 kubectl get pods --show-labels # 查看 Service 的 selector kubectl get svc service-name -o jsonpath{.spec.selector}两者必须匹配否则流量无法到达 Pod。六、实用排查命令清单# 1. 快速定位所有异常 Pod kubectl get pods --field-selectorstatus.phase!Running -A # 2. 查看集群事件按时间排序 kubectl get events --sort-by.lastTimestamp # 3. 进入容器调试 kubectl exec -it pod-name -- sh # 4. 使用调试镜像临时进入 kubectl debug pod-name -it --imagenicolaka/netshoot # 5. 端口转发测试 kubectl port-forward pod-name 8888:8080 # 6. 网络连通性测试 kubectl exec pod-name -- curl -I http://service-name:80七、生产环境建议1. 完善监控告警# Prometheus 告警规则示例 - alert: PodCrashLoop expr: kube_pod_container_status_restarts_total 3 for: 5m labels: severity: critical2. 规范健康检查配置所有服务必须配置readinessProbe和livenessProbe关键服务建议加startupProbe。3. 资源配额规范resources: requests: cpu: 100m memory: 256Mi limits: cpu: 500m memory: 512Mi总结Pod 故障排查的核心是建立清晰的排查路径状态 → 事件 → 日志 → 配置 → 网络按这个顺序逐层排查能解决绝大多数问题。最后说一句转行做运维前期确实会遇到很多没见过的状态但只要掌握了排查方法论很多问题其实没那么可怕。有问题欢迎评论区交流。
