The Cluster
A Kubernetes cluster has two kinds of machines: a control plane that manages the cluster, and worker nodes that run your applications.
Kubernetes Cluster
┌────────────────────────────┐
│ Control Plane │
└────────────────────────────┘
│
┌─────────┴─────────┐
▼ ▼
Worker Node 1 Worker Node 2
Zooming in, each side runs a fixed set of components:
┌─────────────────── Control Plane ───────────────────┐
│ │
│ API Server ←──── kubectl / CI/CD │
│ │ │
│ etcd Scheduler Controller Manager │
└──────────────────────────────────────────────────────┘
│
┌──────────┼──────────┐
↓ ↓ ↓
Node 1 Node 2 Node 3
┌────────┐ ┌────────┐ ┌────────┐
│kubelet │ │kubelet │ │kubelet │
│kube- │ │kube- │ │kube- │
│ proxy │ │ proxy │ │ proxy │
│Pod Pod │ │Pod Pod │ │Pod Pod │
└────────┘ └────────┘ └────────┘
Master vs Worker
| Control Plane (Master) | Worker Node |
|---|---|
| Manages the cluster | Runs applications |
| API Server | kubelet |
| etcd | kube-proxy |
| Scheduler | Pods |
| Controller Manager | Containers |
The control plane makes decisions — what runs where, how many replicas, what to do when something fails. Worker nodes carry them out. The control plane holds kube-apiserver, etcd, kube-scheduler, and kube-controller-manager; every worker runs kubelet, kube-proxy, and a container runtime. The next lesson examines each component in detail.
The Request Flow
Every change to a cluster — whether from a developer's terminal or a CI/CD pipeline — follows the same path:
Developer
│
kubectl apply
│
▼
API Server (validates and receives the request)
│
▼
etcd (desired state is recorded)
│
▼
Scheduler (picks the best worker node)
│
▼
Worker Node (kubelet starts the containers)
│
▼
Pod Running
Nothing talks to the cluster except through the API Server, and nothing is "true" in the cluster until it's written to etcd. Keep this flow in mind — every object you create for the rest of this course (Pods, Deployments, Services) travels exactly this route.