Infrastructure nodes for boosting performance on RHOCP

To offload basic housekeeping tasks from your compute nodes, dedicated infrastructure nodes can be introduced. This boosts the performance of the compute nodes. As infrastructure nodes do not need licensing, and helps to optimize TCO.

To isolate and offload basic housekeeping tasks from your compute nodes, you can introduce dedicated infrastructure nodes. The following Red Hat OpenShift Container Platform components are infrastructure components:

  • Kubernetes and RHOCP control plane services that run on control plane nodes
  • The default router
  • The container image registry
  • The cluster metrics collection, or monitoring service
  • Cluster aggregated logging
  • Service brokers

The isolation of such components can boost the performance of the compute nodes. You can build the infrastructure nodes out of compute nodes.

Any node that runs any other container, pod, or component is a compute node that your subscription must cover.

Figure 1. RHOCP with infrastructure nodes
RHOCP with infrastructure nodes

For more information about infrastructure nodes and how to build them, see Creating infrastructure machine setsinesets.html(Red Hat documentation).

RHOCP infrastructure components

The following RHOCP components are infrastructure components:

  • Kubernetes and RHOCP control plane services that run on control plane nodes
  • The default router
  • The container image registry
  • The cluster metrics collection, or monitoring service
  • Cluster aggregated logging
  • Service brokers

Any node that runs any other container, pod, or component is a compute node that your subscription must cover.

In a production deployment, to hold infrastructure components at least three machine sets are necessary. Both the logging aggregation solution and Red Hat OpenShift Service Mesh deploy Elasticsearch, and Elasticsearch requires three instances that are installed on different nodes. For high availability, these nodes should be placed to different availability zones. Since you need different machine sets for each availability zone, it is necessary to have at least three machine sets.

Moving resources to infrastructure MachineSets

Some of the infrastructure resources are deployed in your cluster by default. You can move them to the infrastructure machine sets that you created.

Moving the router
The router Pod can be deployed to a different machine set. By default, the Pod is displayed to a compute node.
Moving the default registry
The registry Operator must be configured to deploy its pods to different nodes.
Moving the monitoring solution
By default, the Prometheus Cluster Monitoring stack, which contains Prometheus, Grafana, and Alertmanager, is deployed to provide cluster monitoring. It is managed by the Cluster Monitoring Operator. To move its components to different machines, a custom ConfigMap needs to be created.
Moving the cluster logging resources
The Cluster Logging Operator can be configured to deploy the pods for any or all the Cluster Logging components, Elasticsearch, Kibana, and Curator to different nodes. You cannot move the Cluster Logging Operator pod from its installed location. For example, the Elasticsearch pods can be moved to a separate node because of high CPU, memory, and disk requirements.

Once infrastructure nodes are added to your cluster configuration, it is recommended to create a machine config pool to the infra nodes as they were added after the RHOCP cluster creation. Otherwise, when the RHOCP cluster is upgraded, the compute nodes with the infra label that is applied won’t get upgraded. This is the expected behavior.

For detailed technical instructions, see Creating infrastructure machine sets (Red Hat documentation).

A good reading on this topic can be found here:https://www.linkedin.com/pulse/boosting-performance-using-infrastructure-nodes-your-cluster-miranda/(LinkedIn)