Understanding of static pods in Kubernetes

1. What Is a Static Pod in Kubernetes?

A Static Pod is a special type of Pod managed directly by the kubelet on a specific node not by the Kubernetes API Server or the control plane.

2. Key Characteristics of Static Pods

1. Node-Bound

   • Static Pods are tied to a specific node and cannot be scheduled or moved elsewhere.

2. Managed by Kubelet

   • The kubelet watches a directory (commonly /etc/kubernetes/manifests/) and creates pods from the manifest files found there.

3. Bypasses API Server

   • They are not created through the Kubernetes API server. Instead, they come directly from the node’s filesystem.

4. Visible but Not Controllable

   • Static Pods appear when you run kubectl get pods, but you cannot update, scale, or delete them from the master.

5. Self-Healing

   • If a Static Pod crashes, kubelet will restart it automatically.

6. No Controllers

   • They are not managed by higher-level controllers like Deployments, ReplicaSets, or StatefulSets.

3. How Static Pods Work

• You place a pod manifest file (YAML or JSON) in the kubelet's watched directory:

/etc/kubernetes/manifests/

• The kubelet detects the file and starts the pod on that node.

• If the file is updated, the kubelet will restart the pod with the new configuration.

• If the file is deleted, the kubelet will terminate the pod.

4. How Static Pods Work in Kubernetes Step by Step

Static Pods are managed directly by the kubelet on a node and are not controlled by the Kubernetes API server. Here's how to create, observe, and delete a Static Pod:

Step 1: Choose the Node

Pick the worker node (or master node, if kubelet is running there) where you want the Static Pod to run.

You can SSH into the node:

ssh user@worker-node-ip

Step 2: Create the Pod Manifest

Navigate to the kubelet’s manifest directory:

sudo su - 
cd /etc/kubernetes/manifests/

Create a YAML file for your Static Pod:

vi nginx.yaml

Paste the following content:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-static-pod
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80

• Save and exit the file.

• It will appear under the default namespace when you check with kubectl, but in reality, it is a static pod tied to the node

Step 3: Kubelet Detects and Starts the Pod

The kubelet on that node continuously watches the /etc/kubernetes/manifests/ directory.

As soon as the file is saved:

• Kubelet reads the manifest.

• It creates and starts the Pod automatically.

Step 4: Verify from the Master Node

On the master node (or from any node with kubectl access), run:

• The Pod is visible in the cluster.

• It’s tied to the node where the manifest was placed.

• Get Pods

kubectl get pods 
kubectl get pods -A

Shows pod name: nginx-static-pod-ip-172-31-25-213.

• Get Nodes

kubectl get nodes -o wide

Shows node ip-172-31-25-213 with internal IP 172.31.25.213.

• Get Pod Wide Info

kubectl get pod -o wide

• Confirms pod is on NODE: ip-172-31-25-213.

• A static pod always sticks to the particular node where its manifest is stored.

Step 5: Try to Delete from Master (Won’t Work)

If you try:

kubectl delete pod (pod-name)

The Pod will disappear briefly, but the kubelet will recreate it immediately because the manifest file still exists.

Step 6: Properly Remove the Static Pod

To permanently delete the Static Pod:

1. SSH into the node where the manifest is located.

Delete the YAML file:

rm /etc/kubernetes/manifests/nginx.yaml

2. Wait a few seconds. The kubelet will detect the file is gone and terminate the Pod.

Confirm from master:

kubectl get pods

• The Pod should no longer appear.

• kubelet detects the file is gone → it will stop and delete the pod from that node.

5. Advantages of Static Pods

• Do not depend on the API server

• Perfect for bootstrapping Kubernetes

• Guaranteed to run as long as kubelet is running

• Automatically restarted by kubelet if they fail

6. Limitations

• Not scalable for applications (because you must copy files on each node manually).

• No features like Deployments/ReplicaSets.

• To update or delete, you must directly edit/remove the file on the node.

• No rolling updates

• Harder to manage (SSH required for edits/removals)

• Not suited for regular application workloads