2. 集群基础架构

在讨论节点故障定位之前，必须先建立一张清晰的“集群地图”。如果对节点角色、组件协作关系、网络分区和存储挂载方式没有统一认知，后续任何告警分析都会变成盲人摸象。本节从四个维度拆解 Kubernetes 集群的基础架构，为后续故障场景提供坐标参照系。

2.1 节点角色与控制面组件

一个标准 Kubernetes 集群由两类节点构成：控制面节点（Control Plane Nodes）与工作节点（Worker Nodes）。控制面节点负责全局决策与状态管理，工作节点负责运行实际业务容器。需要特别强调的是，在云原生高可用部署中，控制面通常由 3 或 5 个节点组成奇数副本，通过 Raft 协议保证 etcd 数据一致性；而工作节点则根据业务规模弹性伸缩。

控制面核心组件包括：

  • kube-apiserver：所有组件与 CLI 操作的唯一入口，提供 RESTful API，负责认证、授权、准入控制。
  • etcd：分布式键值存储，保存集群全部状态（节点信息、Pod 定义、ConfigMap、Secret 等）。
  • kube-scheduler：监听未调度的 Pod，根据资源请求、亲和性、污点等策略决定 Pod 落在哪个工作节点。
  • kube-controller-manager：运行各类控制器（节点控制器、副本控制器、端点控制器等），持续修正实际状态与期望状态的偏差。

工作节点上运行的核心组件相对精简：

  • kubelet：节点上的“代理”，负责管理 Pod 生命周期、健康检查、上报节点状态。
  • kube-proxy：维护节点上的网络规则，实现 Service 的负载均衡与转发。
  • 容器运行时（Container Runtime）：如 containerd、CRI-O，真正执行容器的创建与销毁。

故障定位提示：当节点状态显示 NotReady 时，优先检查 kubelet 服务是否存活、能否与 apiserver 通信、容器运行时是否响应。这三个组件中任何一个异常，都会导致节点脱离集群管控。

控制面节点（3副本） etcd Raft 一致性存储 kube-apiserver API 唯一入口 kube-scheduler 调度决策 controller-manager 状态修正 工作节点池（弹性伸缩） Worker Node 1 kubelet kube-proxy containerd 运行时 Pod A / Pod B / Pod C Worker Node 2 kubelet kube-proxy containerd 运行时 Pod D / Pod E Worker Node 3 kubelet kube-proxy containerd 运行时 Pod F / Pod G / Pod H kubectl / 控制器 状态上报与指令下发 网络与存储拓扑 CNI 插件（Calico） Pod 网络互通 Service / kube-proxy ClusterIP / NodePort Ingress Controller 七层路由 CSI 存储插件 PV / PVC 动态供给 存储后端：NFS / Ceph RBD / 云盘（EBS/云硬盘） 网络文件系统 / 分布式块存储 / 云厂商持久化磁盘 控制面通信 数据/存储路径

2.2 网络拓扑：Pod 网络、Service 网络与节点网络

集群网络是故障定位中最容易混淆的层次。Kubernetes 实际上存在三层网络，每层故障表现不同：

网络层次 通信范围 典型实现 故障常见表现
节点网络 宿主机之间 物理交换机 / VPC 路由 节点 NotReady、跨节点 Pod 不通
Pod 网络 Pod IP 之间 CNI（Calico、Cilium、Flannel） Pod 间访问超时、DNS 解析失败
Service 网络 ClusterIP 虚拟 IP kube-proxy + iptables/IPVS Service 访问异常、会话保持失效

在排查网络故障时，必须明确当前是哪个层次的问题。例如：kubectl exec 进入 Pod 后 ping 10.244.1.5 不通，可能涉及 Pod 网络或节点网络；而访问 Service 的 ClusterIP 失败，则优先检查 kube-proxy 规则与 Endpoints 列表。

2.3 存储拓扑：PV/PVC 与 CSI 插件

有状态应用（如数据库、消息队列）依赖持久化存储。Kubernetes 通过 PV（PersistentVolume） 与 PVC（PersistentVolumeClaim） 解耦存储供给与业务声明。CSI（Container Storage Interface）插件负责将存储后端挂载到 Pod 中。

存储故障的典型链路如下：

  1. 应用通过 PVC 声明存储需求；
  2. 存储控制器（或动态供给组件）创建 PV 并绑定；
  3. 调度器将 Pod 调度到某节点；
  4. kubelet 调用 CSI 插件执行 NodeStageVolume 与 NodePublishVolume；
  5. 存储卷被挂载到 Pod 的指定路径。

当 Pod 报 FailedMount 错误时，需要依次检查：PVC 是否 Bound、存储后端是否健康、节点与存储网络是否连通、CSI 驱动 Pod 是否正常运行。

实操建议：在集群初始化时，就为节点打上清晰标签（如 node-role.kubernetes.io/control-plane、disktype=ssd、zone=az1），并统一规划 Pod CIDR 与 Service CIDR 网段。这样在故障定位时，可以通过 kubectl get nodes --show-labels 快速缩小排查范围。

2.4 典型故障场景：控制面节点磁盘压力导致 etcd 写入失败

某生产集群出现 Pod 创建超时，kubectl apply 命令长时间无响应。初步检查发现 apiserver 进程仍在运行，但日志中频繁出现：

etcdserver: request timed out
etcdserver: leader changed
wal: sync duration > 1s, dropping to FSync

进一步排查发现，控制面节点的数据盘使用率已达 92%，etcd 的 WAL 日志写入速度严重下降。由于 etcd 是集群状态的唯一来源，其写入延迟直接拖垮了所有控制面操作。

复盘结论：

  • etcd 对磁盘延迟极其敏感，建议使用 SSD 并单独挂载数据盘；
  • 监控必须覆盖控制面节点的磁盘 IO 延迟与空间使用率，而非仅关注 CPU/内存；
  • 当磁盘使用率超过 85% 时，应触发告警并提前清理历史事件或快照数据。

2.5 常见误区与复盘

误区一：认为所有节点角色相同，忽略控制面与工作节点的资源隔离。控制面节点应避免运行高负载业务 Pod，否则 etcd 与 apiserver 可能因资源争抢而响应变慢。

误区二：网络故障排查时，只关注 Pod 网络而忽略节点网络。例如，节点防火墙规则或安全组变更可能导致 kubelet 无法回连 apiserver，此时节点状态会变为 NotReady，但 Pod 网络本身可能正常。

误区三：存储故障只检查 PVC 状态，忽略 CSI 插件自身的运行状态。CSI 控制器或节点插件异常时，即使存储后端正常，挂载操作依然会失败。

← 上一章 📖 返回目录 下一章 →