Skip to content

Commit

Permalink
Add a note about WMCO kubelet dependency
Browse files Browse the repository at this point in the history
  • Loading branch information
Danil-Grigorev committed Jul 14, 2021
1 parent 0dc40f9 commit df1d938
Showing 1 changed file with 15 additions and 2 deletions.
17 changes: 15 additions & 2 deletions enhancements/machine-api/out-of-tree-provider-support.md
Original file line number Diff line number Diff line change
Expand Up @@ -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:
Expand Down Expand Up @@ -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

Expand Down

0 comments on commit df1d938

Please sign in to comment.