Scale and configure node pools in Azure Red Hat OpenShift with hosted control planes (preview)

After creating node pools in your Azure Red Hat OpenShift with hosted control planes cluster, you can scale them to adjust capacity, control workload placement with labels and taints, configure node drain behavior, and delete node pools you no longer need.

Prerequisites

  • An existing Azure Red Hat OpenShift with hosted control planes cluster with at least one node pool.
  • Azure CLI version 2.67.0 or higher. Use az --version to find your installed version. If you need to install or upgrade, see Install Azure CLI.

Set environment variables

If you didn't already set the following environment variables, set them in your shell before proceeding. Replace the placeholder values with your own.

CUSTOMER_RG_NAME="<resource-group-name>"
CLUSTER_NAME="<cluster-name>"
NP_NAME="<node-pool-name>"

Scale a node pool

Scale an existing node pool to adjust capacity for changing workload demands. Set a specific replica count for manual scaling, or configure autoscaling to automatically adjust the node count within a defined range.

Note

You must configure either replicas or autoScaling for a node pool, but not both.

  1. Update the node pool replica count or autoscaling configuration.

    The following example scales a fixed replica count node pool to four replicas. If the node pool currently uses autoscaling, add --remove properties.autoScaling to disable it:

    az aro hcp cluster nodepool update \
      --resource-group "${CUSTOMER_RG_NAME}" \
      --cluster-name "${CLUSTER_NAME}" \
      --name "${NP_NAME}" \
      --replicas 4 \
      --remove properties.autoScaling
    

    To switch from a fixed replica count to autoscaling, add --remove properties.replicas and provide the autoscaling range:

    az aro hcp cluster nodepool update \
      --resource-group "${CUSTOMER_RG_NAME}" \
      --cluster-name "${CLUSTER_NAME}" \
      --name "${NP_NAME}" \
      --min-replicas 2 \
      --max-replicas 8 \
      --remove properties.replicas
    
  2. Verify the node pool changes.

    oc get nodes
    

Control workload placement

Apply labels and taints to a node pool to control which workloads schedule on its nodes. Use labels to target nodes by using node selectors and affinity rules. Use taints to repel pods that don't have a matching toleration, so you can dedicate node pools to specific workloads.

Important

Label and taint updates apply only to newly created nodes in the node pool. Updating labels or taints doesn't trigger a rolling replacement of existing nodes. To apply labels or taints to all nodes, delete the node pool and create a new one with the desired configuration.

  1. Add or update labels and taints on the node pool.

    The following example adds a label and a taint to a node pool:

    az aro hcp cluster nodepool update \
      --resource-group "${CUSTOMER_RG_NAME}" \
      --cluster-name "${CLUSTER_NAME}" \
      --name "${NP_NAME}" \
      --labels "[{key:workload-type,value:gpu}]" \
      --taints "[{key:dedicated,value:gpu-workloads,effect:NoSchedule}]"
    

    The effect property determines how the taint influences pod scheduling:

    Effect Description
    NoSchedule The scheduler doesn't schedule pods without a matching toleration on the node. Existing pods aren't evicted.
    PreferNoSchedule The scheduler avoids placing pods without a matching toleration on the node, but doesn't prevent it.
    NoExecute The scheduler doesn't schedule pods without a matching toleration on the node, and existing pods without a matching toleration are evicted.
  2. Verify that the labels are applied to the node pool.

    az aro hcp cluster nodepool show \
      --resource-group "${CUSTOMER_RG_NAME}" \
      --cluster-name "${CLUSTER_NAME}" \
      --name "${NP_NAME}" \
      --query "properties.labels"
    

    The following example output shows the label applied to the node pool:

    [
      {
        "key": "workload-type",
        "value": "gpu"
      }
    ]
    

Configure node drain behavior

Set the node drain grace period to control how long the upgrade process respects Pod Disruption Budget (PDB)-protected workloads when it replaces nodes in the pool. After the grace period expires, the process forcibly evicts all remaining workloads.

The node drain timeout property on a node pool overrides the cluster-level default for that pool. The value range is 0 to 10,080 minutes (1 week). A value of 0 means the node drains without any time limit until complete.

The following example sets a 30-minute drain timeout:

az aro hcp cluster nodepool update \
  --resource-group "${CUSTOMER_RG_NAME}" \
  --cluster-name "${CLUSTER_NAME}" \
  --name "${NP_NAME}" \
  --node-drain-timeout 30

Delete a node pool

  1. Delete a node pool when you no longer need it or when you need to recreate it with different immutable properties.

    az aro hcp cluster nodepool delete \
      --resource-group "${CUSTOMER_RG_NAME}" \
      --cluster-name "${CLUSTER_NAME}" \
      --name "${NP_NAME}" \
      -y
    
  2. Verify that the nodes are deleted.

    oc get nodes