2. 节点池概念：节点池的定义、节点池与节点组的关系、节点池在集群升级中的作用
2.1 节点池的定义
节点池（Node Pool）是 Kubernetes 集群中一组具有相同配置、规格和标签的节点集合。它是对底层计算资源（虚拟机或物理机）进行逻辑分组和统一管理的抽象层，使得运维人员能够以“池”为单位进行扩缩容、升级和配置变更，而不是逐个操作节点。
节点池的核心属性包括：
- 计算规格：CPU、内存、GPU 等资源配比。
- 镜像版本：节点操作系统及 Kubernetes 组件版本。
- 节点数量：当前池内运行的节点数及扩缩容范围。
- 标签与污点：用于 Pod 调度亲和性/反亲和性控制。
- 子网/可用区：网络拓扑与故障域隔离策略。
实践要点：节点池是集群资源管理的“原子单元”。在大型生产集群中，建议按业务类型、环境（生产/预发/测试）、计算密集型/内存密集型等维度划分不同的节点池，以实现资源隔离和差异化运维。
2.2 节点池与节点组的关系
在 Kubernetes 生态中，“节点池”与“节点组”常被混用，但在不同云厂商和发行版中存在细微差异。下表梳理了二者的核心区别：
| 维度 | 节点池（Node Pool） | 节点组（Node Group） |
|---|---|---|
| 定义范围 | Kubernetes 集群内的逻辑分组，通常由云厂商托管服务（如 AKS、GKE、EKS）提供 | 底层基础设施（如虚拟机规模集、实例组）的抽象，多见于自建集群或 Cluster API 场景 |
| 管理粒度 | 支持节点级配置（标签、污点、升级策略） | 通常以组为单位统一配置，节点级差异化能力较弱 |
| 升级控制 | 支持滚动升级、蓝绿升级、原地升级等多种策略 | 多采用替换升级（先创建新节点，再删除旧节点） |
| 典型场景 | 云原生托管集群（AKS Node Pool、GKE Node Pool） | 自建集群（Kubeadm + 云实例组）、Cluster API MachineDeployment |
| 与 K8s 原生资源关联 | 直接对应 Node 对象，通过标签关联 | 通过 Machine / MachineSet 间接管理 Node |
从架构视角看，节点池是节点组在 Kubernetes 层面的“控制面代理”。节点组负责基础设施的创建与销毁，节点池则负责将节点注册到集群并注入调度策略。二者通过云厂商控制器或 Cluster API 控制器实现联动。
2.3 节点池在集群升级中的作用
节点池是集群升级治理的核心载体。在滚动升级场景中，节点池承担以下关键职责：
- 版本隔离与灰度控制：通过创建不同版本的节点池，实现控制面与数据面、不同业务线的版本解耦。例如，先升级“测试节点池”验证稳定性，再逐步升级“生产节点池”。
- 滚动升级策略执行：节点池内置升级策略参数（最大不可用节点数、升级批次大小、节点排水超时时间），由节点池控制器按策略逐批替换节点。
- Pod 调度重平衡：升级过程中，节点池配合 PodDisruptionBudget（PDB）和节点污点，控制 Pod 的驱逐顺序与迁移目标，避免业务中断。
- 回滚与故障恢复：当升级导致节点异常时，节点池支持快速回滚到上一版本镜像，或通过扩缩容重建节点池。
关键指标：在大型集群（1000+ 节点）中，节点池的升级速度通常受限于“节点排水速率”和“镜像拉取并发数”。建议将节点池规模控制在 200 节点以内，并设置合理的升级批次（如 10% 节点/批次），以平衡升级速度与业务稳定性。
2.4 节点池升级策略对比
不同云厂商和集群管理工具对节点池升级策略的实现存在差异。下表对比了三种主流策略：
| 策略类型 | 执行方式 | 升级速度 | 资源开销 | 业务影响 | 适用场景 |
|---|---|---|---|---|---|
| 滚动升级 | 逐批替换节点，每批先创建新节点，再删除旧节点 | 中等 | 低（仅额外保留 1 批节点） | 低（配合 PDB 可做到零中断） | 生产集群标准升级 |
| 蓝绿升级 | 创建完整的新节点池，切换流量后删除旧节点池 | 快（一次性切换） | 高（双倍节点资源） | 极低（瞬间切换） | 关键业务、合规审计场景 |
| 原地升级 | 在现有节点上替换操作系统或 kubelet 版本 | 快（无需创建新节点） | 极低 | 中等（节点需短暂重启） | 测试环境、边缘集群 |
避坑提示：原地升级虽然速度快、资源开销低，但存在“升级失败后节点不可用”的风险。在生产环境中，建议优先使用滚动升级或蓝绿升级，并确保节点池配置了足够的“最大不可用节点数”余量（通常为 10%~20%）。