Merge pull request #30492 from mburke5678/issue-28020

 Update wording in Reboot Nodes topic for clarity

Author: mburke5678

modules/nodes-nodes-rebooting-infrastructure.adoc

@@ -3,26 +3,15 @@
 // * nodes/nodes-nodes-rebooting.adoc
 
 [id="nodes-nodes-rebooting-infrastructure_{context}"]
-= Understanding infrastructure node rebooting
+= About rebooting nodes running critical infrastructure
 
-Infrastructure nodes are nodes that are labeled to run pieces of the
-{product-title} environment. Currently, the easiest way to manage node reboots
-is to ensure that there are at least three nodes available to run
-infrastructure. The nodes to run the infrastructure are called *master* nodes.
+When rebooting nodes that host critical {product-title} infrastructure components, such as router pods, registry pods, and monitoring pods, ensure that there are at least three nodes available to run these components.
 
-The scenario below demonstrates a common mistake that can lead
-to service interruptions for the applications running on {product-title} when
-only two nodes are available.
+The following scenario demonstrates how service interruptions can occur with applications running on {product-title} when only two nodes are available:
 
 - Node A is marked unschedulable and all pods are evacuated.
-- The registry pod running on that node is now redeployed on node B. This means
-node B is now running both registry pods.
+- The registry pod running on that node is now redeployed on node B. Node B is now running both registry pods.
 - Node B is now marked unschedulable and is evacuated.
-- The service exposing the two pod endpoints on node B, for a brief period of
-   time, loses all endpoints until they are redeployed to node A.
+- The service exposing the two pod endpoints on node B loses all endpoints, for a brief period of time, until they are redeployed to node A.
 
-The same process using three master nodes for infrastructure does not result in a service
-disruption. However, due to pod scheduling, the last node that is evacuated and
-brought back in to rotation is left running zero registries. The other two nodes
-will run two and one registries respectively. The best solution is to rely on
-pod anti-affinity.
+When using three nodes for infrastructure components, this process does not result in a service disruption. However, due to pod scheduling, the last node that is evacuated and brought back into rotation does not have a registry pod. One of the other nodes has two registry pods. To schedule the third registry pod on the last node, use pod anti-affinity to prevent the scheduler from locating two registry pods on the same node.

nodes/nodes/nodes-nodes-rebooting.adoc

@@ -29,6 +29,10 @@ process applies, though it is important to understand certain edge cases.
 
 include::modules/nodes-nodes-rebooting-infrastructure.adoc[leveloffset=+1]
 
+.Additional information
+
+* For more information on pod anti-affinity, see xref:../../nodes/scheduling/nodes-scheduler-pod-affinity.adoc#nodes-scheduler-pod-affinity[Placing pods relative to other pods using affinity and anti-affinity rules].
+
 include::modules/nodes-nodes-rebooting-affinity.adoc[leveloffset=+1]
 
 include::modules/nodes-nodes-rebooting-router.adoc[leveloffset=+1]