Cluster Architecture

Deep-dive into control plane and node components.

beginner60 minRead → Lab → Quiz → Practice

🧠 Brain Warm-Up

🧠 Brain Warm-Up: When you run a command like kubectl apply, does the command communicate directly with the worker nodes or does it talk to something else? How do the worker nodes learn about your request? Think about this flow of communication.

The Two Planes

A Kubernetes cluster is split into two logical areas: the Control Plane (the brain) and the Worker Nodes (the brawn).

Control Plane — makes global decisions (scheduling, handling events). Never runs your actual workloads.

kube-apiserver — the front door; exposes the Kubernetes API and validates incoming requests.
etcd — the cluster's database; stores all state as a key-value database.
kube-scheduler — watches for new Pods and decides which node each Pod runs on based on resource needs.
kube-controller-manager — runs loops to maintain desired state (e.g., node controller, replica controller).

Worker Nodes — host the actual containers that run your apps. Each node has:

kubelet — the node foreman; ensures containers are running in a Pod according to instructions.
kube-proxy — manages network routing rules for Services (directs traffic to Pods).
container runtime — the software engine (typically containerd) that pulls images and runs the containers.

Kubernetes Cluster Architecture Topology

┌────────────────────────────────────────────────────────┐
│                    CONTROL PLANE                       │
│  ┌───────────────┐              ┌───────────────────┐  │
│  │  kube-apiserver ◄────────────►       etcd        │  │
│  └──────┬──────▲─┘              └───────────────────┘  │
│         │      │                                       │
│  ┌──────▼──────┴───────┐        ┌───────────────────┐  │
│  │ kube-controller-mgr │        │  kube-scheduler   │  │
│  └─────────────────────┘        └───────────────────┘  │
└─────────┬──────▲───────────────────────────────────────┘
            │      │  (Secure HTTPS communication via API Server port 6443)
┌─────────▼──────┴───────────────────────────────────────┐
│                      WORKER NODE                       │
│  ┌─────────────────────┐        ┌───────────────────┐  │
│  │       kubelet       │        │    kube-proxy     │  │
│  └──────────┬──────────┘        └─────────┬─────────┘  │
│             ▼                             ▼            │
│      containerd (CRI)               iptables (Routing) │
│    ┌───────────────────┐                               │
│    │  Pod 1   │ Pod 2  │                               │
│    └───────────────────┘                               │
└────────────────────────────────────────────────────────┘

The Reconciliation Loop

Kubernetes works on a declarative model: you declare your desired state (e.g., "run 3 replicas of web-app") and Kubernetes continuously compares it to actual state (e.g., "only 2 replicas are running"). If a discrepancy exists, controllers take action to reconcile it.

You apply YAML (desired: 3 pods)
        ↓
API Server stores it in etcd
        ↓
Controller Manager sees: actual=0, desired=3
        ↓
Creates 3 Pods, Scheduler assigns them to nodes
        ↓
kubelet on each node starts the containers
        ↓
Status updated back to etcd via API Server

←

Why Kubernetes Exists

kubectl & kubeconfig

→