Planning your worker node setup

What hardware options are available to me?

The worker node flavors and isolation levels that are available to you depend on your container platform, cluster type, the infrastructure provider that you want to use, and the Red Hat OpenShift on IBM Cloud location where you want to create your cluster.

What flavors are available to me?

Classic clusters

Worker nodes can be created on virtual and bare metal worker nodes. If you require additional local disks, you can also choose one of the bare metal flavors that are designed for software-defined storage solutions, such as Portworx. Depending on the level of hardware isolation that you need, virtual worker nodes can be set up as shared or dedicated nodes, whereas bare metal machines are always set up as dedicated nodes.

VPC clusters

Worker nodes can be provisioned using virtual worker nodes on standard infrastructure or dedicated hosts.

Satellite clusters

Worker nodes can be provisioned on virtual machines in cloud providers such as AWS, Azure, GCP and more. Or, worker nodes can be provisioned using your own, on-premises, infrastructure.

Can I combine different flavors in a cluster?

Yes. To add different flavors to your cluster, you must create another worker pool. You can't resize existing worker pools to have different compute resources such as CPU or memory.

How can I change worker node flavors?

See updating flavors.

Are the worker nodes encrypted?

The secondary disk of the worker node is encrypted. For more information, see Overview of cluster encryption. After you create a worker pool, you might notice that the worker node flavor has .encrypted in the name, such as b3c.4x16.encrypted.

How do I manage my worker nodes?

Classic clusters

Worker nodes are provisioned into your IBM Cloud account. You can manage your worker nodes by using Red Hat OpenShift on IBM Cloud, but you can also use the classic infrastructure dashboard in the IBM Cloud console to work with your worker node directly.

VPC clusters

Worker nodes are not listed in the VPC infrastructure dashboard. Instead, you manage your worker nodes with Red Hat OpenShift on IBM Cloud only. However, your worker nodes might be connected to other VPC infrastructure resources, such as VPC subnets or VPC Block Storage. These resources are in the VPC infrastructure dashboard and can be managed separately from there.

Satellite clusters

Worker nodes are provisioned by using infrastructure hosts in another cloud provider or on-premsies. You can manage your worker nodes by using the Red Hat OpenShift on IBM Cloud and Satellite API, CLI, and console. You can manage the underlying infrastructure hosts in your cloud provider account or by using your own on-premises management method.

What storage options are available on worker nodes?

Choose a flavor, or machine type, with the correct storage configuration to support your workload. Some flavors have a mix of the following disks and storage configurations. For example, some flavors might have a SATA primary disk with a raw SSD secondary disk.

For VPC clusters, you can also provision a secondary disk on your worker nodes. This optional disk is provisioned in your account and you can can see them in VPC console. The charges for these disks are separate to the cost of each worker and show as a different line item on your bill. These secondary volumes also count toward the quota usage for the your account.

SATA

A magnetic spinning disk storage device that is often used for the primary disk of the worker node that stores the OS file system.

SSD

A solid-state drive storage device for high-performance data.

SAN

For select virtual machines, the storage device is mounted by using software area network (SAN).

Raw

The storage device is unformatted and the full capacity is available for use.

RAID

A storage device with data distributed for redundancy and performance that varies depending on the RAID level. As such, the disk capacity that is available for use varies.

What limitations do I need to be aware of?

Kubernetes limits the maximum number of worker nodes that you can have in a cluster. Review worker node and pod quotas for more information.

Reserved capacity and reserved instances are not supported.

Red Hat OpenShift on IBM Cloud also sets compute resource reserves that limit available compute resources on each worker node. For more information, see worker node resource reserves.

Want to be sure that you always have enough worker nodes to cover your workload? Try out the cluster autoscaler.

What operations are blocked if my worker node is running an unsupported operating system?

The following operations are blocked when an operating system is unsupported:

• worker reload
• worker replace without update
• worker replace with update
• worker update
• worker pool create (with an unsupported OS)
• worker pool rebalance
• worker pool resize (scale up)
• worker pool zone add
• instance group resize (patch)
• autoscaler remove worker (v2/autoscalerRemoveWorker)

Why do my worker nodes have the master role?

When you run oc get nodes or oc describe node <worker_node>, you might see that the worker nodes have master,worker roles. In OpenShift Container Platform clusters, operators use the master role as a nodeSelector so that OCP can deploy default components that are controlled by operators, such as the internal registry, in your cluster. No master node processes, such as the API server or Kubernetes scheduler, run on your worker nodes. For more information about master and worker node components, see Red Hat OpenShift architecture.

Planning considerations for VMs

Available flavors for VMs

The following table shows available worker node flavors for classic and VPC clusters. Worker node flavors vary by cluster type, the zone where you want to create the cluster, the container platform, and the infrastructure provider that you want to use. To see the flavors available in your zone, run ibmcloud oc flavors --zone <zone>.

To view a list of available VM flavors by zone, review the following pages.

• Classic flavors
• VPC Gen 2 flavors*

* VPC: For more information about network performance caps for virtual machines, see VPC profiles. The network speeds refer to the speeds of the worker node network interfaces. The maximum speed available to your worker nodes is 25Gbps. Because IP in IP encapsulation is required for traffic between pods that are on different subnets, data transfer speeds between pods on different subnets might be slower, about half the compute profile network speed. Overall network speeds for apps that you deploy to your cluster depend on the worker node size and application's architecture.

Planning considerations for bare metal

How is bare metal different than VMs?

Bare metal gives you direct access to the physical resources on the machine, such as the memory or CPU. This setup eliminates the virtual machine hypervisor that allocates physical resources to virtual machines that run on the host. Instead, all a bare metal machine's resources are dedicated exclusively to the worker, so you don't need to worry about "noisy neighbors" sharing resources or slowing down performance. Physical flavors have more local storage than virtual, and some have RAID to increase data availability. Local storage on the worker node is for short-term processing only, and the primary and auxiliary disks are wiped when you update or reload the worker node. For persistent storage solutions, see Planning highly available persistent storage.

Because you have full control over the isolation and resource consumption for your workloads, you can use bare metal machines to achieve HIPAA and PCI compliance for your environment.

Bare metal seems awesome! What's stopping me from ordering one immediately?

Bare metal servers are more expensive than virtual servers, and are best suited for high-performance apps that need more resources and host control. Bare metal worker nodes are also not available for VPC clusters.

Bare metal servers are billed monthly. If you cancel a bare metal server before the end of the month, you are charged through the end of that month. After you order or cancel a bare metal server, the process is completed manually in your IBM Cloud infrastructure account. Therefore, it can take more than one business day to complete.

Available flavors for bare metal

Worker node flavors vary by cluster type, the zone where you want to create the cluster, the container platform, and the infrastructure provider that you want to use. To see the flavors available in your zone, run ibmcloud oc flavors --zone <zone>. You can also review available VM or SDS flavors.

Bare metal machines are optimized for different use cases such as data-, GPU-, or RAM-intensive workloads.

After you create GPU bare metal worker nodes in your Red Hat OpenShift version 4 cluster, install the Node Feature Discovery and NVIDIA GPU operators for your cluster version.

Planning considerations for SDS

Because you have full control over the isolation and resource consumption for your workloads, you can use SDS machines to achieve HIPAA and PCI compliance for your environment.

You typically use SDS machines in the following cases:

• If you use an SDS add-on such as Portworx, use an SDS machine.
• If your app is a StatefulSet that requires local storage, you can use SDS machines and provision Kubernetes local persistent volumes.
• If you have custom apps that require additional raw local storage.

For more storage solutions, see Planning highly available persistent storage.

Available flavors for SDS

Worker node flavors vary by cluster type, the zone where you want to create the cluster, the container platform, and the infrastructure provider that you want to use. To see the flavors available in your zone, run ibmcloud oc flavors --zone <zone>. You can also review available bare metal or VM flavors.