What is Kubernetes? Architecture Explained
Video: Day 5/40 — What is Kubernetes — Kubernetes Architecture Explained • https://www.youtube.com/watch?v=SGGkUCctL4I • Duration: ~25 min
Key terms
| Term | Meaning |
|---|---|
| Control plane | The "brains" that manage the cluster |
| Worker node | A machine that runs application pods |
| kube-apiserver | Front door for all cluster operations |
| etcd | Key-value store holding all cluster state |
| scheduler | Assigns pods to suitable nodes |
| controller-manager | Runs the reconciliation control loops |
| kubelet | Node agent that runs and reports on pods |
| kube-proxy | Programs Service networking on each node |
Problem & solution
To operate or troubleshoot Kubernetes you must know which component does what. Treating the cluster as a black box makes failures impossible to reason about, so we first map the control plane and worker node pieces and how they interact.
Solution: Split work into a control plane (api-server, etcd, scheduler, controller-manager) that decides desired state and worker nodes (kubelet, kube-proxy, runtime) that run it.
The analogy
Picture a busy container shipping port. The harbor master's office never touches cargo itself; it makes decisions: a front desk takes every request, a master ledger records what should be where, a berth clerk assigns waiting ships to docks, and floor supervisors keep reality matching the plan. Down on the water, each dock has a foreman who actually ties up ships and reports back. Kubernetes is that port: the control plane (api-server, etcd, scheduler, controller-manager) decides, and each worker node (with its kubelet) carries it out. We reuse this same port across the whole course, so every later day just adds one more part of the harbor.
Where this fits in the cluster
The same cluster entities appear in every day's notes; the diagram below shows where this day's topic fits.
Graph legend — each node maps to a real Kubernetes component:
| Graph node | Maps to | What it does |
|---|---|---|
| api-server | kube-apiserver | Front door; validates and serves the API |
| etcd | the etcd datastore | Key-value store of all cluster state |
| scheduler | kube-scheduler | Assigns pods to nodes |
| controller-manager | kube-controller-manager | Runs reconciliation control loops |
| Worker Node | a node running kubelet, kube-proxy, runtime | Hosts and reports on pods |
| Pod / container - nginx:1.27 | a pod and its nginx:1.27 container | The actual workload being run |
Cluster = Control Plane + Worker Nodes
A cluster splits into a control plane that makes decisions and worker nodes that run the actual workloads.
Graph legend — each node maps to a real control-plane or node component:
| Graph node | Maps to | What it does |
|---|---|---|
| kube-apiserver | kube-apiserver | The only entry point; everything talks here |
| etcd | etcd | Consistent key-value store, the source of truth |
| scheduler | kube-scheduler | Picks the best node for new pods |
| controller-manager | kube-controller-manager | Runs node/replication/endpoint control loops |
| cloud-controller | cloud-controller-manager | Integrates LBs, volumes, and nodes with the cloud |
| kubelet | the kubelet on each node | Ensures the node's pod containers run and stay healthy |
| kube-proxy | kube-proxy | Programs Service networking rules on the node |
| container runtime | containerd / CRI-O | Actually pulls images and runs containers |
Control Plane components
The control plane is the cluster's brain — these components decide what should run and where.
| Component | Role |
|---|---|
| kube-apiserver | The only entry point. Validates & serves the K8s API. Everything goes through it. |
| etcd | Consistent key-value DB. Stores the entire cluster state ("source of truth"). |
| kube-scheduler | Watches for unscheduled pods, picks the best node (resources, taints, affinity). |
| kube-controller-manager | Runs controllers (node, replication, endpoints...) that drive desired state. |
| cloud-controller-manager | Integrates with cloud APIs (load balancers, volumes, nodes). |
Worker Node components
Each worker node runs these agents to host pods and wire up their networking.
| Component | Role |
|---|---|
| kubelet | Agent on each node. Talks to API server, ensures pod containers are running/healthy. |
| kube-proxy | Maintains network rules so Services route traffic to the right pods. |
| container runtime | Actually runs containers (containerd / CRI-O). |
How a pod gets created (request flow)
Creating a pod is a relay: the request flows through the API server, gets stored, scheduled, then run on a node.
Graph legend — each node maps to a step in creating an nginx pod:
| Graph node | Maps to | What it does |
|---|---|---|
| kubectl apply -f nginx-pod.yaml | the kubectl request | Submits the desired pod to the API |
| 1 kube-apiserver validate | kube-apiserver | Authenticates, validates, and admits the request |
| 2 etcd | etcd write | Persists the desired pod spec |
| 3 scheduler picks a node | kube-scheduler | Binds the pod to a suitable node |
| 4 kubelet sees the assignment | the node's kubelet | Notices the pod bound to its node |
| 5 container runtime pulls nginx:1.27 | containerd/CRI-O | Pulls the image and starts the container |
| 6 kubelet reports status | kubelet → apiserver → etcd | Records actual state back into the cluster |
Mental model
A quick analogy for who does what across the control plane and each node.
etcd = the database (what SHOULD exist)
apiserver= the receptionist (all requests pass through)
scheduler= the planner (where things go)
controllers = the workers (keep reality == desired)
kubelet = the foreman on each node (make it so locally)
End-to-end flow
How one kubectl apply becomes a running pod across the control plane and the node.
Graph legend — each participant maps to a real component in the nginx pod flow:
| Graph node | Maps to | What it does |
|---|---|---|
| kubectl | the kubectl client | Submits apply nginx-pod.yaml |
| API server | kube-apiserver | Central hub all messages pass through |
| etcd | etcd | Stores both desired and actual state |
| Scheduler | kube-scheduler | Watches unscheduled pods and binds them to a node |
| kubelet | the node agent | Sees the binding and drives the runtime |
| Runtime | containerd/CRI-O | Pulls nginx:1.27 and runs the container |
Key takeaways
- All communication flows through the API server.
- etcd is the single source of truth — back it up (covered Day 35).
- Scheduler decides placement; kubelet executes on the node.
Checklist
- [ ] Can name all control-plane and node components and their jobs
- [ ] Can trace the pod-creation request flow end to end