Static Pods

The API server is not running. The kube-scheduler is not running. The controller manager is not running. Who starts them?

Static Pods are the answer. They are Pod manifests placed in a directory on the node’s filesystem. The kubelet watches this directory directly and starts, restarts, and stops Pods based on what it finds there, without any API server involvement. This is how Kubernetes bootstraps its own control plane.

Where static Pods live

The kubelet’s static Pod directory is configured by the --staticPodPath flag in the kubelet configuration. On kubeadm clusters, the default is /etc/kubernetes/manifests/.

kubectl get pods -n kube-system

The control plane Pods you see here (kube-apiserver-<node>, etcd-<node>, kube-scheduler-<node>, kube-controller-manager-<node>) all have the node name suffixed to their names. This naming convention signals that they are static Pods, owned by the kubelet on that specific node.

In the simulated cluster:

kubectl describe pod kube-apiserver-sim-control-plane -n kube-system

Look at the Controlled By field. For a static Pod, it shows Node/sim-control-plane. A regular Pod shows a ReplicaSet or DaemonSet. The Node controller is the kubelet itself.

Creating a static Pod

To create a static Pod, you place a manifest file in the staticPodPath directory. The kubelet detects the new file and starts the Pod automatically.

In the simulator, the static Pod directory path is /etc/kubernetes/manifests/. Create a manifest there:

nano /etc/kubernetes/manifests/my-static-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: my-static-pod
  namespace: default
spec:
  containers:
    - name: static-app
      image: busybox:1.36
      command: ['sh', '-c', 'sleep 3600']

The kubelet detects the file and creates the Pod. Within seconds:

kubectl get pods

You see my-static-pod-sim-control-plane (with the node name suffix). Note that the Pod appears in the API server for visibility, but the API server does not manage it. The kubelet manages it.

Static Pods vs DaemonSets

Static Pods run without API server involvement. DaemonSets require a running API server and scheduler. Static Pods are for bootstrapping scenarios where the API server is not yet available or must not be the arbiter of whether the Pod runs.

Use DaemonSets for user workloads that should run on every node. Use static Pods for critical infrastructure that must survive API server outages or that must start before the API server itself.

The control plane bootstrap sequence

This is the key insight for the CKA: the kubelet starts first (as a system service), reads /etc/kubernetes/manifests/, and starts the control plane components as static Pods. Only after etcd and the API server are running can the rest of the cluster initialize.

kubectl get pod etcd-sim-control-plane -n kube-system -o yaml

Look at metadata.ownerReferences. The owner is the Node, confirming static Pod status. The etcd Pod is managed entirely by the kubelet on the control plane node.

rm /etc/kubernetes/manifests/my-static-pod.yaml

The kubelet detects the file removal and terminates the Pod. Static Pods are the foundation of cluster self-hosting. The next lesson covers priority classes, which determine which Pods are evicted first when the cluster runs out of resources.