#Infra Nodes

An infra node is a worker node dedicated to hosting infrastructure components. You create an infra node by giving a worker node the infra role label and a taint, and then move selected components to it.

#Node Roles

A cluster uses Kubernetes node role labels in the format node-role.kubernetes.io/<role> to assign different roles to nodes. In this topic, role label refers to this type of label.

By default, a cluster contains two types of nodes: control plane nodes and worker nodes, used to host control plane workloads and application workloads, respectively.

In a cluster, the control plane nodes are labeled with the role label node-role.kubernetes.io/control-plane.

Note:

Prior to Kubernetes v1.24, the community also used the label node-role.kubernetes.io/master to mark control plane nodes. For backward compatibility, both labels are considered valid for identifying control plane nodes.

For the nodes or node pools that you plan for infrastructure components, such as logging, monitoring, and ingress, use the role label node-role.kubernetes.io/infra. To divide these nodes further, you can define your own roles, for example node-role.kubernetes.io/log or node-role.kubernetes.io/monitor.

Use role labels and taints to create infra nodes or custom role nodes, then move selected workloads to those nodes when workload isolation requires it.

#Create Infra Nodes on Alauda OS Nodes

On an Alauda OS cluster, do not apply role labels or taints to Node resources by hand: nodes on this architecture are replaced rather than mutated, so anything applied to an individual Node disappears with the next node replacement. Declare the labels and taints on the node-pool resources instead — then every node the pool creates, including replacements, carries them.

The following steps declare the infra role on a node pool. To create a node pool, see the Create a Cluster page of your provider: Bare Metal, Huawei DCS, Huawei Cloud Stack, or VMware vSphere.

#Step 1: Declare the Infra Label and the Taint on the Node Pool

Set the label on .spec.template.metadata.labels and the taint on .spec.template.spec.taints of the pool's MachineDeployment. For a control plane pool, set them on .spec.machineTemplate.metadata.labels and .spec.machineTemplate.taints of its KubeadmControlPlane instead. The example shows only the fields that define the infra role; keep the other fields of your MachineDeployment as they are.

apiVersion: cluster.x-k8s.io/v1beta1
kind: MachineDeployment
metadata:
  name: <infra-md-name>
  namespace: <namespace>
spec:
  clusterName: <cluster-name>
  template:
    metadata:
      labels:
        node-role.kubernetes.io/infra: ""
    spec:
      taints:
      - key: node-role.kubernetes.io/infra
        value: reserved
        effect: NoSchedule

Labels and taints that you add or change on the pool's template are applied to the existing nodes of the pool without replacing them.

#Step 2: Verify

After the nodes of the pool register, check that the Node has the infra role label and the taint node-role.kubernetes.io/infra=reserved:NoSchedule, for example with kubectl describe node <node-name>.

A single-cluster deployment in which the global cluster doubles as the workload cluster is a supported deployment form; its node planning follows the same rules as any other cluster of its size.

#Create Infra Nodes on Non-Alauda OS Nodes

By default, a cluster only includes control plane nodes and worker nodes. If you want to designate certain worker nodes as infra nodes dedicated to hosting infrastructure components, you need to manually add the appropriate role label and taint to those nodes.

Note:

The operations in this section apply only to clusters whose nodes run a non-Alauda OS. Do not use these operations for provider-managed cloud clusters, third-party clusters, or clusters whose nodes run Alauda OS.

#Step 1: Add the Infra Role Label to the Node resources

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

This command adds the infra role label to the Node 192.168.143.133: node-role.kubernetes.io/infra: "", indicating that the node is an infra node.

#Step 2: Add a Taint to the Node resources

Add a taint to prevent other workloads from being scheduled onto the infra node.

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

This command adds the taint node-role.kubernetes.io/infra=reserved:NoSchedule to Node 192.168.143.133, indicating that only applications that tolerate this taint can be scheduled onto this node.

#Step 3: Verify the Label and Taint

Check whether the node has been assigned the infra role label and taint:

# 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

The output indicates that the Node 192.168.143.133 has been configured as an infra node and has the node-role.kubernetes.io/infra=reserved:NoSchedule taint.

To set labels and taints for existing nodes in the web console instead, see Manage Nodes.

#Move Workloads to Infra Nodes

If you want to schedule a specific Pod onto infra nodes, you need to make the following configurations:

• A nodeSelector targeting the infra role label.
• Corresponding tolerations for the infra node's taint.

Below is an example Pod manifest configured to run on the infra node.

apiVersion: 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
  ...

The nodeSelector ensures the Pod is only scheduled on nodes with the label node-role.kubernetes.io/infra: "", and the toleration allows the Pod to tolerate the taint node-role.kubernetes.io/infra=reserved:NoSchedule.

With these configurations, the Pod will be scheduled onto the infra node.

Note:

Moving pods installed through OLM Operators or Cluster Plugins to an infra node is not always possible. The capability to move these pods depends on the configuration of each Operator or Cluster Plugin.

For the following components, the documentation describes how to place them on infra nodes:

• Monitoring: Planning Infra Nodes for Monitoring.
• ALB: Tasks for ALB.
• Envoy Gateway: Tasks for Envoy Gateway.
• Operators: Operator, section Configure Operator Pod Scheduling.

#Custom Role Nodes

To divide infra nodes further, you can define custom roles — for example, log nodes for logging components or monitor nodes for monitoring components. You can define any role name for this.

A custom role node works exactly like an infra node, with your role name in place of infra:

• Use the role label node-role.kubernetes.io/<role> and the taint node-role.kubernetes.io/<role>=<value>:NoSchedule. The <value> is optional but can help operators understand the scheduling intent, such as reserved or dedicated.
• On Alauda OS nodes, use one node pool per role. Each node pool carries its own node-role.kubernetes.io/<role> label and taint, declared on the pool as in Create Infra Nodes on Alauda OS Nodes.
• On non-Alauda OS nodes, add the label and the taint to the Node as in Create Infra Nodes on Non-Alauda OS Nodes.
• To schedule a Pod onto these nodes, configure a nodeSelector and tolerations as in Move Workloads to Infra Nodes.