Bookmark this page

Create Dedicated Node Pools

Objectives

  • Add node pools to run applications by using different EC2 instance types.

Some of your applications might require specific hardware to run. For example, artificial intelligence (AI) or machine learning (ML) workloads might need compute nodes with graphics processing units (GPU) for processing their models. Monolithic legacy applications that you move to OpenShift might require compute nodes with large memory. On the other hand, you might select cheaper Amazon Elastic Compute Cloud (Amazon EC2) instances for less critical workloads. You might also isolate mission-critical applications on dedicated nodes.

Even though your workloads have different requirements, you do not need to deploy several OpenShift clusters to run them. A Red Hat OpenShift Service on AWS (ROSA) cluster can use machine pools to provision and manage groups of compute nodes of the same EC2 instance type. By creating different machine pools for your workloads, you ensure that your applications run on the hardware that they require.

When you create a machine pool, you select the EC2 instance type for the machines in the pool, as well as the number of machines to provision. For example, to prepare to run your AI/ML workloads, you can create a machine pool that uses EC2 accelerated computing instances.

To associate a workload with the correct machine pool, you use OpenShift node labels and node selectors. To prevent other workloads from running on this dedicated machine pool, you use taints and tolerations.

Managing Machine Pools

The ROSA cluster creation process creates the Default machine pool with the EC2 instance type that you select during installation, which is m5.xlarge (4 vCPU and 16 GiB of memory) by default. By default, this machine pool groups all the worker nodes that you can use to run your workloads. You can create additional machine pools for specialized workloads.

From machine pools, ROSA creates several OpenShift resources:

Machine sets

A machine set resource defines the configuration parameters of a group of machines of the same type. Machine sets also manage the lifecycle of the machines in the groups.

ROSA machine pools translate to OpenShift machine set resources. On ROSA clusters, however, the machine sets are protected against direct modifications. Instead, edit the corresponding machine pool when you need to change a pool parameter.

Although an OpenShift machine set exists for the infrastructure nodes, no corresponding ROSA machine pool exists. Remember that in ROSA, in contrast to a self-managed Red Hat OpenShift Container Platform installation, the Red Hat Site Reliability Engineering (SRE) team manages these nodes for you. You are not allowed to modify them, or to run your workloads on them.

Machines

A machine resource stores the details of a specific cloud instance. For AWS, for example, the machine resource stores the name and the ID of the Amazon EC2 instance. OpenShift automatically creates the machine resources from the machine set resources.

Nodes

A node is an OpenShift object that represents a running machine. Nodes run the services that OpenShift requires to manage pods and containers. OpenShift clusters that you deploy on an existing infrastructure, without cloud provider integration, do not have machine or machine set resources, but only nodes.

Selecting EC2 Instance Types

Before creating a machine pool, you must choose an EC2 instance type for the nodes in the pool.

Amazon EC2 publishes the list of the instance types and their characteristics at https://aws.amazon.com/ec2/instance-types/. However, not all types are available for ROSA. Some instance types do not have enough memory, or a supported CPU architecture, to work as nodes in an OpenShift cluster. Some other types might not be available in your AWS Region.

To list the available EC2 instance types for your ROSA cluster, use the rosa list instance-types command:

$ rosa list instance-types
ID               CATEGORY               CPU_CORES  MEMORY
dl1.24xlarge     accelerated_computing  96         768.0 GiB
g4dn.12xlarge    accelerated_computing  48         192.0 GiB
p3.2xlarge       accelerated_computing  8          61.0 GiB
...output omitted...
c5.12xlarge      compute_optimized      48         96.0 GiB
c5.18xlarge      compute_optimized      72         144.0 GiB
...output omitted...
m5.12xlarge      general_purpose        48         192.0 GiB
m5.16xlarge      general_purpose        64         256.0 GiB
...output omitted...
r4.16xlarge      memory_optimized       64         488.0 GiB
r4.2xlarge       memory_optimized       8          61.0 GiB
...output omitted...
c5n.18xlarge     network_optimized      72         192.0 GiB
c5n.2xlarge      network_optimized      8          21.0 GiB
...output omitted...
m5d.8xlarge      storage_optimized      32         128.0 GiB
m5d.xlarge       storage_optimized      4          16.0 GiB

For specialized workloads, Amazon EC2 provides optimized instances that are organized into categories. For example, the accelerated computing category groups instance types that provide specific hardware, such as GPU.

You can get all the details of an instance type by using the aws ec2 describe-instance-types command:

$ aws ec2 describe-instance-types --instance-types p3.2xlarge
{
    "InstanceTypes": [
        {
            "InstanceType": "p3.2xlarge",
...output omitted...
            "MemoryInfo": {
                "SizeInMiB": 62464
            },
...output omitted...
            "GpuInfo": {
                "Gpus": [
                    {
                        "Name": "V100",
                        "Manufacturer": "NVIDIA",
                        "Count": 1,
                        "MemoryInfo": {
                            "SizeInMiB": 16384
                        }
                    }
                ],
                "TotalGpuMemoryInMiB": 16384
            },
...output omitted...
        }
    ]
}

Creating Machine Pools

Use the rosa create machinepool command to add a machine pool. The following command creates the with-gpu machine pool that deploys three compute nodes of the p3.2xlarge type:

$ rosa create machinepool --cluster mycluster --name with-gpu --replicas 3
  --instance-type p3.2xlarge

You can run the command interactively by using the --interactive option:

$ rosa create machinepool --cluster mycluster --interactive
? Machine pool name: with-gpu
? Enable autoscaling (optional): No
? Replicas: 3
I: Fetching instance types
? Instance type: p3.2xlarge
...output omitted...

Note

Another section of the course discusses the autoscaling capability of machine pools.

Listing, Updating, and Deleting Machine Pools

Use the rosa list machinepools command to list the machine pools in your cluster. The following command lists the machine pools in the cluster:

$ rosa list machinepools --cluster mycluster
ID       AUTOSCALING  REPLICAS  INSTANCE TYPE LABELS TAINTS AVAILABILITY ZONES ...
Default  No           2         m5.xlarge                   us-east-1a ...
with-gpu No           3         p3.2xlarge                  us-east-1a ...

Use the rosa edit machinepools command to modify some machine pool parameters. You cannot change the instance type of an existing pool. The following command scales up the with-gpu machine pool to six nodes:

$ rosa edit machinepool --cluster mycluster --replicas 6 with-gpu

Use the rosa delete machinepools command to delete a machine pool. The associated compute nodes are also deleted. OpenShift relocates the workloads that are still using the pool. However, if these workloads use a node selector to target the pool, then OpenShift cannot restart them. The following command deletes the with-gpu machine pool:

$ rosa delete machinepool --cluster mycluster with-gpu

Associating Workloads with Machine Pools

By default, OpenShift considers all the available compute nodes when scheduling workloads, even nodes in machine pools. To ensure that a specific workload runs on the expected machine pool, and to dedicate the pool to the workload, extra configuration is needed:

  • Add a node label to the compute nodes of the pool, and then configure your workload with a node selector. This configuration ensures that OpenShift schedules the workload on the compute nodes of the pool.

  • Add a taint to the compute nodes of the pool, and then add the corresponding toleration to your workload. A node taint prevents OpenShift from scheduling workloads without a matching toleration. This configuration prevents any other workload from running on the machine pool. Thus, the machine pool is dedicated to your specific workload.

Adding Node Labels to the Compute Nodes of a Pool

To add a label to the nodes of a machine pool, declare the label at the machine pool level. ROSA automatically applies that label to all the nodes in the pool.

Use the rosa edit machinepool command with the --labels label-name=label-value option to declare a node label. The following command adds the workload=IA label to the nodes of the with-gpu machine pool:

$ rosa edit machinepool --cluster mycluster --labels workload=IA with-gpu

You can also add that --labels option to the rosa create machinepool command, when you create the machine pool.

To assign your workload to the pool, use the nodeSelector parameter in the pod definition of your workload. The following example deploys a web server in a compute node with the workload=IA label:

apiVersion: v1
kind: Pod
metadata:
  name: frontweb
spec:
  containers:
    - name: web
      image: registry.redhat.io/rhel9/nginx-120:1-101
  nodeSelector:
    workload: IA

Adding a Taint to the Compute Nodes of a Pool

To add a taint to the nodes of a machine pool, use the rosa edit machinepool command with the --taints key=value:effect option. The following command adds the nvidia.com/gpu=true:NoSchedule taint to the nodes of the with-gpu machine pool:

$ rosa edit machinepool --cluster mycluster
  --taints nvidia.com/gpu=true:NoSchedule with-gpu

You can also add that --taints option to the rosa create machinepool command, when you create the machine pool.

At that point, no workload can use the machine pool. For OpenShift to schedule your workload to the pool, add the same toleration to your workload. The following example adds the toleration to the pod resource:

apiVersion: v1
kind: Pod
metadata:
  name: frontweb
spec:
  containers:
    - name: web
      image: registry.redhat.io/rhel9/nginx-120:1-101
  nodeSelector:
    workload: IA
  tolerations:
    - key: "nvidia.com/gpu"
      operator: "Equal"
      value: "true"
      effect: "NoSchedule"

The effect parameter controls how OpenShift manages the workloads that are already running when you set the taint, and how to schedule new workloads:

NoSchedule

The existing workloads continue to run on the node, even without the corresponding toleration. Only new workloads with the corresponding toleration can start running on the node.

PreferNoSchedule

The existing workloads continue to run on the node, even without the corresponding toleration. New workloads with the corresponding toleration can run on the node. If possible, then OpenShift tries to avoid deploying other workloads on this node.

NoExecute

OpenShift removes the existing workloads without the corresponding toleration. Only new workloads with the corresponding toleration can run on the node.

References

For more information about managing ROSA machine pools, refer to the Nodes chapter in the Red Hat OpenShift Service on AWS 4 Cluster Administration documentation at https://access.redhat.com/documentation/en-us/red_hat_openshift_service_on_aws/4/html-single/cluster_administration/index#nodes

For more information about taints and tolerations, refer to the Controlling Pod Placement Using Node Taints section in the Controlling Pod Placement onto Nodes (Scheduling) chapter in the Red Hat OpenShift Container Platform 4.12 Nodes documentation at https://access.redhat.com/documentation/en-us/openshift_container_platform/4.12/html-single/nodes/index#nodes-scheduler-taints-tolerations

GPU Instance Types Available for ROSA

Amazon EC2 Instance Types

Revision: do120-4.12-b978842