Understanding Static Pods in Kubernetes

In this blog, we’ll explore Static Pods in Kubernetes, their use cases, and how to configure and inspect them.

---

What Are Static Pods?

Normally, the kubelet relies on the kube-apiserver to get instructions about which pods to run on a node. The API server receives scheduling decisions from the kube-scheduler, and stores the cluster state in ETCD.

But what happens if there’s no API server, no scheduler, no controllers, and no ETCD—in other words, no Kubernetes master at all?

Even in this scenario, the kubelet can still manage pods independently. These pods, created and managed by the kubelet without any control plane components, are called Static Pods.

---

How Static Pods Work

• The kubelet periodically checks a designated directory on the node for pod definition files (manifests).

• When it finds a manifest, it creates the pod on the node.

• If the pod crashes, the kubelet automatically restarts it.

• If the manifest file changes, the kubelet recreates the pod to apply updates.

• If the manifest is removed, the pod is automatically deleted.

Important: Static pods only exist at the pod level. You cannot create ReplicaSets, Deployments, or Services using static pod manifests. These objects require other control plane components.

---

Where Are Static Pods Stored?

The kubelet needs to know the path to the directory containing static pod manifests. There are two ways to locate this:

1. Check in the kubelet.service file

The static pod path may be specified directly as the --pod-manifest-path option. To check:

systemctl cat kubelet | grep pod-manifest-path

Example output:

--pod-manifest-path=/etc/kubernetes/manifests

This directory is where you place your pod manifest files.

---

2. Check in the kubelet config file (config.yaml or kubeconfig.yaml)

Sometimes the kubelet is configured to use a config file via the --config option. In this file, the path is specified as:

staticPodPath: "/etc/kubernetes/manifests"

• Either method will give you the correct directory for placing static pod manifests.

• If both exist, the kubelet config file usually takes precedence.

---

Viewing Static Pods

Once static pods are created, you cannot use kubectl to view them if the kube-apiserver is not running. This is because:

• kubectl communicates with the kube-apiserver.

• If the cluster has no API server (e.g., in a standalone kubelet scenario), kubectl has no source of truth.

Instead, use Docker (or the container runtime directly) to inspect the running static pods:

docker ps

If the node is part of a cluster with a running kube-apiserver, static pods are mirrored as read-only pods, and you can view them via:

kubectl get pods -n kube-system

You cannot edit or delete static pods via kubectl; changes must be made in the manifest files.

---

Static Pods vs DaemonSets

Both static pods and DaemonSet pods are ignored by the kube-scheduler.

---

Use Cases for Static Pods

Static pods are ideal for:

• Bootstrapping the Kubernetes control plane itself as pods (e.g., API server, Controller Manager, ETCD).

• Running critical node-level services that must exist independently of the control plane.

When using tools like kubeadm, static pods are used to deploy the cluster's control plane. The kubelet monitors these pods, automatically restarting them if they crash.

---

Summary

• Static Pods are created and managed directly by the kubelet.

• They are independent of the Kubernetes control plane.

• You can find the static pod manifest directory in either the kubelet.service file (--pod-manifest-path) or the kubelet config file (staticPodPath).

• Use Docker to inspect static pods if no API server is present.

• Use static pods to deploy the Kubernetes control plane itself or critical node-level services.

Static pods provide a simple, reliable way to run essential pods even when the full Kubernetes control plane is not available.