Kubernetes 集群故障排查实战指南

可能原因：资源不足（CPU/内存/GPU）、HostPort 冲突、Taints 不匹配或调度策略限制。解决思路包括清理无用 Pod、扩容节点或调整调度参数（如 NodeSelector、Affinity）。

2. Waiting 或 ContainerCreating 状态 这通常意味着 Sandbox 容器无法正常启动。重点查看 Kubelet 日志中的 CNI 网络错误。

journalctl -u kubelet | grep cni

例如，网桥 cni0 配置了错误的 IP 段会导致同步失败。此时可尝试删除网桥让插件重建：

ip link set cni0 down
brctl delbr cni0

此外，镜像拉取超时、私有镜像密钥错误或容器打包问题也是常见诱因。

3. ImagePullBackOff 状态 通常是镜像名称错误或私有仓库权限问题。验证方法是用 docker pull 测试镜像。若是私有镜像，需先创建 Secret：

kubectl create secret docker-registry my-secret \
  --docker-server=DOCKER_REGISTRY_SERVER \
  --docker-username=DOCKER_USER \
  --docker-password=DOCKER_PASSWORD \
  --docker-email=DOCKER_EMAIL

然后在 Pod Spec 中引用：

imagePullSecrets:
- name: my-secret

4. CrashLoopBackOff 状态 容器曾启动但异常退出。优先查看日志和重启次数：

kubectl describe pod <pod-name>
kubectl logs <pod-name>
kubectl logs --previous <pod-name>

关注 OOMKilled 或进程退出码。若日志无果，可 SSH 登录 Node 查看 Kubelet 或 Docker 日志，甚至进入容器内部检查（如 kubectl exec）。

5. Error 状态 通常涉及依赖缺失或权限问题，如 ConfigMap、Secret 不存在，或违反 LimitRange、PodSecurityPolicy 等安全策略。

6. Terminating 或 Unknown 状态 Node 失联后 Pod 不会立即删除。若需强制清理，可使用 --grace-period=0 --force，但需谨慎，尤其是 StatefulSet 管理的 Pod，以防数据丢失。若因 Finalizers 卡住，可通过 kubectl edit 移除相关字段。

系统组件日志分析

当上述常规手段无效时，需要深入底层组件日志。

Kubelet 日志

需 SSH 登录至 Node 节点：

journalctl -l -u kubelet -n 1000

控制平面组件

获取组件 Pod 名称后查看日志：

# Kube-apiserver
PODNAME=$(kubectl -n kube-system get pod -l component=kube-apiserver -o jsonpath='{.items[0].metadata.name}')
kubectl -n kube-system logs $PODNAME --tail 100

# Kube-controller-manager
PODNAME=$(kubectl -n kube-system get pod -l component=kube-controller-manager -o jsonpath='{.items[0].metadata.name}')
kubectl -n kube-system logs $PODNAME --tail 100

# Kube-scheduler
PODNAME=$(kubectl -n kube-system get pod -l component=kube-scheduler -o jsonpath='{.items[0].metadata.name}')
kubectl -n kube-system logs $PODNAME --tail 100

注意：API Server 异常会导致集群不可访问；Controller Manager 或 Scheduler 异常则会影响新 Pod 调度和资源控制器工作。

网络与 DNS

Kube-proxy 通常以 DaemonSet 部署，可通过标签筛选日志：

kubectl -n kube-system get pod -l component=kube-proxy
kubectl -n kube-system logs kube-proxy-xxx

若 Dashboard 出现 CrashLoopBackOff，往往是因为依赖的 kube-dns 启动失败。需同时检查 kubedns、dnsmasq 和 sidecar 三个容器的日志：

kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c kubedns
kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c dnsmasq
kubectl logs --namespace=kube-system $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name) -c sidecar

掌握这些排查路径，基本能覆盖 90% 以上的集群故障场景。关键在于保持冷静，按步骤收集证据，而非盲目操作。