again

Author: jeremyhouser-ms

articles/operator-nexus/troubleshoot-kubernetes-cluster-node-cordoned.md

@@ -19,9 +19,9 @@ The purpose of this guide is to troubleshoot a Kubernetes Cluster when 1 or more
 
 ## Typical Cause
 
-After a runtime upgrade, before a Baremetal Machine is shut down for reimaging, the machine lifecycle controller will cordon and drain Virtual Machine resources scheduled to that Baremetal Machine. Once the Baremetal Machine resolves the reimaging process, the expectation is that the machine lifecycle controller reschedule Virtual Machines to that Baremetal Machine. It would then uncordon the Virtual Machine, with the Kubernetes Cluster Node it supports reflecting the appropriate state `Ready`.
+After a runtime upgrade, before a Baremetal Machine is shut down for reimaging, the machine lifecycle controller will cordon and drain Virtual Machine resources scheduled to that Baremetal Machine. Once the Baremetal Machine resolves the reimaging process, the expectation is that the machine lifecycle controller reschedules Virtual Machines to that Baremetal Machine. It would then uncordon the Virtual Machine, with the Kubernetes Cluster Node it supports reflecting the appropriate state `Ready`.
 
-However, a race condition may occur wherein the machine lifecycle controller fails to find Virtual Machines which should be scheduled to that Baremetal Machine. Each Virtual Machine is deployed using a virt-launcher pod. This race condition happens when the virt-launcher pod's image pull job isn't yet complete. Only after the image pull job is complete will the pod be schedulable to a Baremetal Machine. When the machine lifecycle controller examines these virt-launcher pods during the uncordon action execution, it can't find which Baremetal Machine the pod is tied to. This is because the pod itself has not yet been scheduled. Therefore the machine lifecycle controller skips uncordoning that Virtual Machine which that pod represents.
+However, a race condition may occur wherein the machine lifecycle controller fails to find Virtual Machines which should be scheduled to that Baremetal Machine. Each Virtual Machine is deployed using a virt-launcher pod. This race condition happens when the virt-launcher pod's image pull job isn't yet complete. Only after the image pull job is complete will the pod be schedulable to a Baremetal Machine. When the machine lifecycle controller examines these virt-launcher pods during the uncordon action execution, it can't find which Baremetal Machine the pod is tied to. This is because the pod itself hasn't been scheduled. Therefore the machine lifecycle controller skips uncordoning that Virtual Machine that that pod represents.
 
 ## Procedure