Isolating Infrastructure Nodes

  • 24 Jan, 2025

Applying a specific node selector to all infrastructure components will guarantee that they will be scheduled on nodes with that label. See more details on node selectors in placing pods on specific nodes using node selectors, and about node labels in understanding how to update labels on nodes.

Our node label and matching selector for infrastructure components will be node-role.kubernetes.io/infra: "".

To prevent other workloads from also being scheduled on those infrastructure nodes, we need one of two solutions:

  • Apply a taint to the infrastructure nodes and tolerations to the desired infrastructure workloads.
    OR
  • Apply a completely separate label to your other nodes and matching node selector to your other workloads such that they are mutually exclusive from infrastructure nodes.

TIP: To ensure High Availability (HA) each cluster should have three Infrastructure nodes, ideally across availability zones. See more details about rebooting nodes running critical infrastructure.

TIP: Review the infrastructure node sizing suggestions

By default all nodes except for masters will be labeled with node-role.kubernetes.io/worker: "". We will be adding node-role.kubernetes.io/infra: "" to infrastructure nodes.

However, if you want to remove the existing worker role from your infra nodes, you will need an MCP to ensure that all the nodes upgrade correctly. This is because the worker MCP is responsible for updating and upgrading the nodes, and it finds them by looking for this node-role label. If you remove the label, you must have a MachineConfigPool that can find your infra nodes by the infra node-role label instead. Previously this was not the case and removing the worker label could have caused issues in OCP <= 4.3.

This infra MCP definition below will find all MachineConfigs labeled both “worker” and “infra” and it will apply them to any Machines or Nodes that have the “infra” role label. In this manner, you will ensure that your infra nodes can upgrade without the “worker” role label.

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  name: infra
spec:
  machineConfigSelector:
    matchExpressions:
      - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,infra]}
  nodeSelector:
    matchLabels:
      node-role.kubernetes.io/infra: ""

If you are not using the MachineSet API to manage your nodes, labels and taints are applied manually to each node:

Label it:

oc label node <node-name> node-role.kubernetes.io/infra=
oc label node <node-name> node-role.kubernetes.io=infra

Taint it:

oc adm taint nodes -l node-role.kubernetes.io/infra node-role.kubernetes.io/infra=reserved:NoSchedule node-role.kubernetes.io/infra=reserved:NoExecute

Related Posts

OpenShift Day 2 Operations - Part 3

  • 05 Nov, 2025

Retrieving OpenShift Cluster Logs Logs are invaluable for understanding the state of your OpenShift cluster and diagnosing problems. OpenShift provides several ways to access these logs efficiently: Get node logs Display node journal: oc adm node-logs Tail 10 lines from node journal: oc adm node-logs --tail=10 Get kubelet journal logs only: oc adm node-logs -u kubelet.service Grep kernel word on node journal: oc adm node-logs --grep=kernel List /var/log contents: oc adm node-logs --path=/ Get /var/log/audit/audit.log from node: oc adm node-logs --path=audit/audit.log Pod Logs Pod logs provide insights into application behavior. - Retrieve logs for a s

OpenShift Day 2 Operations - Part 3Read More

OpenShift Day 2 Operations - Part 2

  • 19 Aug, 2025

“Day 2” operations refer to everything that happens after the cluster is installed, which could be a lot or a little, depending on how you plan to use the cluster. Effective troubleshooting and monitoring in OpenShift require understanding the right way to retrieve logs and manage issues. While it might be tempting to SSH directly into cluster nodes, OpenShift provides tools and workflows to handle logs more securely and efficiently. Why You Should Avoid SSHing to Nodes SSHing directly into cluster nodes might seem like a quick way to debug issues, but it introduces several risks and challenges: 1. Security Risks - Inconsistent Access Control: Granting SSH access bypasses OpenShift’s

OpenShift Day 2 Operations - Part 2Read More

OpenShift Day 2 Operations - Part 1

  • 29 Jul, 2025

“Day 2” operations refer to everything that happens after the cluster is installed, which could be a lot or a little, depending on how you plan to use the cluster. Verifying the Health of Your OpenShift 4 Cluster Managing an OpenShift 4 cluster effectively involves regular health checks to ensure smooth operation and reliability. An unhealthy cluster can lead to downtime, reduced performance, and compromised workloads. Node Health Healthy nodes are crucial for running workloads effectively. - Use this command to check the node status: oc get nodes Verify that all nodes show Ready in the STATUS column. You can use oc get nodes -o wide to get more details about the cluster For more

OpenShift Day 2 Operations - Part 1Read More