Kubernetes Architecture Explained Simply (With Real‑World Flow)

---

Introduction

Most Kubernetes architecture blogs show diagrams and definitions.

• Control Plane
• Nodes
• Pods
• Services

But when something breaks in production, those terms don’t help much.

You start asking:

• Why is my Pod stuck in Pending?
• Who decided this node?
• Why is nothing happening after deployment?

The problem is simple:

Kubernetes is often explained as components instead of a working system flow.

This post explains Kubernetes architecture the way you actually use it:

✅ How requests flow
✅ Who makes decisions
✅ What actually runs your workloads

---

1. The most important concept: Desired vs Actual State

Kubernetes is not just running containers.

It is constantly trying to:

Make the cluster match what you declared

Example:

• You say: “Run 3 Pods”
• Only 2 are running

Kubernetes will:

• Detect mismatch
• Automatically create 1 more

This loop is called reconciliation, and everything in the architecture exists for this purpose.

---

2. High‑level architecture (simple mental map)

Instead of memorizing components, remember this:

You → API Server → Control Plane → Node → Pod

Break it into:

✅ Control Plane → decides

✅ Worker Nodes → execute

---

3. Control Plane — where all decisions happen

The Control Plane is responsible for:

• Accepting requests
• Storing cluster state
• Deciding where workloads run
• Fixing mismatches

---

🔹 API Server (entry point)

Every operation goes through the API server.

Example:

kubectl apply -f deployment.yaml

➡️ Steps:

• API server receives request
• Validates YAML
• Stores it
• Notifies other components

👉 Without API server → nothing works

---

🔹 etcd (cluster memory)

• Stores everything:
  • Pods
  • Nodes
  • Secrets
  • ConfigMaps

Key idea:

👉 If etcd is lost → cluster forgets everything

---

🔹 Scheduler (placement engine)

When a Pod is created:

Scheduler decides where it will run.

Based on:

• CPU and memory
• Node labels
• Taints and tolerations
• Affinity rules

---

🔹 Controller Manager (correction engine)

Controllers continuously fix issues.

Example:

• Desired: 3 pods
• Running: 2 pods

➡️ Controller creates 1 new Pod

---

✅ Control Plane summary

• Does NOT run applications
• Only monitors and makes decisions

---

4. Worker Nodes — where workloads actually run

Worker nodes are where your application runs.

Each node contains:

---

🔹 Kubelet (node agent)

• Receives instructions from API server
• Ensures containers are running

---

🔹 Container Runtime

This actually runs containers.

Examples:

• containerd
• Docker (older setups)

---

🔹 Kube‑proxy (networking)

Handles:

• Service routing
• Traffic forwarding

Example:

• Service → Pod communication

---

5. Real request flow (VERY IMPORTANT)

Let’s trace what happens when you deploy something.

---

Step 1: You apply a deployment

kubectl apply -f deployment.yaml

---

Step 2: API Server stores it

• Validates YAML
• Saves in etcd

---

Step 3: Controller creates Pods

• Deployment controller sees: “need 3 replicas”

➡️ creates pods

---

Step 4: Scheduler assigns Node

Scheduler decides:

• Which node fits best

---

Step 5: Kubelet runs container

On selected node:

• Pulls image
• Starts container

---

Step 6: Pod becomes RUNNING

Now your app is live ✅

---

✅ Key insight

At every step:

Kubernetes is reacting to state, not executing a script

---

6. What happens when something breaks

This is where architecture understanding helps.

---

Case: Pod stuck in Pending

Flow:

• Pod created ✅
• Scheduler tries to place ❌

You check:

kubectl describe pod <pod-name> -n <namespace>

Look for:

• Insufficient CPU
• PVC waiting
• Node mismatch

---

Case: CrashLoopBackOff

Flow:

• Pod scheduled ✅
• Container starts ❌

You check:

kubectl logs <pod-name> -n <namespace>
kubectl logs <pod-name> -n <namespace> --previous

---

Case: Service not reachable

Flow:

• Pod running ✅
• Traffic routing ❌

You check:

kubectl get svc -n <namespace>
kubectl get endpoints -n <namespace>

---

✅ Pattern to remember

Problem	Component responsible
Pod Pending	Scheduler
Pod crashing	Container / Kubelet
Service issue	kube-proxy / networking
Config mismatch	Controller

---

7. Common misunderstandings

---

❌ “Kubernetes runs containers”

✅ Reality:

• Kubelet + runtime run containers
• Kubernetes orchestrates them

---

❌ “Logs will show everything”

✅ Reality:

• Many issues appear in Events, not logs

Use:

kubectl describe pod <pod-name>

---

❌ “Restarting fixes issue”

✅ Reality:

• Restart hides real problem
• Controllers will recreate failing pods again

---

8. Final Mental Model (Very Important)

If you remember only one thing:

Desired State → API Server → Controllers → Scheduler → Node → Pod

Everything works in a loop:

• Observe
• Compare
• Fix

---

Final takeaway

Kubernetes architecture is not about memorizing components.

It’s about understanding:

✅ Who receives the request
✅ Who decides placement
✅ Who runs the container
✅ Who fixes problems

Once you think this way:

• Debugging becomes easier
• Failures become predictable
• You stop guessing

---

🚀 InfraDecode Takeaway

Kubernetes is not about components — it’s about flow and decisions.
Every issue can be traced to: API Server → Scheduler → Node → Pod.
If you understand who made the decision, debugging becomes easier.
Think flow, not features — that’s how Kubernetes becomes predictable.