Kubernetes in a restaurant — full breakdown 👇
The reel gives you the mental model. Here’s what I skipped for time:
→ API Server (the waiter)
The front door of Kubernetes. Every request goes through it — from you, kubectl, controllers, everything. It validates requests and acts as the control plane entrypoint.
→ etcd (the order book)
A distributed key-value store holding cluster state: pods, nodes, configs, secrets.
Lose etcd, lose the cluster.
That’s why production setups run 3 or 5 replicas for high availability.
→ Scheduler (the head chef)
It doesn’t run your app.
It decides where your pod should run based on CPU, memory, affinity, taints, and constraints — then hands it off.
→ Kubelet (the cook)
Runs on every worker node.
Pulls images, starts containers, checks health, and reports back to the control plane.
→ Container Runtime (the stove)
The software actually running containers.
Usually containerd today.
Docker was the original standard, but Kubernetes moved toward container-native runtimes.
→ Controller Manager (the floor manager)
This is Kubernetes philosophy in one loop:
Observe current state
→ Compare to desired state
→ Fix the gap
That’s reconciliation.
One thing I skipped in the reel:
→ kube-proxy (the food runner)
Routes traffic to the right pod by managing networking rules on each node.
Covering that in the next reel.
Why “self-healing” is a big deal
Pod dies
→ Controller notices
→ New pod gets scheduled
→ Kubelet starts it
No human involved.
That’s how companies like Netflix, Spotify and Airbnb run thousands of services without babysitting infrastructure.
Save this for your next system design interview 🔖
Follow
@akashcode.official for more backend breakdowns.
#kubernetes #devops #backend #systemdesign #k8s cloudnative softwareengineering programming backenddeveloper devopsengineer docker containerization microservices cloudcomputing techeducation