Add a note about WMCO kubelet dependency

Author: Danil-Grigorev

enhancements/machine-api/out-of-tree-provider-support.md

@@ -22,7 +22,7 @@ approvers:
   - "@mrunalp"
   - "@sttts"
 creation-date: 2020-08-31
-last-updated: 2021-06-29
+last-updated: 2021-07-14
 status: implementable
 replaces:
 superseded-by:
@@ -203,7 +203,20 @@ Without this information, the `scheduler` cannot schedule `Pods` that have any s
 To ensure that cluster disaster recovery procedures can still operate smoothly, we will ensure that core control plane components and their operators tolerate the uninitialized taint, to prevent `CCM` blocking new control plane hosts being added if `CCM` is non-functional.
 This will include, but is not limited to: Kube Controller Manager, Etcd, Kube API Server, Networking, Cluster Machine Approver.
 
-*Note: Windows Machine Config Operator (WMCO) manages `kubelet` configuration for Windows nodes, for which described changes in this chapter would still apply.*
+#### Windows Machine Config Operator
+
+##### Kubelet Changes
+
+To generate the configuration for Windows nodes, `WMCO` reads the output of MCO's rendered configuration as a basis for its own config for Kubelet on the Windows node.
+As we are making changes to the output of the Kubelet service in `MCO` (namely change the value of the `cloud-provider` flag), we will need to verify that `WMCO` reads this flag and copies its value to the Kubelet Windows service.
+
+##### Node Initialization
+
+On most platforms, `Node` initialization is handled centrally by the `CCM`, specifically the Cloud Node Manager (`CNM`) running within it.
+However, On certain platforms (e.g. Azure), the `CNM` must be run on the `Node` itself, typically via a `DaemonSet`.
+Since Red Hat cannot supply or support Windows container images, we cannot run a `DaemonSet` for the `CNM` targeted at Windows Nodes as we would do on Linux Nodes.
+Instead, we must adapt the `WMCO` to, on these particular platforms, deploy a new Windows service that runs the `CNM` on the `Node`.
+This pattern is already in place for other components that are required to run on the host (eg `CNI` and Kube-Proxy), so we will be able to reuse the existing pattern to add support for `CNM` on platforms that require a `CNM` per host.
 
 ##### Example flag changes for kubelet