Apply the.... to identify each KFD for the Kubernetes scheduler.

Looks like only one topology label needs to be added, but a different one must be added to each MCP (worker-0, worker-1, worker-2, worker-3..).

Updated as follows:

. Apply the topology.kubernetes.io/zone label to each node to identify its KFD for the scheduler. You must apply the corresponding custom node role label (for example, worker-0, worker-1, worker-2) to assign each node to its custom MCP by running the following command:

I would recommend including the node role label on each node during installation so you avoid any disruption on the node once the cluster is installed. The label, then, will already be included when the cluster is ready.

It can also be done later in a cluster already installed, but a warning message should be included that moving a node from a different MCP can cause disruption.

Updated the IMPORTANT NOTE to include this new info:

"Apply the topology.kubernetes.io/zone label and custom node role labels during cluster installation or node scaling whenever possible. Applying these labels before scheduling workloads ensures that the Kubernetes scheduler can distribute application replicas correctly across failure domains.

Applying or changing node role labels after installation can move nodes between MCPs, which might temporarily disrupt workloads on those nodes. If workloads are already running when you apply or modify these labels, you might need to reschedule workloads to achieve the intended HA distribution."

As currently shows this has one worker in each MCP and thus one worker in each zone. I think it would be more instructive to show 2 workers per MCP and zone, even if we use only 2 MCPs if we need to keep this short.

Should advise that the consequence of scheduling before zone labeling is that the scheduler won't distribute across zones

The normal state of pause is false. Only set it to true when the upgrade process is starting. Set it true before starting the control plane upgrade.

As noted above, the normal state for pause should be false. The wording here should be pause the MCPs when you are ready to upgrade the cluster

I believe we need some additional context here. Things not covered are:

• Use of zones is not a guarantee that the scheduler will spread replicas across zones. It is a soft constraint, but it is beneficial to have the scheduler taking failure domains (and thus upgrade domains) into account
• The ability to take an entire failure domain offline depends on several criteria
  • The application/workload is designed to be highly available
  • The application/workload has PodDisruptionBudgets protecting the HA replicas
  • The application is able to meet minimum service level requirements while the failure domain is offline
• Recommendation is to have sufficient spare capacity in the cluster to accomodate pods disrupted when failure domain is taken offline
• If application level contraints require less than a full failure domain be taken offline concurrently the maxUnavailable setting can be reduced, eg to 50% of the failure domain, or whatever capacity allows the application to meet service requirements.