Kubernetes Static Pods

Pods managed directly by the kubelet on a node, independent of the API server. Static Pods are the bootstrap mechanism that launches the Kubernetes control plane itself — a critical concept for cluster troubleshooting and the CKA exam.

What Is a Static Pod?

A Static Pod is a Pod that is created and managed by the kubelet daemon on an individual node, without any instruction from the Kubernetes API server or scheduler. The kubelet watches a local directory on the node (by default /etc/kubernetes/manifests) for YAML manifest files. When it finds a valid Pod manifest, it creates the container(s) directly via the Container Runtime Interface (CRI). When the manifest file is deleted, the kubelet terminates the Pod.

Key Insight: Static Pods are the only way the control plane can run before the control plane exists. When you bootstrap a cluster with kubeadm, the kubelet is the first component running on the node. It reads the Static Pod manifests for kube-apiserver, kube-scheduler, and kube-controller-manager from disk and starts them. Only then does the API server become available, allowing the cluster to accept other workloads. Source: CKA Day 13 Source: CKA Day 27

How Static Pods Work

Node Filesystem
  /etc/kubernetes/manifests/
    ├── kube-apiserver.yaml
    ├── kube-scheduler.yaml
    └── kube-controller-manager.yaml
         │
         ▼
    kubelet (reads directory)
         │
         ▼
    Container Runtime (containerd/CRI-O)
         │
         ▼
    Running Containers (control plane pods)

The kubelet performs the following actions:

1. Periodically scans the manifest directory (default interval: every few seconds)
2. Detects new, changed, or removed YAML files
3. Creates, updates, or deletes the corresponding Pods via the CRI
4. Reports the Pod status back to the API server (for visibility only — the API server cannot control them)

Static Pod Manifest Example

apiVersion: v1
kind: Pod
metadata:
  name: kube-apiserver
  namespace: kube-system
  labels:
    component: kube-apiserver
    tier: control-plane
spec:
  hostNetwork: true
  containers:
  - name: kube-apiserver
    image: registry.k8s.io/kube-apiserver:v1.30.0
    command:
    - kube-apiserver
    - --advertise-address=192.168.1.10
    - --allow-privileged=true
    - --authorization-mode=Node,RBAC
    - --client-ca-file=/etc/kubernetes/pki/ca.crt
    # ... additional flags

Notice there is no nodeName or scheduler annotation — the kubelet does not need to be told where to run it because the manifest is already on that node.

Static Pods vs Other Workload Types

Aspect	Static Pod	DaemonSet	Deployment
Managed by	kubelet (node-local)	API server / controller	API server / controller
Scheduler involved	❌ No	✅ Yes	✅ Yes
Scaling	One per node (manifest file)	One per node (automatic)	N replicas (configurable)
Self-healing	✅ kubelet restarts container	✅ Controller recreates Pod	✅ ReplicaSet recreates Pod
Use case	Control plane components	Node agents, monitoring, CNI	Stateless applications
kubectl delete	❌ Ignored or recreates	✅ Deletes Pod	✅ Deletes Pod
Manifest location	Node filesystem	etcd (via API server)	etcd (via API server)

Identifying Static Pods

Static Pods are visible through the API server because the kubelet reports them for observability, but their names contain a suffix derived from the node name:

# List all pods in kube-system
kubectl get pods -n kube-system
 
# Output
# kube-apiserver-control-plane-1   1/1   Running   0   10m
# kube-scheduler-control-plane-1   1/1   Running   0   10m
# kube-controller-manager-control-plane-1  1/1   Running   0   10m

The suffix -control-plane-1 is the node name. If you see a Pod name ending with a node name, it is almost certainly a Static Pod.

Exam Speed Pattern: On the CKA exam, if you are asked to “create a Pod on node worker-1 without using the scheduler,” the answer is a Static Pod manifest placed in /etc/kubernetes/manifests on that node, or using nodeName in a regular Pod spec. The exam context will guide which is expected.

Troubleshooting Static Pods

Symptom	Cause	Fix
Static Pod not appearing	kubelet not running or wrong manifest path	systemctl status kubelet, verify --pod-manifest-path in kubelet config
Control plane Pod stuck Pending	Manifest has syntax error	Check journalctl -u kubelet for parse errors
Deleted Static Pod keeps recreating	kubectl delete does not remove the manifest file	SSH to node and delete the file from /etc/kubernetes/manifests
Image pull failures	Wrong image tag or no registry access	Verify image string and node connectivity to registry

CKA Exam Relevance

• Cluster Architecture (~25%): Static Pods are the bootstrap mechanism for control plane nodes. You must know where manifests live and how to inspect them.
• Troubleshooting (~30%): If the API server is down, you cannot use kubectl to fix it. You must SSH to the node and edit the Static Pod manifest directly.
• Key Commands:

  # On a control plane node
  ls /etc/kubernetes/manifests
  cat /etc/kubernetes/manifests/kube-apiserver.yaml
  sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml
  systemctl restart kubelet

Practical Practice

Exam-style hands-on tasks for this topic. Complete each task before reviewing the solution. Time yourself — CKA tasks average 5–7 minutes.

Task 1: Create a Static Pod on a Node You are asked to run a Static Pod named nginx-static on node worker1. Requirements: Place the manifest in /etc/kubernetes/manifests/ on the node. The manifest must be a valid Pod spec. Verification: kubectl get pods -n kube-system -o wide | grep nginx-static Solution:

# SSH to worker1 and create the manifest
cat <<EOF | sudo tee /etc/kubernetes/manifests/nginx-static.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx-static
  namespace: default
spec:
  containers:
  - name: nginx
    image: nginx:alpine
EOF

Task 2: Verify a Static Pod with crictl You are asked to confirm the Static Pod container is actually running on the node. Requirements: Use crictl on the node where the manifest was placed. Verification: crictl ps | grep nginx-static Solution:

# On worker1
sudo crictl ps | grep nginx-static

Task 3: Delete a Static Pod Correctly You are asked to remove the Static Pod nginx-static. kubectl delete pod nginx-static either fails or causes the Pod to recreate immediately. Requirements: Explain why kubectl delete does not work and perform the correct deletion. Verification: kubectl get pods -n kube-system | grep nginx-static should return nothing. Solution:

# Explanation: Static Pods are managed by the kubelet from the node filesystem,
# not by the API server. Deleting the mirror object via kubectl only removes
# the mirror; the kubelet sees the manifest still exists and recreates it.
# Correct action: remove the manifest file on the node.
ssh worker1
sudo rm /etc/kubernetes/manifests/nginx-static.yaml

Related Pages

• Kubernetes Architecture — control plane component placement and bootstrapping
• Kubernetes Manual Scheduling — alternative ways to pin Pods to nodes
• Kubernetes Taints and Tolerations — control-plane taints that affect where regular Pods can run
• Kubernetes Labels and Selectors — metadata on Static Pods
• Pod Fundamentals — the underlying Pod lifecycle
• Kubernetes DaemonSet — the API-managed alternative for node-local workloads
• CKA Certification — exam structure
• CKA Study Roadmap — Day 13 in the learning plan
• Kubernetes Control Plane Troubleshooting — Day 38: Static Pod manifest repair for control plane recovery
• Tech Tutorials with Piyush — course source

---

Tags: kubernetes static-pod kubelet control-plane cka devops troubleshooting kubeadm