How are Kubernetes control plane components started when they run as static Pods?

I've been diving deep on my learning Kubernetes clusters. I want to know how kubeadm starts up each control plane component and in what order?

After reading the Kubernetes documents, I wasn't sure. Doing some more reading I started to understand that it may be the kubelet service that does it by picking up the static Pod manifests in /etc/kubernetes/manifests. I think that sounds about right, since the kubelet is the only service that is running on the host machine (and not as a Pod in the cluster); and it handles static Pods.

I didn't want to waste time going down the wrong path so then I asked AI (Google, and MS CoPilot) to see if I could get the warm fuzzies and the pat on the back. They both said No, because it doesn't. Then they started to lecture me by droning on about how the kubelet has other responsibilities, see snippet here:

The AI seems to be explaining the difference in each component and missed what I was asking here. But I guess this could be right. It would be great if the Kubernetes documentation laid out the manual steps for setting up a cluster. I find it to be very helpful in the learning process to better comprehend the architecture.

Your assumptions are correct and AI is hallucinating. Static pods ARE being started by kubelet and providing the kube-apiserver is deployed as a static pod, then yes it is indeed started by kubelet (as any other static/non-static pod). There are cases and k8s distros where api-server can be provided as a service. In this case the api-server doesn't run as a pod in the cluster.

Check https://docs.aws.amazon.com/eks/latest/best-practices/control-plane.html for example. Also tools like kind or k3d doesn't run the kube-apiserver as a dedicated pod.

To answer your question, you can review the kubeadm Implementation details. Which lay out exactly how it does it in good details.

These are from the official Kubernetes documentation. You can navigate to it by following the breadcrumbs Kubernetes Documentation > Reference > Setup tools > Kubeadm > Implementation details. There they provide this hint Generate static Pod manifests for control plane components which cements the idea that the kube-apiserver (starts as a static Pod) with a manifest that kubeadm generates and places at /etc/kubernetes/manifests/kube-apiserver.yaml.

Furthermore, the installing kubeadm process seen here; instructs you to install the kubelet package as a service of systemd (if using systemd). Where you can optionally enable the kubelet service, but not to start it at that point. kubeadm will start it at the right time. The implementation details also state "The kubelet watches this directory for Pods to be created on startup". Thus verifying that this is how the kube-apiserver pod is started.