Windows Machine Config Bootstrapper

Bootstrapper is the entity responsible for bootstrapping a Windows node. The current scope of this component is to perform an one shot configuration of the Windows node to ensure that it can be become a worker node. Following are the jobs that the bootstrapper does:

Parse the worker ignition file to get the bootstrap kubeconfig
Ensures that the kubelet gets the correct kubelet config
Perform CNI configuration
Run the kubelet as a windows service

Once the bootstrapper has been run and the CSR associated with the Windows node is approved, the Windows node will have a taint called os=Windows:NoSchedule, only the pods with matching toleration can be scheduled onto the Windows node. An example pod spec with the toleration would be:

tolerations:
  - key: "os"
    operator: "Equal"
    value: "Windows"
    effect: "NoSchedule"

This will be remotely invoked from a Ansible script or can be run locally

Requirements

Must be run on Windows server 2019
Must be run as administrator
A worker ignition file generated by the cluster must be on disk
The kubelet you wish to use must be on disk. Currently we support v1.16.2
If running on AWS, the Windows instance must have the same tags as the other worker nodes in the cluster
For CNI, the following is required:
- HNS overlay network has been created
- A directory with all the CNI binaries
- A CNI v2 or v3 configuration file

Usage

make build

wmcb initialize-kubelet --ignition-file $IGNITION_FILE_PATH --kubelet-path $KUBELET_PATH
wmcb configure-cni --cni-dir $CNI_BIN_DIR --cni-config $CNI_CONFIG

configure-cni needs to be executed only after initialize-kubelet is executed. If initialize-kubelet is executed after configure-cni is executed, all the CNI options will be removed. This is to give the user a chance to change network configuration to something other than CNI after the initial setup.

Testing