Skip to main content
In this lesson we explain static pods in Kubernetes: what they are, how the kubelet manages them, how to configure the manifest directory, and how static pods differ from DaemonSets.

​
What are static pods?

A static pod is a regular Pod manifest file placed on a node in a directory that the kubelet watches. The kubelet periodically reads that directory, creates the pods described by the manifests with the local container runtime, and ensures they remain running even when the Kubernetes control plane is absent. Key behaviors:
  • Adding a manifest file results in the kubelet creating the Pod on the node.
  • Modifying the manifest causes the kubelet to recreate the Pod so the changes take effect.
  • Removing the manifest makes the kubelet delete the corresponding Pod.
Because the kubelet operates directly at the Pod level, static pods are limited to Pod objects only. You cannot run higher-level controllers (ReplicaSets, Deployments, Services) solely by placing their manifests in the static-pod directory — those rely on control-plane components (API server, controllers, scheduler, etcd).

​
How the kubelet works without a control plane

Normally the kubelet communicates with the kube-apiserver to learn which pods to run (those scheduled by the control plane). However, the kubelet can manage pods independently if provided with local manifest files. This is why static pods are useful for bootstrapping or running essential components when the control plane is not available.

​
Manifest lifecycle (at a glance)

​
Configure where kubelet reads static pod manifests

You can configure the static pod manifest path either via a kubelet CLI flag or in the kubelet configuration file. Clusters created with kubeadm typically use the configuration-file approach. To inspect how kubelet is configured on an existing node, check the systemd unit (for example systemctl cat kubelet or cat /etc/systemd/system/kubelet.service.d/10-kubeadm.conf). If the unit references --config, open that file and look for the staticPodPath setting.

​
Inspecting static pods locally

Static pods are created by the kubelet through the container runtime, so you can inspect their containers with the runtime tooling. Example output using Docker:
If the node uses containerd (or another CRI runtime), use CRI tools such as crictl ps or ctr -n k8s.io containers ls to list containers created for static pods.

​
Static pods in a clustered node: mirror pods

When a kubelet running in a cluster creates a static pod, it also registers a read-only “mirror” Pod object in the kube-apiserver. This mirror allows cluster-wide visibility via kubectl but is not editable via the API — any changes must be made to the manifest file on the node. Example:
Note: The mirror pod name usually includes the node name appended (e.g., static-web-node01).

​
Using static pods for control-plane components

Static pods are commonly used to run the control-plane components (API server, controller-manager, scheduler, etcd) on control-plane nodes because they do not depend on the API server being available. Tools like kubeadm deploy control-plane manifests into the kubelet static pod directory so kubelet will start and manage them directly. Typical manifests found on a control-plane node:
This is precisely how kubeadm boots the control plane: it places component manifests in the kubelet static pod directory so kubelet acts as the local manager.

​
Static pods vs DaemonSets

Static pods and DaemonSets can both result in pods running on nodes, but they differ significantly in management, scope, and intended use.
A slide titled "Static Pods vs DaemonSets" showing a three-row comparison table. It lists that Static Pods are created by the kubelet, used for control-plane components, and not scheduled by the kube-scheduler, while DaemonSets are managed by the DaemonSet controller, used for monitoring/logging agents, and scheduled by the default scheduler using NodeAffinity.
Summary comparison:
  • Static Pods: Created directly by kubelet; typically used for bootstrapping and running control-plane components. Managed by editing the manifest files on the node.
  • DaemonSets: Managed by the DaemonSet controller and kube-apiserver; used for running replicas of an agent across nodes and managed declaratively.
That covers static pods: how the kubelet uses them to run pods without a control plane, how to configure and inspect them, and how they compare to DaemonSets.

Watch Video

Practice Lab