After this chapter, you should understand what is happening inside Kubernetes when you run:

kubectl apply -f deployment.yaml

We'll go from the big picture → individual components → complete request flow.

1. Kubernetes Architecture — Big Picture#

A Kubernetes environment is called a Cluster.

A cluster generally consists of:

                    Kubernetes Cluster
                           │
             ┌─────────────┴─────────────┐
             │                           │
        Control Plane                Worker Nodes
             │                           │
      ┌──────┼──────┐          ┌─────────┼─────────┐
      │      │      │          │         │         │
    API   Scheduler etcd      Node 1     Node 2    Node 3
   Server
      │                           │
      │                           ├── Pod
      │                           ├── Pod
      │                           └── Pod
      │
 Controllers

Think of it as:

Control Plane = Brain

Worker Nodes = Workers that run your applications

2. Control Plane vs Worker Node#

This distinction is fundamental.

Control Plane#

The Control Plane makes decisions about the cluster.

It handles things like:

• What should be running?
• Where should a Pod run?
• Is something broken?
• Should a new Pod be created?
• Should an application be scaled?

Worker Node#

Worker Nodes actually run your workloads.

For example:

Worker Node
│
├── Pod
│   └── Node.js container
│
├── Pod
│   └── Python container
│
└── Pod
    └── Nginx container

3. Control Plane Components#

The major components are:

Control Plane
│
├── kube-apiserver
├── etcd
├── kube-scheduler
└── kube-controller-manager

We'll understand each.

4. API Server#

The Kubernetes API Server is the primary entry point into the Kubernetes control plane.

You interact with Kubernetes through the API.

For example:

kubectl get pods

or:

kubectl apply -f deployment.yaml

Your request goes approximately like:

You
 │
 ↓
kubectl
 │
 ↓
Kubernetes API Server

The API Server then coordinates access to the cluster's state.

5. Why is the API Server so important?#

Almost everything communicates through the Kubernetes API.

For example:

kubectl
   ↓
API Server
 
Scheduler
   ↓
API Server
 
Controllers
   ↓
API Server
 
Kubernetes clients
   ↓
API Server

So you can think of the API Server as the front door of the Kubernetes control plane.

6. etcd#

This is another extremely important component.

etcd is Kubernetes' distributed key-value store.

It stores the cluster's state.

For example, Kubernetes needs to know:

How many Pods should exist?
Which Deployments exist?
Which Nodes exist?
What configuration exists?
What is the current state?

Much of this cluster state is stored in etcd.

Conceptually:

              API Server
                  │
                  ↓
                etcd
                  │
        ┌─────────┼─────────┐
        ↓         ↓         ↓
     Cluster    Pods     Deployments
      state

Simple analogy#

Think of etcd as the Kubernetes database for cluster state.

Don't treat it as your application's PostgreSQL/MongoDB database.

It is for Kubernetes' own state.

7. Scheduler#

Now imagine you create a Pod:

I need one Pod.

But your cluster has:

Node 1
Node 2
Node 3

Which node should run it?

That's where the Scheduler comes in.

New Pod
   ↓
Scheduler
   ↓
Choose suitable Node
   ↓
Node 2

The Scheduler considers things such as:

• Available CPU
• Available memory
• Scheduling constraints
• Affinity/anti-affinity
• Taints/tolerations
• Other scheduling rules

We'll study these later.

8. Controller Manager#

This component contains controllers that continuously work to move the cluster toward the desired state.

Remember our earlier concept:

Desired State ≠ Current State

The controllers try to reconcile that difference.

Example:

You want:

3 Pods

Current state:

2 Pods

A controller notices:

Desired = 3
Current = 2

and takes action so that eventually:

Current = 3

Conceptually:

Desired State
      ↓
Controller
      ↓
Compare
      ↓
Current State
      ↓
Take action

This reconciliation loop is one of the central ideas behind Kubernetes.

9. Worker Node Architecture#

Now let's look at a Worker Node.

A simplified node looks like:

Worker Node
│
├── kubelet
│
├── kube-proxy
│
├── Container Runtime
│
└── Pods

Let's understand each.

10. kubelet#

kubelet is the agent running on each worker node.

Its job is to make sure the Pods assigned to that node are running as expected.

Think:

Control Plane
      ↓
"Run this Pod on Node 1"
      ↓
kubelet
      ↓
Container Runtime
      ↓
Container

The kubelet communicates with the Kubernetes API Server and manages the workloads assigned to its node.

11. Container Runtime#

The container runtime is responsible for actually running containers.

Examples include:

containerd
CRI-O

Conceptually:

Kubernetes
     ↓
kubelet
     ↓
Container Runtime
     ↓
Container

You don't need to memorize runtime internals yet.

Just remember:

kubelet manages Pods on the node; the container runtime runs the containers.

12. kube-proxy#

kube-proxy is involved in implementing Kubernetes Service networking on nodes.

For example:

Client
  ↓
Service
  ↓
Pod

It helps establish the networking rules that allow traffic to reach the appropriate backend Pods.

Modern Kubernetes networking can involve other components too, so don't think of kube-proxy as "the entire networking system."

For now:

kube-proxy helps implement Service networking.

13. The Complete Architecture#

Now combine everything:

                         Kubernetes Cluster
                                │
             ┌──────────────────┴──────────────────┐
             │                                     │
       CONTROL PLANE                          WORKER NODES
             │                                     │
    ┌────────┼─────────┐                  ┌─────────┴─────────┐
    │        │         │                  │                   │
 API      Scheduler  Controller          Node 1              Node 2
Server     Manager   Manager              │                   │
    │                                    │                   │
    └─────── etcd                        │                   │
                                         │                   │
                                      kubelet             kubelet
                                         │                   │
                                  Container Runtime    Container Runtime
                                         │                   │
                                       Pods                Pods

14. Let's Deploy Something#

Now let's see what actually happens.

Suppose you create:

apiVersion: apps/v1
kind: Deployment
 
metadata:
  name: nginx
 
spec:
  replicas: 3
 
  selector:
    matchLabels:
      app: nginx
 
  template:
    metadata:
      labels:
        app: nginx
 
    spec:
      containers:
        - name: nginx
          image: nginx:latest

Don't worry if some of this YAML looks unfamiliar.

We'll learn it properly in later chapters.

The important part is:

replicas: 3

You're saying:

"I want three replicas of this application."

15. You Run kubectl#

You execute:

kubectl apply -f deployment.yaml

What happens?

Let's follow it.

16. Step 1 — kubectl Sends Request#

You
 ↓
kubectl
 ↓
API Server

kubectl communicates with the Kubernetes API Server.

17. Step 2 — API Server Validates Request#

The API Server processes the request.

It checks things such as:

• Is the request valid?
• Is the resource valid?
• Does the user have permission?
• Is the YAML structurally valid?

If accepted, the desired configuration becomes part of the cluster state.

18. Step 3 — State is Stored#

The cluster state is stored through the API Server in etcd.

Conceptually:

kubectl
   ↓
API Server
   ↓
etcd
   ↓
Deployment should exist
replicas = 3

Now Kubernetes knows:

"The desired state is 3 replicas."

19. Step 4 — Controller Notices#

The appropriate controller sees the Deployment.

The Deployment controller works toward the desired state.

Eventually the workload hierarchy becomes:

Deployment
    ↓
ReplicaSet
    ↓
3 Pods

So you don't normally manually create three Pods.

The Deployment manages the desired number of replicas.

20. Step 5 — Scheduler Finds Nodes#

The Pods need to be placed on worker nodes.

The Scheduler sees unscheduled Pods:

Pod 1 → ?
Pod 2 → ?
Pod 3 → ?

It evaluates the available nodes.

For example:

Node 1 → 4 CPU available
Node 2 → 2 CPU available
Node 3 → 8 CPU available

It chooses suitable nodes according to scheduling rules.

Maybe:

Pod 1 → Node 1
Pod 2 → Node 2
Pod 3 → Node 3

21. Step 6 — kubelet Takes Over#

Suppose Pod 1 is assigned to Node 1.

The kubelet on Node 1 learns about it.

API Server
    ↓
Node 1
    ↓
kubelet

The kubelet makes sure the Pod is actually created.

22. Step 7 — Container Runtime Runs Container#

The kubelet works with the container runtime.

kubelet
   ↓
containerd / CRI-O
   ↓
Pull nginx image
   ↓
Create container
   ↓
Start container

Now:

Pod
└── nginx container

is running.

23. The Entire Flow#

This is worth memorizing:

kubectl apply
      ↓
API Server
      ↓
etcd
      ↓
Controller
      ↓
Pod created
      ↓
Scheduler
      ↓
Node selected
      ↓
kubelet
      ↓
Container Runtime
      ↓
Container
      ↓
Pod Running

This is one of the most important flows in Kubernetes.

24. What if a Pod Dies?#

Suppose:

Desired:
3 Pods
 
Current:
3 Pods

Everything is good.

Then:

Pod 2 ❌

Now:

Desired = 3
Current = 2

The Kubernetes controllers detect the difference.

They work to restore:

Current = 3

Eventually:

Pod 1 ✅
Pod 2 ❌
Pod 4 ✅
Pod 3 ✅

The exact mechanics depend on the workload type, but the key idea is reconciliation.

25. What if a Node Dies?#

This is a bigger failure.

Suppose:

Node 1 ❌

and it was running:

Pod A
Pod B
Pod C

Kubernetes can detect that the node is unhealthy.

For workloads managed by controllers such as Deployments, Kubernetes can work toward recreating the required Pods on healthy nodes.

Node 1 ❌
     ↓
Pods unavailable
     ↓
Controllers reconcile desired state
     ↓
Healthy Nodes
     ↓
New Pods

This is part of Kubernetes' self-healing behavior.

26. Why etcd is so important#

Imagine the Control Plane temporarily loses a component.

Kubernetes needs persistent cluster state.

That's why etcd is critical.

Conceptually:

             etcd
              │
       Cluster State
              │
     ┌────────┼────────┐
     ↓        ↓        ↓
 Deployments Nodes    Pods

In production, etcd must be handled carefully because losing its data can affect the cluster.

Managed Kubernetes services such as EKS/GKE/AKS generally manage the control-plane infrastructure for you.

27. Control Plane = Decision Making#

A useful mental model:

                 CONTROL PLANE
                      │
          ┌───────────┼───────────┐
          ↓           ↓           ↓
       API Server  Scheduler  Controllers
          │           │           │
          └───────────┼───────────┘
                      ↓
                  Cluster State

And:

                 WORKER NODE
                      │
          ┌───────────┼───────────┐
          ↓           ↓           ↓
       kubelet    kube-proxy   Runtime
          │                       │
          └───────────┬───────────┘
                      ↓
                     Pods

28. Very Important: API Server Is Central#

You can think of the Kubernetes API as the communication hub.

                 API SERVER
                     │
       ┌─────────────┼─────────────┐
       ↓             ↓             ↓
    kubectl      Scheduler     Controllers
                     │
                     ↓
                  Nodes

This is why Kubernetes is often described as an API-driven system.

29. Interview Questions#

Q1. What is the Control Plane?#

The components responsible for managing the Kubernetes cluster's state and making orchestration decisions.

Q2. What does the API Server do?#

It exposes the Kubernetes API and serves as the primary entry point for interacting with the cluster.

Q3. What is etcd?#

A distributed key-value store used to persist Kubernetes cluster state.

Q4. What does the Scheduler do?#

It selects an appropriate node for unscheduled Pods.

Q5. What does kubelet do?#

It is the agent on each node that makes sure Pods assigned to that node are running as expected.

Q6. What does kube-proxy do?#

It helps implement Kubernetes Service networking on nodes.

Q7. What is the container runtime?#

The software responsible for running containers, such as containerd or CRI-O.

Q8. What happens when you run kubectl apply?#

At a high level:

kubectl
 ↓
API Server
 ↓
Cluster state
 ↓
Controllers
 ↓
Scheduler
 ↓
kubelet
 ↓
Container Runtime
 ↓
Container

🧠 Chapter 3 Cheat Sheet#

Memorize this diagram:

                 KUBERNETES CLUSTER
                         │
          ┌──────────────┴──────────────┐
          │                             │
    CONTROL PLANE                  WORKER NODE
          │                             │
    ┌─────┼─────┐                ┌──────┼──────┐
    │     │     │                │      │      │
   API  Sched  etcd           kubelet  proxy  runtime
   │
Controllers
                                      │
                                      ↓
                                     Pods

And remember the responsibilities:

API Server     → Communication / API
etcd           → Cluster state
Scheduler      → Choose node
Controllers    → Reconcile desired state
kubelet        → Manage Pods on node
Runtime        → Run containers
kube-proxy     → Service networking

🎯 Mini Exercise#

Before Chapter 4, try answering these without looking back:

1. You create a Pod. Who decides which Node it should run on?

2. What stores Kubernetes cluster state?

3. What component runs on every worker node and manages Pods?

4. What actually runs the container?

5. If desired replicas = 5 but only 4 are running, what Kubernetes concept works to correct this?

Answers#

1. Scheduler
2. etcd
3. kubelet
4. Container runtime
5. Controllers / reconciliation

Next → Chapter 4: kubectl#

Now we move from theory to actually controlling Kubernetes.

You'll learn commands like:

kubectl get pods
kubectl get nodes
kubectl describe pod
kubectl logs
kubectl exec
kubectl delete
kubectl apply
kubectl get all

And we'll set up a local Kubernetes cluster so you can actually run these commands rather than just reading about them.