Static Pods [page]deterministic
_Static Pods_ are managed directly by the kubelet daemon on a specific node, without the [API server](#gloss:kube-apiserver) observing them. Unlike Pods that are managed by the control plane (for example, a [Deployment](#gloss:deployment)), the kubelet watches each static Pod and restarts it if it fails.
Static Pods are always bound to one [kubelet](#gloss: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](/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.
> Note: If your cluster runs control plane components as Pods, they are likely static Pods. You can recognize their mirror Pods in the `kube-system` namespace by the `kubernetes.io/config.mirror` annotation.
## Mirror Pods {#mirror-pods}
The kubelet automatically tries to create a [mirror Pod](#gloss: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](#gloss:label) from the static Pod to the mirror Pod. You can use those labels as normal via [selectors](#gloss:selector).
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 [ServiceAccount](#gloss:service-account), [ConfigMap](#gloss:configmap), or [Secret](#gloss:secret).
Static Pods do not support [ephemeral containers](/docs/concepts/workloads/pods/ephemeral-containers/).
## Static Pods vs DaemonSets {#static-pods-vs-daemonsets}
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](#gloss: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.
##
- 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.