Kubernetes ArchitectureFrom the Control Plane to Worker Nodes

Previous tutorial: Container Orchestration →

In the previous tutorial we learned:

Docker
   ↓
Container
   ↓
Many Containers
   ↓
Kubernetes
   ↓
Cluster

Now the question is:

The main concepts in this tutorial:

• Node
• Cluster
• Control Plane / Master
• Worker Node
• API Server
• etcd
• Scheduler
• Controllers
• Container Runtime
• Kubelet
• kubectl

These are the core building blocks of Kubernetes architecture.

1. What is a node?

A node is a machine where Kubernetes components run and where workloads can run.

A node can be:

• Physical Server
• Virtual Machine
• Cloud Instance

Put simply:

Example:

Node 1 → Application workloads

Node 2 → Backend workloads

Node 3 → Database-related workloads

In older Kubernetes terminology, a node was sometimes called a:

But today the standard term is:

2. What is a cluster?

A cluster is a group of multiple nodes that Kubernetes manages together.

Example:

Kubernetes Cluster
│
├── Node 1
├── Node 2
└── Node 3

Say you only have one node:

Node 1
  ↓
Application

If Node 1 fails:

Node 1 ❌
  ↓
Application Down ❌

But with multiple nodes:

Node 1

Node 2

Node 3

Kubernetes can run the workloads on the other available nodes.

That is why a cluster gives you:

• Better availability
• More capacity
• Workload distribution
• Failure recovery
• Scalability

A simple definition:

3. What is the master node / control plane?

Kubernetes used to often call it the:

In modern terminology it is usually called the:

The control plane is the management layer of a Kubernetes cluster.

A simple analogy:

It decides and manages:

• Which workloads run where
• Which nodes are available
• What the cluster’s desired state is
• Whether any workload has failed
• Whether a new workload needs to be scheduled
• What the cluster configuration is
• Whether scaling or recovery is needed

Conceptually:

              Control Plane
                    ↓
        ┌───────────┼───────────┐
        ↓           ↓           ↓
     Node 1      Node 2      Node 3

The control plane mainly manages the cluster.

Application workloads usually run on worker nodes.

4. Worker Node vs Control Plane

The difference is very simple.

Company analogy:

Control Plane = Manager

Worker Nodes = Employees

Containers / Pods = Actual Work

The manager doesn’t do all the work.

The manager decides:

5. Kubernetes Architecture Overview

Basic architecture:

                    Kubernetes Cluster
                           │
              ┌────────────┴────────────┐
              │                         │
        Control Plane              Worker Nodes
              │                         │
     ┌────────┼────────┐         ┌──────┼──────┐
     │        │        │         │      │      │
 API Server  etcd   Scheduler  Kubelet Runtime Pods
              │
      Controller Manager

To make it a little clearer:

Kubernetes Cluster

Control Plane
├── API Server
├── etcd
├── Scheduler
└── Controller Manager

Worker Node 1
├── Kubelet
├── Container Runtime
└── Pods / Containers

Worker Node 2
├── Kubelet
├── Container Runtime
└── Pods / Containers

Now let’s go through them one by one.

6. API Server

The API Server is the main entry point to Kubernetes.

Put simply:

Most of the time, you don’t talk to Kubernetes directly.

You use:

kubectl

Then:

kubectl
   ↓
API Server
   ↓
Kubernetes

Example:

kubectl get nodes

Here, kubectl sends a request:

The request goes:

kubectl
   ↓
API Server

The API Server then processes the required information.

Who can communicate with the API Server?

Not just kubectl.

Example:

kubectl

Dashboard

External Application

Automation Tool

CI/CD Pipeline

Management Platform
        ↓
    API Server

So you can think of the API Server as:

7. etcd

etcd is a:

At first, you can simply think of it as:

The important state of the Kubernetes cluster is stored here.

For example:

• Nodes information
• Cluster configuration
• Workload state
• Kubernetes objects
• Metadata
• Desired state

Example:

If you tell Kubernetes:

I want 3 replicas of my application.

this desired configuration is persisted as part of Kubernetes’s cluster state.

Why is etcd important?

Say Kubernetes needs to know:

That is when it needs the stored cluster state.

Conceptually:

Kubernetes
    ↓
   etcd
    ↓
Cluster State

An easy way to remember it:

8. Scheduler

The Scheduler decides which node a new workload runs on.

Very important:

The Scheduler only decides:

Example:

You have:

Node 1

CPU available: 20%

Node 2

CPU available: 70%

Node 3

CPU available: 40%

Now a new workload arrives.

The Scheduler can weigh various factors and decide:

New Pod
   ↓
Scheduler
   ↓
Node 2 selected

Scheduler considerations can include:

• Available CPU
• Available Memory
• Node availability
• Resource requirements
• Scheduling constraints
• Affinity / Anti-affinity
• Taints / Tolerations

For now, just remember this:

9. A simple Scheduler example

You say:

Run my application.

Kubernetes needs to create a new Pod.

Flow:

New Pod Required
       ↓
Scheduler checks Nodes
       ↓
Node 1?
Node 2?
Node 3?
       ↓
Scheduler selects Node 2

After that, the worker node’s components handle actually starting the workload.

10. What are controllers?

Controllers continuously observe the cluster.

Their main goal:

We saw this concept in the previous tutorial.

Say you have said:

Desired State
=
3 application replicas

Currently:

App 1 ✅
App 2 ✅
App 3 ✅

Actual:

3

All good.

Suddenly:

App 2 ❌

Now:

Desired State = 3

Actual State  = 2

The controller detects:

Then Kubernetes starts the process of creating a new instance.

In the end:

Desired = 3

Actual  = 3

It matches again.

11. Think of controllers as supervisors

Company analogy:

Manager says:
"We need 3 workers."

Supervisor checks:
Worker 1 ✅
Worker 2 ✅
Worker 3 ❌

Supervisor:
"We're missing one."

New Worker added

Total = 3 ✅

That is the basic idea of a controller.

12. Controller Manager

Kubernetes doesn’t have just one kind of controller.

There are many different controllers.

Many of them run through a component called the:

At beginner level, remember:

Controller Manager
        ↓
Controllers
        ↓
Watch Cluster
        ↓
Detect Difference
        ↓
Take Corrective Action

13. Container Runtime

Now let’s move on to the worker node.

Who actually runs the container?

Kubernetes itself does not do the low-level work of creating Linux processes/containers directly.

For that, it needs a:

The container runtime’s job:

Common examples:

• containerd
• CRI-O

Because container concepts are usually taught with Docker, Docker examples are very common in tutorials.

Concept:

Kubernetes
    ↓
Kubelet
    ↓
Container Runtime
    ↓
Container

A simple definition:

14. Kubelet

The Kubelet is a very important component in Kubernetes architecture.

Every worker node runs a:

Example:

Worker Node 1
├── Kubelet
├── Container Runtime
└── Application Pods

You can think of the Kubelet as:

15. What does the Kubelet do?

The Kubelet’s responsibilities include:

• Managing the workloads on its node
• Following the desired workload information from the control plane
• Starting containers through the container runtime
• Monitoring Pod/container status
• Reporting node health/status

Simple flow:

Control Plane
     ↓
Workload should run on Node 1
     ↓
Kubelet on Node 1
     ↓
Container Runtime
     ↓
Container starts

16. The relationship between the API Server and the Kubelet

In simplified form:

API Server
    ↓
Kubelet
    ↓
Container Runtime
    ↓
Container

In other words, it is the Kubelet on the worker node that ultimately helps carry out the control plane’s decisions.

A simple analogy:

API Server = Head Office

Kubelet = Local Branch Manager

Container Runtime = Machine doing the work

17. Worker node architecture

A basic worker node:

Worker Node
│
├── Kubelet
│
├── Container Runtime
│
└── Application Workloads

And in Kubernetes terminology, application containers usually live inside this structure:

Pod
 ↓
Container

So a technically more useful diagram is:

Worker Node
│
├── Kubelet
├── Container Runtime
│
├── Pod 1
│   └── Container
│
└── Pod 2
    └── Container

18. Control plane architecture

Basic Control Plane:

Control Plane
│
├── API Server
├── etcd
├── Scheduler
└── Controller Manager

Now the roles side by side:

API Server
= Communication

etcd
= Cluster State

Scheduler
= Where should workload run?

Controller Manager
= Is desired state being maintained?

Once these four differences are clear, Kubernetes architecture becomes much clearer.

19. What is kubectl?

kubectl is Kubernetes’s command-line interface, or CLI.

You use kubectl to interact with a Kubernetes cluster from the command line.

A simple definition:

Concept:

You
 ↓
kubectl
 ↓
API Server
 ↓
Kubernetes Cluster

20. What can you do with kubectl?

Example:

• Cluster status check
• View nodes
• View Pods
• Deploy applications
• View logs
• Create/delete resources
• Apply configuration
• Troubleshoot

Example commands:

kubectl get nodes

kubectl get pods

kubectl cluster-info

21. kubectl get nodes

Command:

kubectl get nodes

Meaning:

Example output:

NAME       STATUS   ROLES

node-1     Ready    control-plane

node-2     Ready    worker

node-3     Ready    worker

Here:

NAME

The node’s name.

STATUS

Whether the node is ready.

Example:

Ready

Meaning the node can be used to run Kubernetes workloads.

ROLES

The role the node plays.

For example:

control-plane

worker

22. kubectl cluster-info

Command:

kubectl cluster-info

This is used to show the cluster’s important endpoints and information.

Concept:

kubectl cluster-info
        ↓
Cluster-related information

23. kubectl run

In the tutorial you may see:

kubectl run

This command can be used to create a basic workload/Pod.

Example concept:

kubectl run
    ↓
API Server
    ↓
Kubernetes
    ↓
Pod created

When you learn about deploying production applications, you will later see more important objects, especially:

So this will become common:

Deployment
   ↓
ReplicaSet
   ↓
Pods
   ↓
Containers

24. Full Request Flow

Now the most important part of the architecture.

Say you tell Kubernetes:

Simplified flow:

You
 ↓
kubectl
 ↓
API Server
 ↓
Kubernetes desired state
 ↓
Scheduler
 ↓
Worker Node selected
 ↓
Kubelet
 ↓
Container Runtime
 ↓
Container starts

This is the main flow.

25. Step-by-Step Example

Say you deploy an application.

Step 1 — kubectl

You run a command:

kubectl

Step 2 — API Server

kubectl sends the request:

kubectl
   ↓
API Server

The API Server receives and processes the request.

Step 3 — Cluster State

Kubernetes persists the desired configuration/state.

Conceptually:

API Server
    ↓
Cluster state
    ↓
etcd

Step 4 — Scheduler

Kubernetes sees that the workload has not been assigned to a node yet.

The Scheduler checks:

Node 1

Node 2

Node 3

and then chooses:

Node 2

Step 5 — Kubelet

The Kubelet on Node 2 sees:

Node 2
 ↓
Kubelet

Step 6 — Container Runtime

The Kubelet helps the container runtime start the workload.

Kubelet
   ↓
Container Runtime
   ↓
Container

Step 7 — Controllers

Controllers continuously observe the system.

If the desired state is:

3 replicas

but the actual state is:

2 replicas

Kubernetes will take corrective action.

26. The whole architecture together

This diagram is very important:

                        YOU
                         │
                      kubectl
                         │
                         ▼
                ┌─────────────────┐
                │   API Server    │
                └────────┬────────┘
                         │
          ┌──────────────┼──────────────┐
          │              │              │
          ▼              ▼              ▼
        etcd         Scheduler     Controllers
          │              │              │
          └──────────────┼──────────────┘
                         │
                  CONTROL PLANE
                         │
                         ▼
               ─────────────────
                         │
            ┌────────────┴────────────┐
            ▼                         ▼
       Worker Node 1             Worker Node 2
            │                         │
         Kubelet                   Kubelet
            │                         │
     Container Runtime         Container Runtime
            │                         │
           Pods                      Pods
            │                         │
       Containers                Containers

27. Delivery Company Analogy

Now let’s understand the whole Kubernetes architecture through an analogy.

Imagine Kubernetes is a delivery company.

Example

You phone the company and say:

kubectl

Your phone/app.

You
↓
kubectl

API Server

Reception receives the request.

kubectl
↓
API Server

etcd

The request/state is recorded in the company system.

Scheduler

The dispatcher decides:

Kubelet

The local manager of the selected branch gets the instruction.

Container Runtime

The actual machinery/process starts the work.

Controller

The supervisor keeps checking:

28. Control Plane vs Worker Node — Final Comparison

Very simply:

Control Plane
=
DECIDE

Worker Node
=
EXECUTE

29. An easy trick for remembering the components

Control Plane

Remember:

A = API Server

E = etcd

S = Scheduler

C = Controllers

In other words:

Control Plane
│
├── API
├── etcd
├── Scheduler
└── Controller

Worker Node

Remember:

K = Kubelet

R = Runtime

P = Pods

Worker
│
├── Kubelet
├── Runtime
└── Pods

30. The most important concept

The most useful mental model from this whole tutorial:

                   Control Plane
                        │
                        │ decides
                        ▼
                  Worker Nodes
                        │
                        │ execute
                        ▼
                       Pods
                        │
                        ▼
                    Containers

And the user interaction:

User
 ↓
kubectl
 ↓
API Server
 ↓
Kubernetes

31. Relating it to your own cluster

When you look at a real Kubernetes cluster, you might see something like this:

Cluster
│
├── Control Plane Node 1
├── Control Plane Node 2
├── Control Plane Node 3
│
├── Worker Node 1
└── Worker Node 2

One reason for having multiple control plane nodes:

In other words, if one control plane node fails, managing the whole cluster doesn’t immediately become unavailable.

The worker nodes’ job:

32. An important correction

When learning, we often say:

More technically accurate:

Because the fundamental scheduling unit in Kubernetes is the:

And containers live inside the Pod.

In other words:

Scheduler
   ↓
Pod
   ↓
Node

And inside a node:

Node
 ↓
Pod
 ↓
Container

This distinction will become very important later.

33. The fundamental hierarchy of Kubernetes

Remember this from now on:

Kubernetes Cluster
        │
        ├── Control Plane
        │
        └── Worker Nodes
                │
                └── Pods
                     │
                     └── Containers

In other words:

This is one of the most important hierarchies in learning Kubernetes.

Final Simplified Explanation

Kubernetes architecture can be split into two major sides:

Control Plane
+
Worker Nodes

Control Plane

The brain of the cluster.

Its important components:

API Server

etcd

Scheduler

Controllers

Worker Node

Runs the application workloads.

Its important components:

Kubelet

Container Runtime

Pods / Containers

Users usually communicate with Kubernetes through:

kubectl

Flow:

kubectl
   ↓
API Server
   ↓
Scheduler
   ↓
Worker Node
   ↓
Kubelet
   ↓
Container Runtime
   ↓
Pod
   ↓
Container

Meanwhile:

etcd

stores the cluster state, and the

Controllers

check:

If not, Kubernetes tries to bring the system back to the desired state.

One-Line Summary

The most important diagram:

                 kubectl
                    │
                    ▼
              API Server
                    │
        ┌───────────┼───────────┐
        ▼           ▼           ▼
      etcd      Scheduler   Controllers
                    │
                    ▼
               Worker Node
                    │
                 Kubelet
                    │
             Container Runtime
                    │
                   Pod
                    │
                Container

And the shortest possible memory formula: