Kubernetes Architecture in Nutshell

Kubernetes has a master-worker architecture:
🧠 Control Plane (Master Node) – Manages the cluster
💼 Worker Nodes – Run the actual applications (pods/containers)
.
🏢 Kubernetes Cluster = A Restaurant
Imagine a well-managed restaurant. Each part of the restaurant maps beautifully to a Kubernetes component.
CONTROL PLANE = Restaurant Management Team
This team manages everything behind the scenes and ensures customers are served properly.
1. API Server = Reception Desk / Waiter
You (the customer) tell the waiter what food you want (
kubectl apply -f menu.yaml
)The waiter writes it down and passes the order to the kitchen (rest of the system)
Only way to interact with the restaurant is through the waiter
📌 Everything goes through the waiter (API Server)
2. etcd = Order Book / Ledger
Stores all orders placed, current status, reservations, recipes, etc.
Single source of truth for the restaurant
📌 etcd keeps track of everything that happens in the restaurant
3. Controller Manager = Kitchen Manager
Keeps track of all ongoing orders
Makes sure every order is being worked on
If a dish is dropped or late, re-assigns it to a new chef (restarts pods, replaces failed ones)
📌 Makes sure the restaurant serves exactly what was ordered
4. Scheduler = Table Manager / Dispatcher
Decides which chef (worker node) will cook which dish (pod)
Assigns dishes based on available skills, tools, or space
📌 Assigns the work to the right person in the kitchen
WORKER NODES = Chefs (Kitchen Staff)
These are the people actually doing the work — cooking food, plating, and serving.
1. kubelet = Head Chef
Gets orders (pod specs) from management
Ensures the dish is prepared exactly as specified
If something goes wrong, reports back to the manager
📌 Chef that makes sure each dish (pod) is prepared correctly
2. Container Runtime = Cooking Stove / Tools
Actually cooks the food (runs the containers)
The chef (kubelet) uses it to prepare dishes
📌 Does the actual cooking (executes app containers)
3. kube-proxy = Waiters / Food Runners
Knows which chef is cooking what
Delivers the food to the right customer
Handles incoming orders and balances them across chefs if busy (load balancing)
📌 Handles routing of food (network traffic) inside the restaurant
🍽️ Example Flow: Placing a Food Order
Customer: I want 2 plates of biryani!
↳ You run:kubectl apply -f biryani-deployment.yaml
Waiter (API Server): Takes your order
Order Book (etcd): Logs your order
Kitchen Manager (Controller): Notices the order needs 2 biryanis
→ Asks scheduler to pick available chefsTable Manager (Scheduler): Picks Chef A and Chef B (nodes)
Chef (kubelet): Starts cooking with the help of stove (container runtime)
Waiter (kube-proxy): Delivers the food to the customer
If Chef A drops the dish (pod crashes),
→ Kitchen Manager (Controller) assigns it to Chef C
I hope It helps you out in terms of Understanding the K8S Architecture in a better way.
if you want K8s related other articles you can follow and subscribe to the blog.
Subscribe to my newsletter
Read articles from Vikrant Raut directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by

Vikrant Raut
Vikrant Raut
I’m a DevOps engineer who lives in the world of AWS, automation, and cool tech stuff. I spend most of my time building cloud infrastructure, setting up CI/CD pipelines, and making sure things run smooth and fast. But that’s not all—I’ve also got a web development background, so I enjoy jumping into frontend or backend code when needed. You could say I’m kind of a full-stack problem solver. This blog is where I share things I learn, random tips, tech experiments, and the occasional rant when something breaks at 2 AM. If you’re into DevOps, cloud, or just curious about how things work behind the scenes—welcome aboard!