// Module included in the following assemblies:
//
// * edge_computing/day_2_core_cnf_clusters/updating/telco-update-ocp-update-prep.adoc

:_mod-docs-content-type: PROCEDURE
[id="update-applying-mcp-labels-to-nodes-before-the-update_{context}"]
= Applying MachineConfigPool labels to nodes before the update

[role="_abstract"]
Prepare `MachineConfigPool` (MCP) node labels to group nodes together in groups of roughly 8 to 10 nodes.
With MCP groups, you can reboot groups of nodes independently from the rest of the cluster.

You use the MCP node labels to pause and unpause the set of nodes during the update process so that you can do the update and reboot at a time of your choosing.

*Staggering the cluster update*

Sometimes there are problems during the update.
Often the problem is related to hardware failure or nodes needing to be reset.
Using MCP node labels, you can update nodes in stages by pausing the update at critical moments, tracking paused and unpaused nodes as you proceed.
When a problem occurs, you use the nodes that are in an unpaused state to ensure that there are enough nodes running to keep all applications pods running.

*Dividing worker nodes into MachineConfigPool groups*

How you divide worker nodes into MCPs can vary depending on how many nodes are in the cluster or how many nodes you assign to a node role.
By default, the two roles in a cluster are control plane and worker roles.

You can also move nodes between MCP groups if both groups have the same machine config, which is important if you have too many nodes in one large machine config pool. For more information about MCP groups, see _Additional resources_.

[NOTE]
====
Larger clusters can have as many as 100 worker nodes.
No matter how many nodes there are in the cluster, keep each `MachineConfigPool` group to around 10 nodes.
This allows you to control how many nodes are taken down at a time.
With multiple `MachineConfigPool` groups, you can unpause several groups at a time to accelerate the update, or separate the update over two or more maintenance windows.
====

Example cluster with 15 worker nodes::
Consider a cluster with 15 worker nodes:

* 10 worker nodes are control plane nodes.
* 5 worker nodes are data plane nodes.

+
Split the control plane and data plane worker node roles into at least 2 MCP groups each.
Having 2 MCP groups per role means that you can have one set of nodes that are not affected by the update.

Example cluster with 6 worker nodes::
Consider a cluster with 6 worker nodes:

* Split the worker nodes into 3 MCP groups of 2 nodes each.

+
Upgrade one of the MCP groups.
Allow the updated nodes to sit through a day to allow for verification of application compatibility before completing the update on the other 4 nodes.

[IMPORTANT]
====
The process and pace at which you unpause the MCP groups is determined by your applications and configuration.

If your pod can handle being scheduled across nodes in a cluster, you can unpause several MCP groups at a time and set the `MaxUnavailable` field in the MCP custom resource (CR) to as high as 50%. This allows up to half of the nodes in an MCP group to restart and get updated.
====

.Procedure
