3. 节点池概念：定义、集群关系与升级场景
在 Kubernetes 集群管理中，节点池（Node Pool） 是云原生平台对一组具有相同配置的 Worker 节点进行逻辑分组的管理单元。理解节点池的定义、与集群的关系以及升级场景，是掌握“API 弃用迁移测试在升级节点池自动”课程的基础。
3.1 节点池定义
节点池是集群内一组同质节点的集合，这些节点共享相同的配置模板，包括：
- 计算规格：CPU、内存、GPU 型号
- 系统镜像：操作系统版本、Kubernetes 版本、运行时组件
- 存储配置：系统盘类型、数据盘大小
- 网络设置：安全组规则、子网、弹性 IP 策略
- 弹性伸缩策略：最小/最大节点数、扩缩容阈值
- 标签与污点：用于 Pod 调度亲和性
核心特征：节点池内的所有节点在创建时使用相同的配置模板，但运行过程中可能因升级、修复、扩缩容而产生差异。节点池管理的关键在于保持池内节点配置的一致性。
3.2 节点池与集群的关系
节点池是集群的组成部分，一个集群可以包含多个节点池。它们之间的关系可以用下表概括：
| 维度 | 集群（Cluster） | 节点池（Node Pool） |
|---|---|---|
| 作用范围 | 全局控制面，管理所有节点和 Pod | 局部节点分组，管理一组同质节点 |
| 生命周期 | 长期存在，升级需谨慎 | 可独立创建、扩缩、升级、删除 |
| 配置粒度 | 控制面组件版本、网络插件 | 节点规格、镜像、Kubelet 参数 |
| 升级影响 | 影响整个集群 API 可用性 | 仅影响该池内节点，可分批进行 |
| 典型用途 | 统一管理所有工作负载 | 分离不同工作负载（如 GPU 池、Spot 池） |
下图展示了集群与节点池的层级关系：
最佳实践：建议将不同工作负载类型（如在线服务、离线任务、GPU 训练）分配到不同的节点池，这样在升级节点池时，可以按业务优先级分批进行，降低整体影响面。
3.3 节点池升级场景
节点池升级是集群运维中最常见的操作之一，主要场景包括：
3.3.1 升级场景分类
| 升级类型 | 触发原因 | 升级内容 | 对 API 的影响 |
|---|---|---|---|
| Kubernetes 版本升级 | K8s 版本 EOL、新功能需求 | kubelet、kube-proxy、容器运行时 | 可能涉及 API 版本弃用 |
| 操作系统镜像升级 | 安全补丁、内核更新 | OS 版本、内核参数、系统包 | 通常无直接影响 |
| 运行时组件升级 | 容器运行时漏洞修复 | containerd / Docker 版本 | 可能影响 Pod 生命周期 |
| 节点配置变更 | 资源规格调整、标签更新 | 实例规格、磁盘、安全组 | 无直接影响 |
3.3.2 升级流程与 API 弃用风险
节点池升级通常采用滚动升级（Rolling Update）策略，流程如下：
- 创建新节点：使用目标配置创建新节点实例
- 节点就绪：新节点加入集群并通过健康检查
- Pod 迁移：将旧节点上的 Pod 驱逐到新节点
- 旧节点下线：确认 Pod 迁移完成后删除旧节点
- 重复步骤 1-4：直到所有节点完成升级
关键风险：当节点池升级涉及 Kubernetes 版本变更时，旧版本 API 可能在新版本中被弃用或移除。如果集群中运行的应用程序仍在使用已弃用的 API 版本，升级后可能导致 Pod 创建失败、资源无法管理等问题。这正是本课程《API 弃用迁移测试在升级节点池自动》要解决的核心问题。
3.3.3 升级策略对比
| 策略 | 描述 | 优势 | 劣势 |
|---|---|---|---|
| 滚动升级 | 逐个替换节点 | 影响最小，可回滚 | 耗时较长 |
| 蓝绿部署 | 创建全新节点池后切换流量 | 切换快，回滚简单 | 资源消耗翻倍 |
| 金丝雀升级 | 先升级少量节点验证 | 风险可控，可观察 | 需要额外监控 |
下图展示了滚动升级过程中节点状态的变化：
3.4 节点池升级与 API 弃用的关联
节点池升级过程中，API 弃用问题主要出现在以下环节：
- kubelet 版本升级：kubelet 与 API Server 的交互可能使用已弃用的 API
- Pod 迁移时资源创建：新节点上调度 Pod 时，如果使用已弃用的 API 版本创建资源，可能失败
- 节点注册与状态上报：节点加入集群时使用的 API 版本可能在新版本中不再支持
- 存储与网络插件：CSI、CNI 插件可能依赖特定 API 版本