From a scheduling perspective, any node can technically be labeled as a master node, infrastructure node, application node, or any combination of the two.
The specific technique depends on the specific version of OpenShift v3.x
Prior to v3.10, the default was to label infrastructure nodes and application nodes with a region label. For example, in the openshift-ansible installation inventory, you might have something like this:
[nodes]
ose3-master[1:3].test.example.com
ose3-infra[1:2].test.example.com openshift_node_labels="{'region': 'infra', 'zone': 'default'}"
ose3-node[1:2].test.example.com openshift_node_labels="{'region': 'primary', 'zone': 'default'}" region=infra and region=primary are the default values for labels mapping to infrastructure and application nodes, but I believe you can configure your cluster to map workloads using different labels
In 3.10 and 3.11, you need to label every node with a node group. For example, in the openshift-ansible installation inventory, you might have something like this:
[nodes]
# openshift_node_group_name must be provided for each node
# See 'Node Group Definition and Mapping' in the project README for more details
ose3-master[1:3].test.example.com openshift_node_group_name="node-config-master"
ose3-infra[1:2].test.example.com openshift_node_group_name="node-config-infra"
ose3-node[1:2].test.example.com openshift_node_group_name="node-config-compute"
Using the openshift_node_group_name annotation in the installer applies the following labels on nodes:
- node-role.kubernetes.io/master=true
- node-role.kubernetes.io/infra=true
- node-role.kubernetes.io/compute=true
If you are a cluster administrator, you can add or remove node labels at any time, including adding multiple labels that affect scheduling.
oc label node <node> <key_1>=<value_1> //Add label to node
oc label node <node> <key_1>=<value_1>- //Remove label from node
Just to note, if you are using official Red Hat supported OpenShift Container Platform, it is in violation of the subscription agreement to run application workloads on infrastructure nodes. Application node subscriptions are separated from Master and Infrastructure subscriptions, so that customers don't have to pay much for the internal component, non-business workloads that run on the Masters and Infras (API, controllers, internal registry, metrics, logging, monitoring, etc).
References:
