🏗️ Kubernetes Architecture

Kubernetes Architecture: Think of a Kubernetes cluster as a company: the Control Plane is the management floor — CEO (API Server), memory/HR (etcd), scheduler (assigns tasks), ma

Think of a Kubernetes cluster as a company: the Control Plane is the management floor — CEO (API Server), memory/HR (etcd), scheduler (assigns tasks), managers (controllers) — while the Worker Nodes are the actual offices where work happens, each with a supervisor (kubelet), mailroom (kube-proxy), and employees (containers in pods). So why split 'decide what should happen' (Control Plane) from 'actually do the work' (Worker Nodes) instead of one component doing both? Because a single point that both decides AND executes can't keep deciding while it's busy executing — split the roles, and the company keeps making decisions (rescheduling a crashed pod) even while individual offices are under repair. It mirrors why a well-designed Java service separates its orchestration layer (a scheduler/coordinator) from its worker threads instead of doing everything on one thread. In production, this split is exactly why a single Worker Node going down doesn't take your whole cluster's decision-making down with it — the Control Plane just reschedules the affected pods elsewhere.

Kubernetes Cluster Architecture

Control Plane Components

kube-controller-manager

Worker Node Components

Practice: Read cluster architecture with kubectl

Fill TODO with cluster info, node list, kube-system pods, and node details.

How a Pod Request Moves Through the Cluster

kubectl sends request

A manifest or command goes to the API Server as an HTTPS request.

The API Server writes validated target state into etcd.

Scheduler picks node

A suitable node is selected by resources, taints, and affinity rules.

kubelet on the selected node asks the runtime to start the pod.