3. 节点池概念详解
节点池（Node Pool）是集群中一组具有相同配置、标签、污点和生命周期策略的节点集合。在 Kubernetes 集群升级场景中，节点池是控制升级粒度、实现灰度验证和快速回滚的核心抽象单元。理解节点池的定义、用途及其与节点组的区别，是掌握集群升级 Chart 版本兼容性验证与回滚策略的前提。
3.1 节点池定义
节点池是对一组工作节点（Worker Node）的逻辑抽象，池内所有节点共享以下属性：
- 计算规格：CPU、内存、GPU 型号与数量
- 系统镜像：操作系统版本、内核参数、预装软件
- Kubernetes 版本：kubelet、kube-proxy 版本
- 节点标签（Labels）：用于 Pod 调度亲和性
- 节点污点（Taints）：控制 Pod 是否可调度到该池
- 自动伸缩策略：最小/最大节点数、扩缩容阈值
- 升级策略：滚动升级批次大小、暂停时间、健康检查间隔
关键概念：节点池是集群中“同质节点”的集合。在升级场景中，节点池是升级操作的最小作用域——升级一个节点池不会影响其他池内的节点。
3.2 节点池用途
节点池在集群生命周期管理中承担以下核心职责：
| 用途维度 | 具体说明 | 升级场景价值 |
|---|---|---|
| 版本隔离 | 不同节点池可运行不同 Kubernetes 版本 | 支持金丝雀升级，先升级小规模池验证兼容性 |
| 资源隔离 | 按业务类型分配不同规格节点池 | 升级时只影响特定业务，降低爆炸半径 |
| 灰度验证 | 创建临时节点池运行新版本 Chart | 验证 Chart 版本兼容性后，再升级生产池 |
| 快速回滚 | 保留旧版本节点池作为回滚目标 | 升级失败时，将流量切回旧池，无需重建节点 |
| 自动修复 | 节点池可配置健康检查和自动替换 | 升级过程中自动替换异常节点，保证池内节点一致 |
3.3 节点池与节点组的区别
在 Kubernetes 生态中，“节点组”（Node Group）是更早期的概念，常见于自建集群或早期云厂商托管服务。两者在抽象层级、管理粒度和升级行为上存在显著差异：
| 对比维度 | 节点池（Node Pool） | 节点组（Node Group） |
|---|---|---|
| 抽象层级 | 集群级资源，由集群控制面统一管理 | 基础设施级资源，通常由云厂商实例组管理 |
| 升级粒度 | 支持逐节点滚动升级，可暂停/回滚 | 通常为实例组整体替换，回滚成本高 |
| 版本一致性 | 池内节点版本严格一致，升级时版本可追溯 | 组内节点版本可能因扩缩容产生漂移 |
| 标签/污点管理 | 池级别统一管理，新增节点自动继承 | 需额外工具同步标签，易出现配置漂移 |
| 回滚能力 | 支持保留旧池，流量秒级切回 | 需重建整个实例组，耗时较长 |
| 典型场景 | 云原生托管集群（如 AKS、GKE、TKE） | 自建集群或早期云厂商托管服务 |
最佳实践：在升级场景中，优先使用节点池而非节点组。节点池的版本隔离和保留旧池能力，是实现“验证-升级-回滚”闭环的关键基础设施。
3.4 节点池典型使用场景
以下 SVG 展示了节点池在集群升级中的典型工作流：
3.5 节点池在升级中的关键操作
在集群升级 Chart 版本兼容性验证与回滚策略中，节点池支持以下关键操作：
- 创建临时验证池：从生产池复制配置，仅修改 Kubernetes 版本和 Chart 版本，用于隔离验证。
- 设置升级批次：配置每次升级的节点数量（如 20%），控制升级速度。
- 暂停/继续升级：在验证池升级完成后暂停，等待人工确认兼容性。
- 保留旧池：升级生产池时，不删除旧版本节点池，作为回滚目标。
- 流量切换：通过调整节点标签或污点，将 Pod 流量从旧池切换到新池。
- 回滚执行：升级失败时，将 Pod 调度回旧版本节点池，并销毁新池。
常见陷阱：升级过程中不要立即删除旧版本节点池。即使新版本验证通过，也应保留旧池至少 72 小时，以便在发现延迟性问题时能够快速回滚。
3.6 节点池配置示例
以下是一个典型节点池的 YAML 配置片段，展示了升级相关字段：
apiVersion: cluster.k8s.io/v1alpha1
kind: NodePool
metadata:
name: production-pool-v1-28
namespace: cluster-system
spec:
clusterName: my-cluster
kubernetesVersion: "1.28.3"
nodeCount: 10
minNodeCount: 3
maxNodeCount: 20
nodeLabels:
environment: production
app-version: stable
nodeTaints:
- key: "dedicated"
value: "production"
effect: "NoSchedule"
upgradeStrategy:
type: RollingUpdate
maxUnavailable: 2
maxSurge: 1
pauseAfterBatch: true
healthCheckPeriodSeconds: 30
scalingPolicy:
minNodes: 3
maxNodes: 20
targetCPUUtilization: 80
retainOnUpgrade: true # 升级时保留旧池，用于回滚
关键字段说明：
retainOnUpgrade: true 表示升级后保留旧版本节点池，不自动删除。这是实现快速回滚的核心配置。pauseAfterBatch: true 表示每完成一批节点升级后自动暂停，等待人工确认。
3.7 节点池与 Chart 版本兼容性验证的关系
节点池是 Chart 版本兼容性验证的天然载体。通过创建不同版本的节点池，可以实现：
- 版本矩阵验证：创建多个节点池，分别运行不同 Kubernetes 版本和 Chart 版本组合，验证兼容性。
- 渐进式升级：先升级非关键业务节点池，验证通过后再升级核心业务节点池。
- 回滚验证：在升级前，先验证回滚路径是否可用——确保旧版本节点池能正常接管 Pod。
- 自动化测试：结合 CI/CD 流水线，在临时节点池上自动运行兼容性测试套件。