A Static Pod is a Kubernetes Pod that is managed directly by the kubelet on a specific node, rather than being managed by the Kubernetes API server or a Deployment.
This makes Static Pods different from normal Pods, where the Kubernetes control plane is responsible for scheduling and managing the workload.
How Does a Static Pod Work?
The kubelet watches a configured directory for Pod manifest files. A common location is:
/etc/kubernetes/manifests/
When a valid Pod YAML file is placed in this directory, the kubelet detects it and starts the Pod on that particular node. If the Pod fails, the kubelet can restart it automatically.
For example:
apiVersion: v1
kind: Pod
metadata:
name: nginx-static
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
The important point is that the manifest is placed on the node where the kubelet is running. It is not submitted through a normal kubectl apply workflow.
Why Are Static Pods Used?
One of the most important use cases is running Kubernetes control-plane components.
For example, tools such as kubeadm commonly use Static Pods for components such as:
- kube-apiserver
- kube-controller-manager
- kube-scheduler
- etcd
This is useful during cluster bootstrapping because the kubelet can start these components directly, even before the Kubernetes API server is fully available.
Can We See a Static Pod With kubectl?
Yes, but there is an important distinction.
The kubelet can create a mirror Pod in the API server so that administrators can see the Static Pod using commands such as:
kubectl get pods -A
However, the mirror Pod is only a representation of the actual Static Pod. Deleting the mirror Pod through the API does not remove the underlying Static Pod; the kubelet continues managing it from the node.
Static Pod vs Deployment
A Deployment is managed through the Kubernetes control plane and is designed for scalable application workloads.
A Static Pod is:
- Managed directly by kubelet
- Bound to one specific node
- Created from a node-level manifest
- Not controlled through normal Deployment mechanisms
- Commonly used for control-plane components
Static Pods therefore aren't normally the right choice for applications that need rolling updates, scaling, or centralized workload management.
Static Pod vs DaemonSet
A Static Pod and DaemonSet can look similar because both can result in workloads running on nodes, but their management model is different.
A DaemonSet is controlled by the Kubernetes control plane and can manage a Pod on selected nodes. A Static Pod is directly managed by the kubelet on one node.
If the goal is to run a node-level application across a cluster, a DaemonSet is generally the better choice. Static Pods are more appropriate when the workload must be managed locally by kubelet, particularly for control-plane bootstrapping.
Final Thoughts
Static Pods are an important Kubernetes concept to understand, especially for anyone working with Kubernetes administration, cluster troubleshooting, or control-plane architecture.
The easiest way to remember them is:
Normal Pod → managed through the Kubernetes control plane
Static Pod → managed directly by kubelet
That distinction becomes especially important when troubleshooting Kubernetes control-plane components or situations where the API server itself is unavailable.