If kubelet Is a Worker Node Component, How Does It Manage Static Pods on the Master Node?

I always thought kubelet was a worker-node component.

Not because someone drilled it into me. It just made sense from every diagram I saw. The master node had the big-brain stuff — API Server, Scheduler, Controller Manager, etcd. The worker node had kubelet. Clean separation. Logical.

Then one afternoon, I was poking around a kubeadm cluster — no particular reason, just getting familiar with a new setup. I logged into the control-plane node and ran something out of habit:

systemctl status kubelet

I stared at it for a second. Ran it again. Same result.

kubelet was running on the control-plane node. But the diagram said it lived on worker nodes. So either the diagram was wrong, or I was missing something.

Turns out it was the second one. And the explanation opened up something I hadn't understood about how Kubernetes actually works.

The Assumption Most Beginners Make

Here's the diagram that started the confusion. You've probably seen some version of it:

  What every tutorial shows:

  Master Node                    Worker Node
  ├── API Server                 ├── kubelet
  ├── Scheduler                  ├── kube-proxy
  ├── Controller Manager         └── Application Pods
  └── etcd

  Logical conclusion: kubelet = worker-node thing.

Makes sense, right? The master handles orchestration. Workers run the actual workloads, and kubelet is the thing on workers that manages those pods. It's presented that way in almost every intro course.

The problem is that this diagram is a simplification. It shows roles, not the full picture of what actually runs on each node. And that gap causes a lot of confusion when you start looking at real clusters.

The Discovery

When I found kubelet running on the control-plane node, my first thought was that something was misconfigured. My second thought was that kubeadm just does weird things.

But then I started checking other clusters. Cloud-managed ones. Bare-metal setups from docs. kubelet was on the control-plane node in all of them.

So clearly this wasn't an accident. kubelet was supposed to be there.

But if kubelet is a worker-node component — what was it actually doing on the master?

The Question Gets Bigger

Here's where it got more interesting.

I ran kubectl get pods -n kube-system and looked at what was running on the control-plane node. There they were — the core components:

kubectl get pods -n kube-system
NAME                                    READY   STATUS    NODE
kube-apiserver-control-plane            1/1     Running   control-plane
kube-controller-manager-control-plane   1/1     Running   control-plane
kube-scheduler-control-plane            1/1     Running   control-plane
etcd-control-plane                      1/1     Running   control-plane

They're pods. Running on the control-plane node.

Pods need something to manage them. On worker nodes, that's kubelet's job. So if kubelet only lives on worker nodes — who's managing these pods on the master?

I had no good answer. And that question kept bugging me until I finally sat down and traced through how it actually works.

What kubelet Actually Is

Here's the thing the diagrams don't tell you: kubelet isn't a worker-node component.

It's a node agent. Its job is to manage pods on whatever node it runs on. It doesn't know or care whether that node is labeled “master” or “worker.” It just does its job — on the node it's installed on.

And kubelet runs on every node in a Kubernetes cluster. That includes the control-plane node.

The corrected picture looks like this:

  What is actually on each node:

  Control Plane Node             Worker Node
  ├── kube-apiserver             ├── kubelet
  ├── kube-scheduler             ├── kube-proxy
  ├── kube-controller-manager    └── Application Pods
  ├── etcd
  ├── kubelet      ← yes, it's here too
  └── kube-proxy

The difference between a control-plane node and a worker node isn't about which components are installed. It's about what workloads run there, and which control-plane services are present. kubelet is on both.

Once I understood this, the question shifted. It wasn't “why is kubelet on the master node?” anymore. It became: “okay, so how does kubelet on the control-plane node know which pods to run — before the API Server even exists?”

That's where Static Pods come in.

Static Pods

Normally, when you want a pod to run, you talk to the API Server. You apply a YAML file, the Scheduler picks a node, and kubelet on that node starts the pod. That's the standard flow.

Static Pods skip all of that.

kubelet watches a specific directory on the node:

/etc/kubernetes/manifests

Any YAML file you drop into that directory — kubelet picks it up and creates the pod. No kubectl apply. No API Server call. No Scheduler involved. Just kubelet reading a file from disk and making it happen.

  You drop a YAML file into:
  /etc/kubernetes/manifests/nginx-static.yaml

  kubelet is watching that directory.
  ↓
  kubelet detects the new file
  ↓
  Pod starts. No kubectl apply. No API Server call.
  ↓
  You can see it with: kubectl get pods

That's it. That's the whole mechanism. Simple, almost surprisingly so.

Create Your First Static Pod

The best way to understand this is to try it. On your control-plane node, create this file:

sudo nano /etc/kubernetes/manifests/nginx-static.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx-static
spec:
  containers:
    - name: nginx
      image: nginx:latest

Save the file. That's all you do.

You don't run kubectl apply. You don't restart anything. You just drop the file in that directory, and kubelet does the rest. Within a few seconds, the pod starts.

This surprises a lot of people the first time they see it, because it goes against how you normally think about pods in Kubernetes.

Verify the Static Pod

kubectl get pods
NAME                          READY   STATUS    NODE
nginx-static-control-plane    1/1     Running   control-plane

Notice the name: nginx-static-control-plane.

The node name gets appended automatically. That's how you spot a Static Pod — the suffix matches the node it's running on. It's Kubernetes telling you: “this one isn't managed by the scheduler, it's managed by kubelet directly.”

You can also see it under kube-system. What you're looking at there is called a mirror pod — a read-only copy in the API Server so you can observe the static pod using kubectl. But the API Server doesn't control it. kubelet does.

Where Are Static Pods Stored?

Now go look at what's already in that directory:

ls /etc/kubernetes/manifests/

etcd.yaml
kube-apiserver.yaml
kube-controller-manager.yaml
kube-scheduler.yaml

Those four YAML files are running the entire cluster.

Not a deployment. Not a Helm chart. Just four files in a directory that kubelet is watching. When kubelet sees them on startup, it creates the pods. The control plane comes up. The cluster is alive.

Sit with that for a second. Four files. That's the foundation.

The Bootstrap Problem

This is the part that finally made everything click for me.

Here's the problem: in Kubernetes, pods are created through the API Server. The Scheduler assigns them to nodes. kubelet starts them. That's the normal flow.

But the API Server is itself a pod. So is etcd. So is the Scheduler.

If those pods need the API Server to be created — but the API Server is one of those pods — then how does any of this ever start? You can't use the API Server to create the API Server. That's a circular dependency. The cluster could never boot.

Static Pods are the answer.

  Node boots up
      ↓
  kubelet starts (it's a systemd service — runs on its own)
      ↓
  kubelet reads /etc/kubernetes/manifests/
      ↓
  etcd.yaml found          → etcd pod starts
  kube-apiserver.yaml      → API Server starts
  kube-scheduler.yaml      → Scheduler starts
  kube-controller-manager.yaml → Controller Manager starts
      ↓
  Cluster is ready to accept your workloads

kubelet starts as a regular systemd service — it doesn't need the API Server. It reads the manifest files from disk. Those files tell it to start etcd, kube-apiserver, kube-scheduler, and kube-controller-manager. kubelet starts all four directly. No API Server involved in that step.

Once those pods are running, the cluster is live. From that point on, the API Server handles everything else — scheduling application workloads, accepting your kubectl commands, the whole normal flow.

But the first boot? That's kubelet, working alone, reading files.

How to Delete a Static Pod

This is where a lot of people get caught out the first time.

You decide to remove the nginx static pod. You run:

kubectl delete pod nginx-static-control-plane

The pod disappears. For about three seconds. Then it comes back.

Because kubelet is still watching /etc/kubernetes/manifests/. The manifest file is still there. As far as kubelet is concerned, that pod should exist. So it recreates it. Your kubectl delete didn't actually delete anything — it just deleted the mirror pod, and kubelet immediately put it back.

The only way to actually delete a static pod is to remove the manifest file:

sudo rm /etc/kubernetes/manifests/nginx-static.yaml

File gone → kubelet stops managing it → pod shuts down. That's the correct sequence.

What Happens If a Static Pod Crashes?

kubelet doesn't just start static pods — it keeps watching them.

If a container inside a static pod crashes, kubelet detects it and restarts it automatically. Same as it does for regular pods, but without needing the API Server to tell it to.

  Container inside static pod crashes
       ↓
  kubelet detects the failure
       ↓
  kubelet restarts the container automatically
       ↓
  No intervention needed — kubelet reconciles continuously

This matters a lot for the control plane. If kube-apiserver crashes at 3 AM, kubelet on the control-plane node catches it and restarts it — entirely on its own. No human needed. No other Kubernetes component needed. Just kubelet doing its job.

Verify Everything Yourself

If you have a kubeadm cluster or a lab environment, run these three commands on your control-plane node:

# 1. Confirm kubelet is running on the control-plane node
systemctl status kubelet

# 2. See the static pod manifests
ls /etc/kubernetes/manifests/
# etcd.yaml
# kube-apiserver.yaml
# kube-controller-manager.yaml
# kube-scheduler.yaml

# 3. See the static pods running in kube-system
# Notice the -<node-name> suffix on each one
kubectl get pods -n kube-system

Interview Corner

🎤 The 60-Second Answer

So — if kubelet is a worker-node component, how does it manage Static Pods on the master node?

The question itself is the wrong framing. kubelet isn't a worker-node component. It's a node agent that runs on every node. Once that clicks, everything else follows: kubelet is on the control-plane node, it watches /etc/kubernetes/manifests/, and those four files are what bring the entire cluster to life on every boot.

You weren't missing something complicated. You were missing one sentence that the beginner diagrams quietly leave out.