Kubernetes 故障排查终极指南：从 Pod 到 Cluster

Kubernetes (K8s) 是现代容器编排的事实标准，但其复杂的架构也让故障排查（Troubleshooting）成为了运维人员的噩梦。当你的 Pod 状态变成了 CrashLoopBackOff，或者 Service 突然访问不通时，该从何下手？

本文将提供一套系统化的排查思路和 checklist，助你快速定位根因。

1. 核心排查思路：自下而上

排查 K8s 问题，建议遵循 Pod -> Controller -> Service -> Network -> Cluster 的顺序。

这是最常见的问题。使用 kubectl get pods 查看状态。

Pod 一直处于 Pending 状态，说明调度失败。

检查 Events: kubectl describe pod <pod-name>
- 资源不足: Insufficient cpu/memory。集群资源耗尽，需扩容节点或调整 Request。
- 节点亲和性不满足: NodeAffinity/Taint。检查 NodeSelector、Affinity 配置，或节点是否有 Taint（污点）而 Pod 未配置 Toleration（容忍）。
- PVC 未绑定: PersistentVolumeClaim is not bound。检查 StorageClass 是否正常，PV 是否充足。

Pod 调度成功，但启动失败或反复重启。

检查日志: kubectl logs <pod-name> [-c <container-name>] --previous
- 应用代码抛出异常退出？
- 配置文件缺失？
- 连接数据库失败？
检查 Liveness Probe: 如果应用启动慢，探针配置的时间太短，K8s 会误判并杀掉 Pod。调整 initialDelaySeconds。
OOMKilled: 内存超限。检查 kubectl describe pod 中的 Last State。需调大 resources.limits.memory 或排查内存泄漏。

镜像拉取失败。

Pod 运行正常，但访问不通。

检查 Endpoints: kubectl get endpoints <service-name>
- 如果 Endpoints 为空，说明 Service 的 selector 没有匹配到任何 Pod，或者 Pod 未通过 Readiness Probe。
检查 Pod IP 连通性: 从另一个 Pod ping 目标 Pod IP。如果 ping 不通，可能是 CNI 插件（Flannel/Calico）故障或节点间防火墙/安全组限制。

测试: kubectl exec -it <pod> -- nslookup <service-name>
排查 CoreDNS: 检查 kube-system 命名空间下的 CoreDNS Pod 是否正常运行。
检查 resolv.conf: Pod 内的 /etc/resolv.conf nameserver 是否指向了 K8s DNS Service IP。

如果大量 Pod 处于 Unknown 或 NodeLost 状态。

检查节点状态: kubectl get nodes
查看 Kubelet 日志: 登录节点查看 journalctl -u kubelet。
- 常见原因：磁盘满（DiskPressure）、PID 耗尽、Docker/Containerd 僵死。
检查系统资源: dmesg 查看是否有硬件错误或内核恐慌。

工欲善其事，必先利其器。

kubectl-debug: 启动一个挂载了常用工具（curl, dig, tcpdump）的 Ephemeral Container 附加到目标 Pod 上，用于调试 Distroless 等精简镜像。
```
kubectl debug -it <target-pod> --image=nicolaka/netshoot
```
k9s: 交互式终端 UI，能极大提升查看日志、Exec 进入容器的效率。
nsenter: 在宿主机上直接进入容器的命名空间（Namespace）进行网络抓包或调试。

K8s 故障排查的核心在于信息收集。

保持冷静，按图索骥，99% 的问题都能迎刃而解。