LinuxKubernetes故障排查教程_Pod异常与网络问题

Pod 异常状态需分层排查：先用 kubectl describe 查看状态与 Events，再查日志和 exec 调试，接着验证节点资源与调度约束，最后逐层检查 CNI、DNS 及 Service 网络连通性。

Pod 一直处于 Pending、CrashLoopBackOff 或 NotReady 状态，通常不是单一原因导致，而是资源、配置、镜像、节点或网络中某一个环节出了问题。快速定位的关键是分层检查：先看 Pod 自身状态和事件，再查容器日志，接着验证节点资源与调度约束，最后聚焦网络连通性与 CNI 插件行为。

看 Pod 状态和 Events 是第一反应

运行 kubectl describe pod -n ，重点关注两块内容：

• Conditions：比如 Initialized=False 可能是 Init 容器失败；Ready=False 说明主容器没通过 readiness probe；ContainersReady=False 表示至少一个容器未就绪
• Events（最实用）：常见提示如 FailedScheduling（资源不足 / 污点不匹配）、ImagePullBackOff（镜像名错 / 私有仓库没 secret）、FailedMount（PV/PVC 绑定失败或权限问题）

如果 Events 里出现 NodeAffinity 或 Taints 相关拒绝信息，要同步检查节点的 taint 和 Pod 的 toleration 配置是否匹配。

查容器日志和 exec 进去诊断

即使 Pod 处于 CrashLoopBackOff，只要它启动过，就能拿到上一次崩溃前的日志：

• kubectl logs -n --previous 查上一轮容器输出
• kubectl logs -n -c 指定多容器中的某一个
• 如果容器还能短暂运行，用 kubectl exec -it -n -- sh 进入调试（注意：有些精简镜像不含 sh，可试 ash 或 /bin/bash）

进容器后优先检查：配置文件 路径是否存在、环境变量 是否注入正确、依赖服务 DNS 是否能解析（nslookup kubernetes.default.svc.cluster.local）、端口 是否被占用（netstat -tuln）。

确认节点资源与调度是否正常

Pod 卡在 Pending，大概率是调度器找不到合适节点。执行以下命令交叉验证：

• kubectl get nodes -o wide 看节点是否 Ready，资源（CPU/Mem）是否充足
• kubectl top nodes 查实时资源使用率（需 metrics-server 已部署）
• kubectl get events --sort-by=.lastTimestamp | tail -20 找集群级调度失败事件
• 检查 Pod 的 resource requests 是否远超节点可用容量，或设置了 nodeSelector 但没有节点打对应 label

临时测试可删掉 resource request/limit 或修改 nodeSelector，看 Pod 是否能成功调度——这能帮你快速隔离是策略问题还是资源问题。

网络不通？从底层 CNI 到 Service 逐层验证

Pod 之间 ping 不通、无法访问 Service、DNS 解析失败，按这个顺序排查：

• Pod IP 层通信：在源 Pod 中 ping 。失败说明 CNI 插件未正确配置（如 calico/node 未运行、flannel 启动失败、kube-proxy 异常）
• DNS 解析：nslookup kubernetes.default.svc.cluster.local。失败先查 CoreDNS Pod 是否 Running，再看其日志（kubectl logs -n kube-system deployment/coredns），并确认 kubelet 的 --cluster-dns 参数指向正确地址
• Service 访问 ：用 ClusterIP + port curl，同时查 kubectl get endpoints 确认 后端 Pod 地址已同步；再查 iptables/ipvs 规则是否生成（kubectl get svc -o wide 对比 endpoint IPs 是否一致）

如果所有 Pod 都无法访问外网，检查节点 host 上的 iptables FORWARD 链是否被 DROP，以及 CNI 插件是否配置了正确的 masquerade 规则。