Kubernetes故障排查：从Pod状态到网络诊断-CFANZ编程社区

在Kubernetes集群运维中，故障排查是日常工作的重要组成部分。从Pod启动失败到服务间通信异常，各种问题层出不穷。掌握系统化的排查方法，能帮助运维人员快速定位根因，减少故障恢复时间。本文将从Pod状态分析入手，逐步深入到网络诊断，结合实战命令和案例，构建完整的Kubernetes故障排查体系。

一、Pod状态分析与常见问题

Pod的状态是排查问题的第一线索，Kubernetes定义了多种状态标识不同的生命周期阶段。

1. Pending状态

Pod停留在Pending状态，说明调度器尚未将其分配到节点。常见原因包括：

资源不足：节点资源无法满足Pod的requests配置

# 查看事件找到具体原因
kubectl describe pod <pod-name> | grep -A 20 "Events:"

# 检查节点资源使用情况
kubectl top node

解决方法：调整Pod的资源requests/limits，或扩容节点资源。

节点亲和性冲突：Pod的亲和性规则无法匹配任何节点

# 问题示例：错误的节点标签选择器
affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: environment
          operator: In
          values:
          - production  # 集群中无此标签的节点

解决方法：修正亲和性规则或为节点添加对应标签。

2. Running但Not Ready

Pod显示Running但就绪探针失败，通常是应用启动失败或健康检查配置问题：

# 查看就绪探针配置
kubectl get pod <pod-name> -o jsonpath='{.spec.containers[0].readinessProbe}'

# 查看容器日志
kubectl logs <pod-name> -c <container-name>

# 进入容器排查
kubectl exec -it <pod-name> -c <container-name> -- sh

常见问题：

就绪探针路径错误（如/health写成/heath）
探针超时时间过短（应用启动慢但探针超时设置为1秒）
应用依赖服务未就绪（如数据库连接失败）

3. CrashLoopBackOff

容器反复启动又崩溃，需重点检查应用退出原因：

# 查看最近一次容器启动日志
kubectl logs <pod-name> -c <container-name> --previous

# 检查退出码（非0表示异常退出）
kubectl get pod <pod-name> -o jsonpath='{.status.containerStatuses[0].lastState.terminated.exitCode}'

典型退出码含义：

137：容器被OOM killer终止（内存超限）
139：段错误（应用程序bug）
255：用户自定义错误码

解决方法：根据日志和退出码修复应用，或调整资源限制。

二、网络故障诊断流程

Kubernetes网络问题涉及Pod间通信、服务发现、外部访问等多个层面。

1. Pod间通信问题

同一集群内Pod无法通信，排查步骤：

# 1. 检查Pod是否正常运行
kubectl get pods -o wide

# 2. 在源Pod中测试到目标Pod的网络连接
kubectl exec -it <source-pod> -- ping <target-pod-ip>
kubectl exec -it <source-pod> -- curl <target-pod-ip>:<port>

# 3. 检查网络策略是否阻止通信
kubectl get networkpolicy -n <namespace>

常见原因：

网络策略配置不当（如默认拒绝入站流量）
CNI插件故障（如Calico节点间路由问题）
容器防火墙规则限制（如iptables规则）

2. Service访问问题

Service无法访问通常涉及服务发现或端点关联问题：

# 1. 检查Service是否关联到正确的端点
kubectl describe service <service-name>

# 2. 验证端点是否正常
kubectl get endpoints <service-name>

# 3. 直接访问端点IP:端口测试
kubectl exec -it <test-pod> -- curl <endpoint-ip>:<port>

若endpoints为空，可能原因：

Pod的标签与Service的selector不匹配
Pod未通过就绪探针检查
命名空间错误（跨命名空间访问需指定namespace）

3. 外部访问问题

Ingress或NodePort无法从外部访问：

# 1. 检查Ingress控制器是否正常运行
kubectl get pods -n ingress-nginx

# 2. 查看Ingress规则配置
kubectl describe ingress <ingress-name>

# 3. 检查节点端口是否监听
kubectl get service <service-name> -o jsonpath='{.spec.ports[0].nodePort}'
ss -tulpn | grep <node-port>

常见问题：

Ingress规则路径或主机名配置错误
云厂商负载均衡器未正确关联
节点安全组未开放对应端口

三、高级诊断工具与技巧

1. 集群层面诊断

# 检查API Server日志
kubectl logs -n kube-system <kube-apiserver-pod>

# 查看控制器管理器状态
kubectl get pods -n kube-system | grep controller-manager

# 检查调度器事件
kubectl logs -n kube-system <kube-scheduler-pod>

2. 节点层面问题排查

当Pod调度到特定节点后出现问题，需检查节点状态：

# 1. 检查节点是否有污点导致Pod无法调度
kubectl describe node <node-name> | grep Taint

# 2. 查看节点是否处于Ready状态
kubectl get node <node-name>

# 3. 登录节点检查容器运行时
ssh <node-ip>
crictl ps  # 查看容器运行状态
crictl logs <container-id>  # 查看容器日志

3. 网络插件诊断

以Calico为例检查网络插件状态：

# 检查Calico节点状态
kubectl get pods -n calico-system

# 查看Calico网络状态
calicoctl node status  # 需要在节点上安装calicoctl

# 检查网络策略生效情况
calicoctl get networkpolicy --all-namespaces

四、故障排查最佳实践

建立排查流程文档：针对常见状态（Pending/CrashLoopBackOff等）制定标准化排查步骤
完善监控与告警：

监控Pod状态变化和重启次数
配置容器OOM、Crash等事件告警
监控网络连通性和Service端点状态

日志集中管理：

收集容器日志、kubelet日志和容器运行时日志
使用ELK或Loki建立日志检索平台
为关键服务配置日志关键字告警

工具链准备：

安装kubectx/kubens快速切换集群和命名空间
使用kube-ps1在终端显示当前集群/命名空间
部署kube-visibility等可视化工具辅助诊断

模拟故障演练：定期进行故障注入测试，验证排查流程有效性

五、典型案例分析

案例1：Pod因PV挂载失败而Pending

现象：Pod长时间Pending，事件显示"FailedMount"

排查过程：

# 查看详细事件
kubectl describe pod <pod-name> | grep -A 10 "FailedMount"

# 发现错误：persistentvolume "pv-data" not found

# 检查PV/PVC状态
kubectl get pv
kubectl get pvc -n <namespace>

原因：PVC绑定的PV不存在，解决方法是创建对应PV或修正PVC的storageClassName。

案例2：Service访问超时

现象：通过Service访问Pod超时，但直接访问Pod IP正常

排查过程：

# 检查Service与Pod标签匹配
kubectl describe service <service-name> | grep Selector
kubectl get pods -l <selector-key>=<selector-value>

# 发现Pod标签错误：app=backend写成app=backed

解决方法：修正Pod的标签或Service的selector。