In the future, TLS Bootstrapping should be delegated to the kubelet

[luxas]

As decided in a SIG meeting, in v1.7 we might delegate the TLS bootstrapping to the kubelet itself, instead of letting kubeadm do it.

This assumes the experimental TLS bootstrapping flag on kubelet is turned into something that we can rely on.

cc @philips @aaronlevy @ethernetdan @vishh @mikedanese @pires

[aaronlevy]

We recently switched to using the kubelet TLS bootstrap in bootkube - but one thing we ran into is that this makes using static manifests for the temporary control plane a little difficult (initial kubelet never enters pod sync loop because it's waiting on CSR - so the temp api server would never start). We still use a compiled-in control plane in bootkube, so it wasn't an immediate issue - but something to consider (like maybe need to pre-seed first node with a valid cert).

ref: kubernetes-retired/bootkube#168 (comment)

[mikedanese]

We should check the ordering here. It seem like it should be possible to start static pods before the kubeclient exists (outside of standalone mode), although I have not looked at the code so I can't speak to the difficulty of such a change.

[luxas]

Delegating the TLS bootstrap flow to the kubelet is a goal for v1.8

cc @mikedanese @jcbsmpsn @aaronlevy @liggitt

[luxas]

This is now fixed