2. Kubernetes 集群架构基础：控制平面与数据平面、节点角色、核心组件交互
在深入节点池 Chart 版本兼容性验证与回滚策略之前，必须牢固掌握 Kubernetes 集群的底层架构。Kubernetes 集群由两大平面构成：控制平面（Control Plane）与数据平面（Data Plane）。理解这两者的职责划分、节点角色以及核心组件的交互方式，是评估升级风险、设计回滚方案的前提。
2.1 控制平面 vs 数据平面
控制平面是集群的“大脑”，负责全局决策与状态管理；数据平面是集群的“肌肉”，负责运行实际的工作负载。两者的职责对比如下：
| 维度 | 控制平面（Control Plane） | 数据平面（Data Plane） |
|---|---|---|
| 核心职责 | 调度、控制器循环、API 请求处理、集群状态存储 | 运行 Pod、处理容器网络流量、挂载存储卷 |
| 关键组件 | kube-apiserver, kube-controller-manager, kube-scheduler, etcd | kubelet, kube-proxy, 容器运行时（如 containerd） |
| 节点类型 | Master 节点（控制面节点） | Worker 节点（工作节点） |
| 升级影响范围 | 影响集群管理能力、API 可用性、调度决策 | 影响业务 Pod 的运行、网络连通性、存储挂载 |
| 回滚复杂度 | 高（涉及 etcd 数据兼容性、API 版本变更） | 中（主要关注 kubelet 与 apiserver 的版本偏移） |
关键原则：控制平面组件与数据平面组件之间存在严格的版本兼容性约束。升级节点池 Chart 时，必须确保新版本的 kubelet 与当前控制平面的 kube-apiserver 版本差不超过一个次要版本（n-1 策略）。
2.2 节点角色与核心组件
Kubernetes 集群中的每个节点都运行着一组特定的守护进程。根据节点角色不同，组件集合有所差异。
2.2.1 Master 节点（控制面节点）
- kube-apiserver：所有组件交互的网关，提供 RESTful API，是集群的“前端”。
- etcd：分布式键值存储，保存集群所有状态数据（Pod、Service、ConfigMap 等）。
- kube-controller-manager：运行控制器进程（如 Node Controller、Deployment Controller）。
- kube-scheduler：负责将新创建的 Pod 分配到合适的 Worker 节点。
2.2.2 Worker 节点（数据面节点）
- kubelet：节点代理，负责管理 Pod 生命周期，与 apiserver 通信。
- kube-proxy：维护节点上的网络规则，实现 Service 的负载均衡。
- 容器运行时：如 containerd、CRI-O，负责拉取镜像并运行容器。
升级关注点：在节点池 Chart 升级场景中，kubelet 的版本变更直接影响节点与 apiserver 的通信协议。若 kubelet 版本高于 apiserver 版本，可能导致节点注册失败或 Pod 调度异常。
2.3 核心组件交互流程
下图展示了用户通过 kubectl 创建 Deployment 时，控制平面与数据平面各组件的完整交互链路：
2.4 组件版本兼容性矩阵
升级节点池 Chart 时，必须验证 kubelet 版本与集群其他组件的兼容性。以下为 Kubernetes 官方推荐的版本偏移规则：
| 组件 | 允许的版本偏移 | 说明 |
|---|---|---|
| kubelet → kube-apiserver | ≤ 1 个次要版本（n-1） | kubelet 可以比 apiserver 低一个版本，但不能更高 |
| kube-controller-manager → kube-apiserver | ≤ 1 个次要版本 | 控制器管理器必须与 apiserver 同版本或低一个版本 |
| kube-scheduler → kube-apiserver | ≤ 1 个次要版本 | 调度器版本偏移规则同 controller-manager |
| kubectl → kube-apiserver | ± 1 个次要版本 | 客户端可以比 apiserver 高或低一个版本 |
回滚陷阱：如果节点池从 v1.28 升级到 v1.29 后发现问题，需要回滚到 v1.28。此时必须确认控制平面仍然运行 v1.28 或 v1.29。若控制平面已升级到 v1.29，则回滚后的 v1.28 kubelet 仍然兼容（n-1）；若控制平面已升级到 v1.30，则 v1.28 kubelet 将无法注册，回滚失败。
2.5 节点池升级中的组件交互变化
当对特定节点池执行 Chart 版本升级时，以下交互路径会发生变化：
- kubelet 启动参数变更：新 Chart 可能修改 kubelet 的
--node-ip、--max-pods或--kube-reserved等参数。 - kubelet 与 apiserver 的 TLS 握手：证书轮换或加密套件变更可能导致握手失败。
- kube-proxy 模式切换：从 iptables 切换到 IPVS 时，需要验证网络规则是否平滑迁移。
- 容器运行时接口（CRI）版本：kubelet 与 containerd 之间的 gRPC 协议版本必须匹配。
验证策略：在升级节点池前，建议先在一个非生产节点上执行“预升级检查”，通过
kubectl get nodes 观察节点状态，通过 kubectl describe node 查看 kubelet 版本和条件，确保所有组件版本在兼容范围内。