Let’s Begin With What You Might Know

So far, you know that Kubernetes runs your apps inside containers, but not directly. It runs Pods, which wrap around those containers.

But now the question is…

“Where are these Pods actually running?”
“Who decides when, where, and how they run?”

To answer that, we need to understand:

• What a Node is
• What a Cluster is
• And what the Control Plane does

Let’s break it down.

What Is a Node?

A Node is simply a machine — physical or virtual — where your app runs.
It can be:

• A cloud VM (like AWS EC2, GCP Compute Engine)
• A bare metal server
• Even your laptop in a local test setup

Each Node has:

• A container runtime (like Docker or containerd)
• Kubelet (the agent that talks to Kubernetes)
• And some networking components

🧩 Kubernetes schedules Pods onto these Nodes, based on available resources.

Think of Nodes as workers in a factory — they actually do the work (run the apps).

What Is a Cluster?

A Cluster is a group of Nodes that work together.

If a Node is like a worker, the Cluster is the entire factory — with all the workers, machines, and a management system in place.

In every Cluster, there are:

• Worker Nodes → Run the actual Pods (your apps)
• Control Plane Nodes → Make decisions and assign work

What Is the Control Plane?

The Control Plane is the brain of the cluster.
It doesn't run your app, but it tells everything else what to do.

The Control Plane includes several components:

💡 You can interact with the Control Plane using kubectl, which sends requests to the API Server.

Real-World Analogy

Let’s say you own a pizza delivery business.

• Orders = Pods (app pieces to be delivered)
• Workers = Nodes (actual delivery staff)
• Managers = Control Plane (they assign tasks, track orders, ensure delivery)
• Entire shop = Cluster (your whole operation)

You don’t give instructions to the delivery staff directly. You talk to the manager (API Server), who handles everything.

What Happens When You Run a Kubernetes Command?

Let’s say you run:

kubectl run myapp --image=nginx

Here’s what happens step-by-step:

1. kubectl sends your request to the API Server
2. The Scheduler decides which Node should run the Pod
3. The Controller Manager creates and tracks the Pod
4. The chosen Worker Node receives the instructions
5. The Kubelet on that Node pulls the image and starts the container inside a Pod

All this happens in seconds — and that’s the beauty of Kubernetes automation.

Quick Summary

• A Node is a machine (VM or physical) that runs your app
• A Cluster is a group of Nodes managed together
• The Control Plane makes decisions: what runs, where, and when
• You interact with Kubernetes via the API Server using kubectl
• The system is fully automated — Kubernetes handles the heavy lifting

Try It Out (Optional Hands-On)

Spin up a free Kubernetes Playground here:
👉 KodeKloud Kubernetes Playground

Run:

kubectl get nodes

You’ll see the Nodes available in your cluster.

Coming Up...

📅 Day 4: Deployments & ReplicaSets — How Kubernetes Runs and Manages Your App

We’ll explore:

• How Kubernetes creates and manages multiple copies of your app
• Why Deployments and ReplicaSets are essential
• And how updates happen without breaking everything

New here? Start from the beginning!
Catch up on the first two posts in our Kubernetes Basics in a Week series:

👉 Day 1: What Is Kubernetes & Why Should You Care?
👉 Day 2: What Are Pods in Kubernetes?