#集群节点规划

集群使用 Kubernetes 节点角色标签 node-role.kubernetes.io/<role> 为节点分配不同的角色。为便于描述，我们将这类标签称为角色标签。

默认情况下，集群包含两种类型的节点：控制平面节点和工作节点，分别用于承载控制平面工作负载和应用工作负载。

在集群中：

• 控制平面节点带有角色标签 node-role.kubernetes.io/control-plane。

  注意：

  在 Kubernetes v1.24 之前，Community 也使用标签 node-role.kubernetes.io/master 标记控制平面节点。为保持向后兼容，这两个标签均被视为有效的控制平面节点标识。

• 默认情况下，工作节点没有角色标签。不过，您也可以根据需要显式为工作节点分配角色标签 node-role.kubernetes.io/worker。

除了这些默认角色标签外，您还可以在工作节点上定义自定义角色标签，进一步将它们划分为不同的功能类型。例如：

• 您可以添加角色标签 node-role.kubernetes.io/infra，将节点指定为用于承载基础设施组件的基础设施节点。

• 您可以添加角色标签 node-role.kubernetes.io/log，将节点指定为日志节点，专门用于承载日志组件。

本文将指导您创建基础设施节点和自定义角色节点，并将工作负载迁移到这些节点。

#在非不可变集群上创建基础设施节点

默认情况下，集群仅包含控制平面节点和工作节点。如果您想将某些工作节点指定为专门用于承载基础设施组件的基础设施节点，则需要手动为这些节点添加相应的角色标签和污点。

注意：

本节中的操作仅适用于非不可变集群。也就是说，以下操作不支持在云集群（例如通过 Alauda Container Platform EKS Provider 集群插件部署的 EKS 托管集群）、第三方集群，或节点使用不可变 OS 的集群上执行。

#添加基础设施节点

#步骤 1：为 Node 资源添加基础设施角色标签

kubectl label nodes 192.168.143.133 node-role.kubernetes.io/infra="" --overwrite

此命令为 Node 192.168.143.133 添加基础设施角色标签：node-role.kubernetes.io/infra: ""，表示该节点是基础设施节点。

#步骤 2：为 Node 资源添加污点

添加污点，以防止其他工作负载被调度到基础设施节点上。

kubectl taint nodes 192.168.143.133 node-role.kubernetes.io/infra=reserved:NoSchedule

此命令为 Node 192.168.143.133 添加污点 node-role.kubernetes.io/infra=reserved:NoSchedule，表示只有能够容忍此污点的应用才能被调度到该节点上。

#步骤 3：验证标签和污点

检查节点是否已分配基础设施角色标签和污点：

# kubectl describe node 192.168.143.133
Name:               192.168.143.133
Roles:              infra
Labels:             node-role.kubernetes.io/infra=""
                    ...
Taints:             node-role.kubernetes.io/infra=reserved:NoSchedule

输出表明，Node 192.168.143.133 已配置为基础设施节点，并已添加污点 node-role.kubernetes.io/infra=reserved:NoSchedule。

#在 Immutable 集群上创建基础设施节点

对于节点运行不可变 OS（Alauda OS）的集群，请勿手动向 Node 资源应用角色标签或污点：此架构中的节点会被替换而不是修改，因此应用于单个 Node 的任何配置都会在下一次节点替换时消失。请改为在节点池资源上声明标签和污点，这样节点池创建的每个节点（包括替换节点）都会携带这些配置。

• 业务节点池在 MachineDeployment.spec.template.spec.taints 中声明污点，并在机器模板上声明标签；控制平面节点池使用 KubeadmControlPlane.spec.machineTemplate。完整的操作步骤（包括在 capi-controller-manager 上设置标签同步配置，以便 Machine 标签能够传递到 Node）请参阅 配置节点上的注解、标签和污点。
• 如果专用节点池还必须接收 worker 机器配置（时区、时间同步以及其他由 MachineConfig 管理的设置），则除了自身的角色标签之外，还需要 node-role.kubernetes.io/worker 标签：默认 worker MachineConfigPool 会根据该标签选择节点，而没有此标签的节点将不会收到任何机器配置，且不会显示任何提示。
• 角色标签本身遵循上述各节中的相同约定，即 node-role.kubernetes.io/infra、node-role.kubernetes.io/log 等；污点 node-role.kubernetes.io/<role>=reserved:NoSchedule 的工作方式也相同。

在单集群部署中，global 集群同时作为业务集群是一种受支持的部署形式；其节点规划遵循与其他同等规模集群相同的规则。

#将 Pod 迁移到基础设施节点

如果希望将特定 Pod 调度到基础设施节点上，则需要进行以下配置：

• 将 infra 角色标签作为目标的 nodeSelector。
• 为基础设施节点的污点配置相应的容忍度。

下面是一个配置为在基础设施节点上运行的 Deployment 清单示例。

apiVersion: apps/v1
kind: Pod
metadata:
  name: infra-pod-demo
  namespace: default
spec:
  ...
  nodeSelector:
    node-role.kubernetes.io/infra: ""
  tolerations:
  - effect: NoSchedule
    key: node-role.kubernetes.io/infra
    value: reserved
    operator: Equal
  ...

nodeSelector 确保 Pod 只会被调度到带有标签 node-role.kubernetes.io/infra: "" 的节点上；
容忍度允许 Pod 容忍污点 node-role.kubernetes.io/infra=reserved:NoSchedule 。

完成这些配置后，Pod 将被调度到基础设施节点上。

注意：

将通过 OLM Operators 或集群插件安装的 Pod 迁移到基础设施节点并不总是可行。能否迁移这些 Pod 取决于各个 Operator 或集群插件的配置。

#自定义节点规划

除了基础设施节点外，您还可以根据其他专用用途指定工作节点，例如托管日志组件、存储服务或监控 agent。

您可以为工作节点分配更多自定义角色标签和相应的污点，从而将其有效转换为自定义角色节点。

#定义自定义角色节点的一般步骤

该操作步骤与创建基础设施节点类似。

#步骤 1：添加自定义角色标签

kubectl label nodes <node> node-role.kubernetes.io/<role>="" --overwrite

将 <role> 替换为所需的角色名称，例如 monitoring、storage 或 log。

#步骤 2：添加相应的污点

kubectl taint nodes <node> node-role.kubernetes.io/<role>=<value>:NoSchedule

将 <role> 替换为自定义角色名称，并将 <value> 替换为有意义的描述符，例如 reserved 或 dedicated。该值为可选项，但有助于文档记录和明确含义。

#步骤 3：验证配置

kubectl describe node <node>

确保 Labels 和 Taints 字段反映您的自定义角色配置。

#示例：创建专用于日志组件的节点

如果您希望创建专门用于安装日志组件的节点，可以添加 log 角色。在此情况下，请按如下方式创建 log 节点。

#步骤 1：添加 log 角色标签

kubectl label nodes 192.168.143.133 node-role.kubernetes.io/log="" --overwrite

此标签表示该节点专用于与日志相关的工作负载。

#步骤 2：为节点添加污点

kubectl taint nodes 192.168.143.133 node-role.kubernetes.io/log=reserved:NoSchedule

此污点可防止未调度的工作负载部署到该节点。

#步骤 3：验证标签和污点

Name:               192.168.143.133
Roles:              log
Labels:             node-role.kubernetes.io/log=reserved
                    ...
Taints:             node-role.kubernetes.io/log=reserved:NoSchedule

这确认该节点已成功配置为带有适当标签和污点的 log 节点。

通过遵循上述做法，您可以根据 Kubernetes 节点的预期用途对其进行有效分区，改善工作负载隔离，并确保将特定组件部署到配置适当的节点上。