Static pods

Question: can we host the control plane of a cluster on the cluster itself?

To create a Pod, we need to communicate with the API server
The API server needs etcd to be up
Then the Pod needs to be bound to a node by the scheduler
So... all these things need to be running already!
Even if the Pod already exists, we still need API server and etcd

(so that kubelet can connect to the API server and "know" about the Pod)

Solution: run (parts of) the control plane in static pods!

Normally, kubelet queries the API server to know what pods to run
Additionally, we can tell kubelet to run pods:
- by storing manifests in a directory (--pod-manifest-path)
- by retrieving manifests from an HTTP server (--manifest-url)
These manifests should be normal pod manifests

(make sure to include the namespace in the metadata block!)
kubelet will append the node name after the pod name

How and when kubelet runs static pods

kubelet runs static pods "no matter what"

(even if it can't connect to the API server, or if no API server is configured)
When there is no API server configuration, that's called "standalone mode"
Almost nothing can prevent kubelet from running these pods

(e.g. admission controllers, pod security settings... won't apply)
kubelet monitors the manifest path (and/or the manifest URL)
If manifests are deleted: their pods are destroyed
If manifests are modified: their pods are destroyed and recreated

.warning[Deleting a mirror pod has no effect on the static pod!]

.warning[Admission control can block the mirror pod, but not the static pod!]

Since kubelet runs the static pod even if there is no connection to the API server

kubeadm leverages static pods to run the control plane

(etcd, API server, controller manager, scheduler)
It "renders" a number of YAML manifests to /etc/kubernetes/manifests
This is the cluster boot sequence:
- machine boots
- kubelet is started (typically by systemd)
- kubelet reads static pod manifests and run them
- control plane is up, yay!

class: extra-details

This pattern isn't used anymore, but perhaps it can provide inspiration
The pod checkpointer automatically generates manifests of running pods

(if they have specific labels/annotations)
The manifests are used to restart these pods if API contact is lost
This pattern is implemented in openshift/pod-checkpointer-operator and bootkube checkpointer
Unfortunately, as of 2021, both seem abandoned / unmaintained 😢

???

:EN:- Static pods :FR:- Les static pods