Static Pods are managed directly by the kubelet daemon on a specific node, without the API server observing them. Unlike Pods that are managed by the control plane (for example, a Deployment), the kubelet watches each static Pod and restarts it if it fails.
Static Pods are always bound to one kubelet on a specific node.
The main use for static Pods is to run a self-hosted control plane: in other words,
using the kubelet to supervise the individual
control plane components.
For example, kubeadm uses static Pods to run
kube-apiserver, kube-controller-manager, kube-scheduler, and etcd on control plane nodes.
kube-system namespace
by the kubernetes.io/config.mirror annotation.The kubelet automatically tries to create a mirror Pod on the Kubernetes API server for each static Pod. This means that the Pods running on a node are visible on the API server, but cannot be controlled from there. The Pod names will be suffixed with the node hostname with a leading hyphen.
The kubelet propagates labels from the static Pod to the mirror Pod. You can use those labels as normal via selectors.
If you try to use kubectl to delete the mirror Pod from the API server,
the kubelet does not remove the static Pod. The kubelet will recreate
the mirror Pod.
The spec of a static Pod cannot refer to other API objects, such as ServiceAccount, ConfigMap, or Secret.
Static Pods do not support ephemeral containers.
If you are running clustered Kubernetes and are using static Pods to run a Pod on every node, you should probably be using a DaemonSet instead.
Static Pods are not managed by the control plane, so they cannot be rolled out, rolled back, or scaled using standard Kubernetes mechanisms. DaemonSets provide these capabilities and are the recommended approach for running node-level workloads.
Static Pods are started by the kubelet before the API server is available, which makes them suitable for bootstrapping control plane components. DaemonSets require a running control plane.