Kubernetes Architecture in Nutshell

Vikrant RautVikrant Raut
3 min read

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

  1. Customer: I want 2 plates of biryani!
    ↳ You run: kubectl apply -f biryani-deployment.yaml

  2. Waiter (API Server): Takes your order

  3. Order Book (etcd): Logs your order

  4. Kitchen Manager (Controller): Notices the order needs 2 biryanis
    → Asks scheduler to pick available chefs

  5. Table Manager (Scheduler): Picks Chef A and Chef B (nodes)

  6. Chef (kubelet): Starts cooking with the help of stove (container runtime)

  7. Waiter (kube-proxy): Delivers the food to the customer

  8. 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.

0
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!