2. Kubernetes 集群基础排障框架

本章构建一套可复用的基础排障框架，覆盖 Pod 状态、Node 健康、网络策略、存储卷挂载及日志聚合五大维度。该框架是后续 GitOps 同步窗口与多租户隔离排障的底层能力。

2.1 Pod 状态分析

Pod 是 Kubernetes 最小调度单元，其状态直接反映应用运行健康度。排障时首先通过 kubectl get pod 查看状态，再结合 kubectl describe pod 与日志定位根因。

2.1.1 Pod 生命周期状态机

状态含义常见原因排障动作
PendingPod 未被调度到 Node资源不足、PVC 未绑定、NodeSelector 不匹配检查 Node 资源、PVC 状态、调度策略
Running至少一个容器正常运行正常状态无需操作，或检查就绪探针
CrashLoopBackOff容器反复崩溃重启应用异常、配置错误、资源 OOM查看容器日志、检查资源限制
ImagePullBackOff镜像拉取失败镜像不存在、仓库认证失败、网络不通验证镜像名与标签、检查 Secret
Error容器启动失败入口命令错误、依赖缺失检查容器启动命令与环境变量
TerminatingPod 正在被删除正常删除流程或卡死强制删除或排查 finalizer
实战口诀：Pending 看调度，CrashLoop 看日志，ImagePull 看仓库，Terminating 看 finalizer。

2.1.2 常见排障命令链

# 快速查看 Pod 状态与重启次数
kubectl get pod -n <namespace> -o wide

# 查看 Pod 详细事件
kubectl describe pod <pod-name> -n <namespace>

# 查看容器标准输出日志
kubectl logs <pod-name> -c <container-name> -n <namespace> --tail=100

# 查看前一个崩溃实例的日志
kubectl logs <pod-name> -c <container-name> -n <namespace> --previous

# 进入容器内部排查
kubectl exec -it <pod-name> -c <container-name> -n <namespace> -- /bin/sh

2.2 Node 健康检查

Node 是集群的计算底座，Node 异常会导致其上所有 Pod 不可用。健康检查应覆盖系统资源、kubelet 状态与内核事件。

2.2.1 Node 状态与条件

Node 条件影响检查命令
ReadyTrue 表示正常，False/Unknown 表示异常kubectl get node
DiskPressure磁盘空间不足，驱逐 Poddf -h 登录 Node
MemoryPressure内存紧张，触发驱逐free -m 登录 Node
PIDPressure进程数超限ps aux | wc -l
NetworkUnavailable网络插件异常检查 CNI 插件 Pod 状态

2.2.2 Node 排障三板斧

  1. 查看 Node 事件：kubectl describe node <node-name> 查看 Conditions 与 Events 段。
  2. 登录 Node 检查系统服务：systemctl status kubelet、journalctl -u kubelet -n 50。
  3. 检查容器运行时：crictl ps、crictl logs <container-id>。
注意：Node 级别排障需要节点访问权限。生产环境建议通过 Node Problem Detector 自动上报异常，减少人工登录。

2.3 网络策略排查

网络策略（NetworkPolicy）控制 Pod 间及 Pod 与外部通信。多租户场景下策略配置错误是常见故障源。

2.3.1 网络策略生效检查流程

# 查看当前 Namespace 下的所有 NetworkPolicy
kubectl get networkpolicy -n <namespace>

# 查看具体策略规则
kubectl describe networkpolicy <policy-name> -n <namespace>

# 使用临时 Pod 测试连通性
kubectl run test-pod --image=busybox -n <namespace> -- sleep 3600
kubectl exec test-pod -n <namespace> -- wget -O- http://<target-svc>:<port>

2.3.2 常见网络策略故障模式

故障现象可能原因排查方向
Pod 间无法通信缺少允许 ingress/egress 规则检查 podSelector 与 namespaceSelector
DNS 解析失败策略阻止了 kube-dns 流量添加允许 UDP 53 端口的规则
外部访问超时egress 规则未放通目标 CIDR检查 ipBlock 配置
策略不生效CNI 插件不支持 NetworkPolicy确认使用 Calico/Cilium 等支持策略的插件

2.4 存储卷挂载问题

存储卷挂载失败会导致 Pod 处于 ContainerCreating 或 CrashLoopBackOff 状态。排障需从 PV/PVC 绑定、存储驱动、挂载路径三个层面展开。

2.4.1 存储卷排障步骤

  1. 检查 PVC 状态：kubectl get pvc -n <namespace>，确保状态为 Bound。
  2. 检查 PV 状态：kubectl get pv，确认 AccessModes 与 StorageClass 匹配。
  3. 查看 Pod 事件：kubectl describe pod <pod-name> 中查找 FailedMount 事件。
  4. 登录 Node 检查挂载点：mount | grep <volume-name>、ls -la /var/lib/kubelet/pods/<pod-uid>/volumes/。
典型案例：PVC 状态为 Pending 时，90% 的原因是 StorageClass 未配置或 Provisioner 不可用。检查 kubectl get storageclass 与 kubectl logs -n kube-system <provisioner-pod>。

2.5 日志收集与聚合基础

日志是排障的核心数据源。基础排障框架要求至少实现节点级日志采集与集中查看能力。

2.5.1 日志采集架构

下图展示基于 DaemonSet 的日志采集架构，每个 Node 运行一个日志代理（如 Filebeat、Fluentd），将容器标准输出日志发送到 Elasticsearch 或 Loki 等后端。

Kubernetes 日志采集架构 Node 1 Pod A (stdout) Pod B (stdout) 日志代理 (DaemonSet) Node 2 Pod C (stdout) Pod D (stdout) 日志代理 (DaemonSet) Node 3 Pod E (stdout) Pod F (stdout) 日志代理 (DaemonSet) 日志聚合后端 Elasticsearch / Loki / ClickHouse Kibana / Grafana

2.5.2 日志查看命令速查

场景命令
查看 Pod 实时日志kubectl logs -f <pod-name> -n <ns>
查看多容器 Pod 指定容器日志kubectl logs <pod-name> -c <container> -n <ns>
查看前一个崩溃实例日志kubectl logs --previous <pod-name> -n <ns>
按标签筛选 Pod 日志kubectl logs -l app=nginx -n <ns>
查看节点系统日志journalctl -u kubelet -n 100 --no-pager
最佳实践：生产集群必须配置日志轮转（logrotate），避免容器日志撑满磁盘。建议在 DaemonSet 日志代理中增加 tail -F /var/log/containers/*.log 采集所有容器日志。

2.6 排障框架总结

基础排障框架强调分层排查：先 Pod 后 Node，先网络后存储，最后通过日志聚合全局视图。下表汇总各维度的核心命令与关注点。

维度核心命令关键关注点
Pod 状态kubectl get/describe podCrashLoopBackOff、ImagePullBackOff
Node 健康kubectl describe nodeReady 状态、DiskPressure、MemoryPressure
网络策略kubectl get networkpolicyingress/egress 规则、CNI 兼容性
存储卷kubectl get pvc/pvPVC 绑定状态、FailedMount 事件
日志聚合kubectl logs + 后端查询日志采集覆盖率、轮转策略
框架使用原则：遇到故障时，按 Pod → Node → 网络 → 存储 → 日志的顺序逐层排查，避免跳跃式排障导致遗漏根因。每层排查时间建议不超过 5 分钟，快速定位后进入下一层或确认根因。
← 上一章 📖 返回目录 下一章 →