kubeadmJoin and Cloud Init

Today was wondering , how does TKG plumb SSH keys into a. VM ? ... I think its something like this........ It became clear that, even though adding SSH keys is provider independent (i.e. its defined by CAPI), the impl of how SSH keys are added to a machine is PRovider dependent, bc diff providers need to do different API calls / tasks to ensure that a VM is launched w/ specific FILES (like an ssh key) on it............ 

- theres a contract that CAPI provides, which is that "ill give you boostrap data in the VM"

- CAPV knows how to READ that data, and parse out the SSH key from it (its embdeed in the bootstrapv1.User struct, that CAPI defines) 

- CAPV also knows how to WRITE user_data to a VM when it tells VSphere to create a new VM instance, so CAPV sends, in its "api" call to Vsphere, the ssh keys and other files that need to be on the VM, on the VMs birthday

- When the VM Starts, now cloud init reads data from a predefined location, some of which has been populated by CAPV.

 

Quick note to self.

When we define kubeadm configurations in TKG, we define them in our KubeadmControlPlane (these are the boss nodes (apiserver nodes),  and KubeadmConfigTemplates (machine deployments/ worker nodes).

After that, a secret is made called the Kubeadm Bootstrap Script by CAPI (https://github.com/kubernetes-sigs/cluster-api/blob/main/bootstrap/kubeadm/internal/cloudinit/cloudinit.go) 

 CAPI Defines a BaseUserData class, which has generic info that is common on all providers, including the concept of a USER.

The USERS object above has the SSH key configuration in it... because of that, CAPZ, CAPV, and so on are all capable of reading in SSH config data, from the initial kubeadm bootstrap script............