3. 节点池概念：Kubernetes 节点池定义、节点池与 NodeSelector/Taints/Tolerations 的关系
3.1 节点池（Node Pool）定义
在 Kubernetes 集群管理中，节点池（Node Pool）是指一组具有相同配置、规格、标签和污点的节点集合。节点池通常由云服务商（如 AKS、EKS、GKE）或集群生命周期管理工具（如 Cluster API）提供，用于简化节点组的扩缩容、升级和配置管理。
节点池的核心特征包括：
- 同质化：同一节点池内的所有节点共享相同的虚拟机规格（CPU/内存）、操作系统版本、容器运行时、数据盘大小及挂载路径。
- 统一标签与污点：节点池创建时自动为每个节点注入预定义的标签（Labels）和污点（Taints），确保调度策略的一致性。
- 独立扩缩容：每个节点池可独立设置最小/最大节点数、自动扩缩容策略，互不影响。
- 滚动升级：节点池支持按批次滚动升级节点镜像或 Kubernetes 版本，降低对工作负载的影响。
📌 节点池 vs. 普通节点组：节点池是云原生语境下的高级抽象，比传统节点组多了自动标签继承、污点传播、版本锁定等能力。在 Helm Chart 回滚场景中，节点池的版本一致性直接影响 Pod 能否被正确调度。
3.2 节点池与 NodeSelector 的关系
NodeSelector 是 Pod 规范中最简单的节点选择约束，它通过键值对匹配节点的标签。节点池自动为节点注入的标签（例如 agentpool=gpuseries、kubernetes.azure.com/scalesetpriority=spot）可直接被 NodeSelector 引用。
| 维度 | 节点池标签示例 | NodeSelector 匹配方式 |
|---|---|---|
| 节点池名称 | agentpool=systempool |
nodeSelector: { agentpool: systempool } |
| 节点规格 | node.kubernetes.io/instance-type: Standard_D4s_v5 |
nodeSelector: { node.kubernetes.io/instance-type: Standard_D4s_v5 } |
| 可用区 | topology.kubernetes.io/zone: us-east-1a |
nodeSelector: { topology.kubernetes.io/zone: us-east-1a } |
| 节点池用途 | pool-type: gpu |
nodeSelector: { pool-type: gpu } |
💡 回滚兼容性提示：当 Helm Chart 回滚到旧版本时，如果旧版本 Pod 的
nodeSelector 引用了某个节点池标签，而该节点池在回滚期间已被删除或重命名，Pod 将陷入 Pending 状态。巡检时应检查节点池标签的持久性。
3.3 节点池与 Taints / Tolerations 的关系
Taints（污点） 是节点对 Pod 的排斥标记，Tolerations（容忍） 是 Pod 对污点的豁免声明。节点池通常会在创建时设置污点，以控制哪些工作负载可以调度到该节点池。
常见的节点池污点策略：
- 系统节点池：通常不设置污点，或设置
CriticalAddonsOnly=true:NoSchedule，仅允许系统组件运行。 - GPU 节点池：设置
nvidia.com/gpu=true:NoSchedule，只有声明了tolerations的 GPU 工作负载才能调度。 - Spot 节点池：设置
spot=true:PreferNoSchedule或spot=true:NoSchedule，容忍中断风险的工作负载才使用。 - 专用节点池：设置
dedicated=myapp:NoExecute，强制只有特定应用可以运行，且不允许其他 Pod 被调度。
⚠️ 回滚风险点：如果 Helm Chart 回滚后，新版本的 Pod 没有声明
tolerations，而目标节点池的污点已变更（例如从 NoSchedule 升级为 NoExecute），Pod 将被驱逐或无法调度。巡检时必须对比 Chart 版本中的 tolerations 与当前节点池污点集合。
3.4 节点池、NodeSelector、Taints/Tolerations 协同工作流
下图展示了节点池如何通过标签和污点与 Pod 调度约束协同工作：
3.5 节点池变更对 Helm 回滚的影响矩阵
下表总结了节点池属性变更后，回滚到旧 Chart 版本可能出现的兼容性问题：
| 节点池属性 | 变更类型 | 回滚影响 | 巡检建议 |
|---|---|---|---|
| 节点池标签 | 删除或重命名 | Pod 因 nodeSelector 无法匹配，Pending |
确认标签是否被其他工作负载依赖 |
| 节点池污点 | 新增 NoSchedule |
旧 Pod 无对应 tolerations，无法调度 |
对比 Chart 中的 tolerations 列表 |
| 节点池污点 | 升级为 NoExecute |
已运行 Pod 被驱逐，新 Pod 无法调度 | 检查 tolerationSeconds 设置 |
| 节点池规格 | 变更实例类型 | 若 nodeSelector 指定了旧规格，调度失败 |
使用更通用的标签（如 pool-type） |
| 节点池删除 | 整个节点池被移除 | 所有依赖该节点池标签/污点的 Pod 无法调度 | 回滚前确认节点池仍存在且可用 |
3.6 最佳实践：节点池感知的 Chart 设计
- 使用抽象标签而非具体标签：在
nodeSelector中使用pool-type: gpu而非agentpool: gpu-pool-v2，避免节点池重命名导致调度失败。 - 声明完整的 Tolerations：在 Helm Chart 的
values.yaml中提供tolerations模板变量，允许运维人员在回滚时注入当前节点池的污点容忍。 - 节点池版本锁定：在 Chart 的
Chart.yaml或values.yaml中记录目标节点池名称和预期标签集合，作为回滚前置检查项。 - 预检脚本：在 Helm 回滚钩子（
pre-rollback）中执行节点池兼容性检查，比对当前节点池标签/污点与 Chart 中定义的调度约束。
🔧 巡检命令示例：
# 查看节点池标签
kubectl get nodes -l agentpool --show-labels
# 查看节点池污点
kubectl get nodes -o json | jq '.items[].spec.taints'
# 检查 Pod 的调度约束
kubectl get pod <pod-name> -o json | jq '.spec.nodeSelector, .spec.tolerations'