Kubernetes容器编排故障排查：从Pod崩溃到集群级诊断方法

Kubernetes故障排查的分层方法论

Kubernetes容器编排已成为网站运维和SRE稳定性工程的核心基础设施。但当集群出现异常时，排查路径往往不清晰——Pod CrashLoopBackOff、Service无端点、节点NotReady……每个问题都可能涉及多层组件。本文建立一套从Pod层到集群层的分层诊断体系，配合DevOps实践中的常用工具链，帮助运维人员快速定位K8s故障根因。

Pod层故障：CrashLoopBackOff与ImagePullBackOff

Pod层是最常见的故障发生层。CrashLoopBackOff表示容器启动后反复崩溃，排查步骤：

# 1. 查看Pod状态
kubectl get pods -n <namespace> -o wide

# 2. 查看容器事件
kubectl describe pod <pod-name> -n <namespace>

# 3. 查看容器日志（前一个崩溃的容器）
kubectl logs <pod-name> -n <namespace> --previous

# 4. 进入运行中的容器调试
kubectl exec -it <pod-name> -n <namespace> -- /bin/sh

常见根因：应用启动配置错误（数据库连接串指向错误地址）、健康检查配置不当（readinessProbe超时过短导致容器被反复重启）、资源限制不足（OOMKilled）。

ImagePullBackOff表示镜像拉取失败。排查方向：检查image字段拼写、确认私有镜像仓库的imagePullSecrets是否配置、网络策略是否允许节点访问外部仓库。

Service与Ingress层：流量路由故障

Pod运行正常但服务不可访问，问题通常在Service或Ingress层。Docker自动化部署和CI/CD流水线中这类故障占比很高。

# 检查Service端点
kubectl get endpoints <service-name> -n <namespace>

# 端点为空说明标签选择器匹配失败
kubectl get pods -n <namespace> --show-labels
kubectl describe svc <service-name> -n <namespace> | grep Selector

# 检查Ingress规则
kubectl get ingress -n <namespace>
kubectl describe ingress <ingress-name> -n <namespace>

# 验证Ingress Controller日志
kubectl logs -n ingress-nginx -l app.kubernetes.io/name=ingress-nginx

Service的selector与Pod的labels不匹配是最常见的”静默故障”——不会报错，但流量无法到达后端。建议在CI/CD流水线中加入helm template渲染后的YAML校验步骤，自动检查selector一致性。

节点层故障：NotReady与资源压力

节点NotReady通常由kubelet异常或节点资源耗尽引起。

# 查看节点状态与条件
kubectl get nodes
kubectl describe node <node-name>

# SSH到节点检查kubelet状态
systemctl status kubelet
journalctl -u kubelet --since "10 minutes ago"

# 检查节点资源使用率
kubectl top node <node-name>

# 查看节点上的Pod资源分配
kubectl describe node <node-name> | grep -A 20 "Allocated resources"

磁盘压力（DiskPressure）是节点NotReady的高频原因。当节点磁盘使用率超过85%，kubelet会驱逐Pod并标记节点为不可调度。监控告警体系中应设置75%和85%两级磁盘告警阈值，前者通知清理，后者自动触发扩容。

集群层诊断：etcd与控制平面

当多个节点同时异常或API Server响应变慢，需检查控制平面组件。etcd是K8s的”数据库”，其健康状况直接决定集群可用性。

# 检查etcd集群健康
ETCDCTL_API=3 etcdctl endpoint health   --endpoints=https://127.0.0.1:2379   --cacert=/etc/kubernetes/pki/etcd/ca.crt   --cert=/etc/kubernetes/pki/etcd/server.crt   --key=/etc/kubernetes/pki/etcd/server.key

# 检查etcdleader状态与延迟
ETCDCTL_API=3 etcdctl endpoint status -w table

# API Server资源监控
kubectl get --raw /metrics | grep apiserver_request_duration

etcd磁盘IO延迟超过10ms会影响API Server性能，超过100ms可能导致leader选举超时。混沌工程实践中，可以主动注入etcd网络延迟来验证控制平面的容错能力。

日志分析是K8s故障排查的”最后一公里”。建议使用EFK（Elasticsearch+Fluentd+Kibana）或Loki+Promtail+Grafana方案，集中收集所有Pod和节点日志，配合结构化查询实现秒级检索。监控告警体系需要覆盖Pod重启率、节点NotReady持续时间、etcd磁盘延迟三个核心指标，形成从被动响应到主动预防的完整闭环。