# Static Pods

LLMS index: [llms.txt](/llms.txt)

---

_Static Pods_ are managed directly by the kubelet daemon on a specific node,
without the <a class='glossary-tooltip' title='Control plane component that serves the Kubernetes API.' data-bs-toggle='tooltip' data-bs-placement='top' href='/docs/concepts/architecture/#kube-apiserver' target='_blank' aria-label='API server'>API server</a>
observing them.
Unlike Pods that are managed by the control plane (for example, a
<a class='glossary-tooltip' title='Manages a replicated application on your cluster.' data-bs-toggle='tooltip' data-bs-placement='top' href='/docs/concepts/workloads/controllers/deployment/' target='_blank' aria-label='Deployment'>Deployment</a>),
the kubelet watches each static Pod and restarts it if it fails.

Static Pods are always bound to one <a class='glossary-tooltip' title='An agent that runs on each node in the cluster. It makes sure that containers are running in a pod.' data-bs-toggle='tooltip' data-bs-placement='top' href='/docs/reference/command-line-tools-reference/kubelet' target='_blank' aria-label='kubelet'>kubelet</a> 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](/docs/concepts/overview/components/#control-plane-components).
For example, [kubeadm](/docs/reference/setup-tools/kubeadm/) uses static Pods to run
`kube-apiserver`, `kube-controller-manager`, `kube-scheduler`, and `etcd` on control plane nodes.


<div class="alert alert-info" role="note"><h4 class="alert-heading">Note:</h4>If your cluster runs control plane components as Pods, they are likely
static Pods. You can recognize their mirror Pods in the <code>kube-system</code> namespace
by the <code>kubernetes.io/config.mirror</code> annotation.</div>


## Mirror Pods {#mirror-pods}

The kubelet automatically tries to create a
<a class='glossary-tooltip' title='An object in the API server that tracks a static pod on a kubelet.' data-bs-toggle='tooltip' data-bs-placement='top' href='/docs/reference/glossary/?all=true#term-mirror-pod' target='_blank' aria-label='mirror Pod'>mirror Pod</a>
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 <a class='glossary-tooltip' title='Tags objects with identifying attributes that are meaningful and relevant to users.' data-bs-toggle='tooltip' data-bs-placement='top' href='/docs/concepts/overview/working-with-objects/labels' target='_blank' aria-label='labels'>labels</a>
from the static Pod to the mirror Pod. You can use those labels as normal via
<a class='glossary-tooltip' title='Allows users to filter a list of resources based on labels.' data-bs-toggle='tooltip' data-bs-placement='top' href='/docs/concepts/overview/working-with-objects/labels/' target='_blank' aria-label='selectors'>selectors</a>.

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.

## Limitations {#limitations}

The spec of a static Pod cannot refer to other API objects,
such as <a class='glossary-tooltip' title='Provides an identity for processes that run in a Pod.' data-bs-toggle='tooltip' data-bs-placement='top' href='/docs/tasks/configure-pod-container/configure-service-account/' target='_blank' aria-label='ServiceAccount'>ServiceAccount</a>,
<a class='glossary-tooltip' title='An API object used to store non-confidential data in key-value pairs. Can be consumed as environment variables, command-line arguments, or configuration files in a volume.' data-bs-toggle='tooltip' data-bs-placement='top' href='/docs/concepts/configuration/configmap/' target='_blank' aria-label='ConfigMap'>ConfigMap</a>, or
<a class='glossary-tooltip' title='Stores sensitive information, such as passwords, OAuth tokens, and ssh keys.' data-bs-toggle='tooltip' data-bs-placement='top' href='/docs/concepts/configuration/secret/' target='_blank' aria-label='Secret'>Secret</a>.

Static Pods do not support [ephemeral containers](/docs/concepts/workloads/pods/ephemeral-containers/).

## Static Pods vs DaemonSets {#static-pods-vs-daemonsets}

<!-- Source: tasks/configure-pod-container/static-pod/ -->
If you are running clustered Kubernetes and are using static Pods to run a Pod
on every node, you should probably be using a
<a class='glossary-tooltip' title='Ensures a copy of a Pod is running across a set of nodes in a cluster.' data-bs-toggle='tooltip' data-bs-placement='top' href='/docs/concepts/workloads/controllers/daemonset' target='_blank' aria-label='DaemonSet'>DaemonSet</a> 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.

## What's next

- Learn how to [create static Pods](/docs/tasks/configure-pod-container/static-pod/).
- Learn about [Kubernetes components](/docs/concepts/overview/components/) and how the control plane uses static Pods.
- Learn about [DaemonSets](/docs/concepts/workloads/controllers/daemonset/) as an alternative to static Pods.