Kubernetes Architecture Overview: Control Plane, Worker Nodes & the Container Stack

#architecture #devops #infrastructure #kubernetes

Kubernetes is often described as a "container orchestration platform," but that description barely scratches the surface. To truly understand how it works, you need to see the full stack — from bare metal hardware up to the Pods running your workloads. Let's build that picture layer by layer.

1. The Full Stack: Bottom Up

┌─────────────────────────────────────────────────────────┐
│                   Cloud (Kubernetes)                    │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐              │
│  │   Pod    │  │   Pod    │  │   Pod    │              │
│  │[C]...[C] │  │[C]...[C] │  │[C]...[C] │              │
│  └──────────┘  └──────────┘  └──────────┘              │
├─────────────────────────────────────────────────────────┤
│                   Cluster Orchestration                 │
│  ┌──────────────────┐  ┌──────────┐  ┌──────────────┐  │
│  │  Control Plane   │  │  Worker  │  │   Storage    │  │
│  │  kube-scheduler  │  │  Nodes   │  │              │  │
│  │  kube-controller │  │kube-proxy│  │     Etcd     │  │
│  │  kube-apiserver  │  │ kubelet  │  │              │  │
│  └──────────────────┘  └──────────┘  └──────────────┘  │
├─────────────────────────────────────────────────────────┤
│    Container Runtime (Docker / Containerd / CRI-O / Frakti) │
├─────────────────────────────────────────────────────────┤
│    Operating System (Linux / Windows / macOS)           │
├─────────────────────────────────────────────────────────┤
│    Hardware (x86 / ARM / s390x / ppc64le)               │
└─────────────────────────────────────────────────────────┘

2. Hardware & OS Layer

Kubernetes is designed to be platform-agnostic at both the hardware and OS level.

Layer	Supported options
CPU Architecture	x86, ARM, s390x, ppc64le
Operating System	Linux, Windows, macOS

This means the same Kubernetes cluster can orchestrate workloads across heterogeneous nodes — x86 cloud VMs alongside ARM edge devices, for example.

3. Container Runtime Interface (CRI)

Kubernetes does not run containers directly. It delegates container lifecycle management to a container runtime via the CRI (Container Runtime Interface):

Runtime	Notes
Docker	Original default; now deprecated as direct runtime (uses containerd underneath)
Containerd	Current industry standard; lightweight, CNCF graduated
CRI-O	Minimal runtime purpose-built for Kubernetes
Frakti	Hypervisor-based runtime for stronger isolation

Why the abstraction? Decoupling Kubernetes from any specific runtime means the ecosystem can evolve independently. New runtimes (e.g., gVisor, Kata Containers) can be plugged in without changing Kubernetes itself.

4. Cluster Components

Kubernetes components are divided into three functional groups:

Control Plane (Master Node)

The brain of the cluster — makes all global decisions about scheduling, state management, and API serving.

Component	Role
kube-apiserver	The single entry point for all cluster operations. Every component communicates through it. Exposes the Kubernetes REST API.
kube-controller-manager	Runs control loops that watch cluster state and drive it toward the desired state (e.g., ReplicaSet controller, Node controller).
kube-scheduler	Watches for unscheduled Pods and assigns them to appropriate nodes based on resource requirements, affinity rules, and policies.

Worker Nodes (Compute Nodes)

The muscle of the cluster — actually runs the workloads.

Component	Role
kubelet	Agent on every node. Receives Pod specs from the API server and ensures the described containers are running and healthy.
kube-proxy	Maintains network rules on each node. Implements the Kubernetes Service abstraction by routing traffic to the correct Pod endpoints.

Cluster Storage

Component	Role
etcd	Distributed key-value store. The single source of truth for all cluster state — configuration, secrets, service discovery, and more.

5. Pods & Containers

All workloads in Kubernetes run as Pods — the smallest deployable unit.

Pod
├── Container A  (your app)
├── Container B  (sidecar, e.g. log collector)
└── shared: network namespace, IPC namespace, volumes

A Container is an isolated process created by three Linux kernel primitives:

Primitive	What it provides
Namespace	Isolation of PID, network, mount, UTS, IPC — each container sees its own view of the system
Cgroup	Resource limits — CPU, memory, I/O quotas per container
Filesystem	Layered filesystem (UnionFS) — each container gets its own writable layer on top of a shared image

Containers are not VMs. They share the host OS kernel. The isolation is logical (via kernel features), not physical (no separate kernel per container). This is why containers start in milliseconds and have near-zero overhead.

6. Summary

Developer submits a Pod spec via kubectl
    ↓
kube-apiserver receives and stores it in etcd
    ↓
kube-scheduler detects unscheduled Pod
    assigns it to a node
    ↓
kubelet on that node receives the spec
    calls container runtime (containerd/CRI-O)
    ↓
Container runtime creates the container
    using Linux namespaces + cgroups
    ↓
kube-proxy updates network rules
    Pod is reachable via Service  ✅

Layer	Key Abstraction
Hardware	Multi-arch support (x86, ARM, ...)
OS	Linux/Windows node support
Container Runtime	CRI — pluggable runtime interface
Control Plane	API server + scheduler + controllers
Worker Node	kubelet + kube-proxy
Storage	etcd — distributed truth store
Workload	Pod → Container (namespace + cgroup + fs)