The "non-static" pods:
Usually the API-server provides the kubelet with the Yaml configuration file to deploy the pods, the kubelet runs the pods described inside the Yaml file and make sure they are running without any issues.
The static pods:
The static pods are handled directly by the kubelet service.
The Kube-API can see the static pods, but it can't interact with them directly.
The kubelet service runs on all the nodes of the cluster, it is in charge of spawning the pods and interacting directly with the container runtime engine like docker, CRI-O or CoreOS rkt.
The kubelet also takes care of restarting static pods in case of failure.
the API-server doesn't manages static pods.
On the master node for example, all we have to do is run the kubelet as a service and configure it to spawn other services as static pods (kube-dns, kube-scheduler,...) using the "--pod-manifest-path" in its configuration files.
The files in the "--pod-manifest-path" could be a pod Yaml configuration file.
The "--pod-manifest-path" could be "/etc/kubernetes/kubelet" for example.
The kubelet goes regularly through the "--pod-manifest-path" directory and runs the configurations files there to create or delete the static pods.
After filling out the configuration file for the kubelet service "/usr/lib/systemd/system/kubelet.service" as below:
We could start the kubelet service using the below command: