As moondev pointed to, eventually bootkube will handle bootstrapping k8s clusters. At my company we just set everything up using cloud-config. A systemd unit boots the kubelet on each server, and static k8s manifests are loaded by the kubelet to run the rest of the k8s components as pods. This way, the kubelet itself is the only component that is not managed by k8s itself.
> At my company we just set everything up using cloud-config. A systemd unit boots the kubelet on each server, and static k8s manifests are loaded by the kubelet to run the rest of the k8s components as pods.
This is the exact same methodology that i've been using and it's worked rather well. The current CoreOS documentation [1] on running Kubernetes follows this methodology too.
This is precisely what we do on our cluster as well for the node-level daemons - kubelet and kube-proxy.
We use fleet to schedule the HA API server. You cannot use the Kubelet to schedule this, because you need an API server to schedule cluster-wide pods.
The only solution I can see is to have a config that launches a special 'master' node that runs the API server, but this is uncompelling to me. I'd rather have every single node be identical, and get the API server to pop up somewhere in the cluster using a master election process - which is precisely what fleet does.
Fleet is still not necessary for HA control planes. There is no danger in running multiple API servers as once. For some time now, the controller manager and scheduler binaries have supported built-in leader election with the --leader-elect option.
