Day 5: What is Kubernetes? Architecture Explained

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 <== marks what this day touches.

Cluster = Control Plane + Worker Nodes

A cluster splits into a control plane that makes decisions and worker nodes that run the actual workloads.

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.

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.

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