3. 节点池API概览:NodePool CRD定义、核心字段与常用操作

在Kubernetes集群生命周期管理中,节点池(NodePool)是承载一组同质化工作节点的逻辑抽象。通过自定义资源定义(CRD),NodePool将节点的配置、扩缩容策略、升级行为与生命周期状态统一暴露为声明式API。理解NodePool CRD的结构是后续进行API弃用检测与自动迁移的基础。

3.1 NodePool CRD 定义与分组

NodePool CRD通常归属于集群管理平台(如KubeOne、Cluster API或自研平台)的自定义API组。以下是一个典型的CRD定义结构:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: nodepools.cluster.example.com
spec:
  group: cluster.example.com
  names:
    kind: NodePool
    plural: nodepools
    singular: nodepool
    shortNames:
      - np
  scope: Namespaced
  versions:
    - name: v1alpha1
      served: true
      storage: false
      schema:
        openAPIV3Schema:
          type: object
          properties:
            # v1alpha1 字段定义
    - name: v1beta1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            # v1beta1 字段定义
    - name: v1
      served: true
      storage: false
      schema:
        openAPIV3Schema:
          type: object
          properties:
            # v1 字段定义
版本演进策略: 在API迁移场景中,storage: true 的版本决定了etcd中实际存储的数据结构。弃用检测的核心任务之一就是识别哪些版本已从 served: true 变为 served: false,并确保存储版本与最新稳定版本一致。

3.2 核心字段详解

NodePool的Spec和Status字段是日常操作与迁移判断的关键。下表列出了各版本中常见的核心字段及其作用:

字段路径 类型 版本引入 说明
spec.replicas integer v1alpha1 期望节点数量,控制节点池规模
spec.template.spec.providerspec object v1alpha1 云提供商特定的节点配置(实例类型、磁盘、网络)
spec.template.spec.kubernetesVersion string v1alpha1 节点池的Kubernetes版本,用于版本管理与升级
spec.strategy.type string v1beta1 升级策略类型:RollingUpdate 或 Recreate
spec.strategy.rollingUpdate.maxSurge intOrString v1beta1 滚动升级时允许超出期望副本数的最大节点数
spec.strategy.rollingUpdate.maxUnavailable intOrString v1beta1 滚动升级时允许不可用的最大节点数
status.readyReplicas integer v1alpha1 当前就绪的节点数量
status.phase string v1beta1 节点池生命周期阶段:Running、Upgrading、Scaling、Failed
status.conditions array v1 节点池当前状态的条件列表,包含 Ready、Degraded 等类型
字段弃用风险: 在v1alpha1中,spec.template.spec.kubernetesVersion 可能被直接替换为 spec.version(v1beta1引入)。如果自动化脚本仍引用旧字段,将导致API校验失败。迁移检测必须覆盖字段路径的变化。

3.3 常用操作与API版本对应关系

不同的节点池操作依赖不同的API版本能力。以下列表展示了从v1alpha1到v1的操作演进:

  • 创建节点池(v1alpha1+): 使用 kubectl apply -f nodepool.yaml,所有版本均支持。
  • 扩缩容(v1alpha1+): 修改 spec.replicas,基础操作在所有版本中保持兼容。
  • 滚动升级(v1beta1+): 需要 spec.strategy 字段支持,v1alpha1仅支持原地替换。
  • 状态条件查询(v1+): 通过 status.conditions 获取细粒度健康状态,v1alpha1仅提供 readyReplicas。
  • 版本升级触发(v1beta1+): 修改 spec.version 或 spec.template.spec.kubernetesVersion,v1统一为 spec.version。

3.4 NodePool 资源关系与生命周期

下面的SVG图展示了NodePool CRD与底层节点、集群控制面以及升级控制器之间的核心关系:

NodePool CRD 资源关系与生命周期 NodePool CR 集群控制面 (Cluster API / KubeOne) 升级控制器 (Upgrade Controller) 节点组 (Machines) 说明: NodePool CR 是声明式配置的中心点,控制面负责校验与持久化,升级控制器负责执行版本迁移,节点组反映实际运行状态。

3.5 多版本字段映射与迁移路径

当API从v1alpha1迁移到v1时,核心字段的路径和语义可能发生变化。下面的SVG图展示了三个版本之间的字段映射关系,帮助理解迁移检测的检查点:

NodePool 多版本字段映射与迁移路径 v1alpha1 (storage: false) spec.replicas spec.template.spec. kubernetesVersion spec.template.spec. providerspec status.readyReplicas v1beta1 (storage: true) spec.replicas spec.version spec.providerSpec status.readyReplicas status.phase v1 (storage: false) spec.replicas spec.version spec.providerRef status.readyReplicas status.conditions
迁移检测要点:
  • 字段重命名: kubernetesVersion → version,providerspec → providerSpec → providerRef。
  • 字段废弃: status.phase 在v1中被 status.conditions 替代,旧版客户端无法读取新版状态。
  • 存储版本锁定: 如果v1beta1是存储版本,所有v1alpha1的CR在被更新时会自动转换,但读取时需注意版本兼容。

3.6 常用操作命令速查

以下命令覆盖了节点池的日常管理,注意API版本参数的使用:

# 列出所有节点池(默认使用首选版本)
kubectl get nodepools

# 使用特定API版本查看节点池
kubectl get nodepools.v1beta1.cluster.example.com -o yaml

# 创建节点池(v1版本)
kubectl apply -f nodepool-v1.yaml

# 更新节点池副本数
kubectl patch nodepool my-pool -p '{"spec":{"replicas":5}}' --type merge

# 查看节点池状态条件(v1+)
kubectl get nodepool my-pool -o jsonpath='{.status.conditions}'

# 删除节点池
kubectl delete nodepool my-pool
版本探测技巧: 使用 kubectl api-resources --api-group=cluster.example.com -o wide 可以查看当前集群中NodePool的可用版本及其存储版本,这是弃用检测的第一步。