Lesson 2 · Core objects & the control plane
Cluster architecture
Who runs the control loop, and who runs your containers — the control plane vs the nodes.
Your win: name the control-plane components (api-server, etcd, scheduler, controller-manager) and the node components (kubelet, kube-proxy, runtime), and say what each one does — a guaranteed CKA/interview question.
Two halves of a cluster
A Kubernetes cluster splits into the control plane (the brain — makes decisions) and the nodes (the muscle — run your Pods).1
CONTROL PLANE (the brain) NODES (the muscle)
┌────────────────────────────────┐ ┌──────────────────────────┐
│ kube-apiserver ◄── kubectl │ │ kubelet kube-proxy │
│ │ │◄──────►│ │ │
│ etcd (state) │ │ containerd → your Pods │
│ scheduler controller-manager │ └──────────────────────────┘
└────────────────────────────────┘ ┌──────────────────────────┐
│ kubelet … more nodes … │
└──────────────────────────┘
Control plane — the brain
| Component | Job |
|---|---|
| kube-apiserver | the front door — the only component that reads/writes cluster state. Everything (kubectl, controllers, kubelets) talks through it. |
| etcd | a consistent, highly-available key-value store holding all cluster state. The api-server is its only client. |
| kube-scheduler | watches for Pods with no node assigned and picks a suitable node for each (resources, affinity, taints — Lesson 10). |
| kube-controller-manager | runs the controllers — the reconcile loops from Lesson 1 (Deployment, ReplicaSet, node, …). |
The mental picture
The api-server is the hub; etcd is its memory. Controllers
and the scheduler don't talk to each other or to nodes directly — they watch the
api-server for changes and write back through it. That single choke-point is why
RBAC (Lesson 12) can secure the whole cluster: control one door.
Nodes — the muscle
| Component | Job |
|---|---|
| kubelet | the node agent: takes the Pods assigned to its node, tells the runtime to start their containers, runs the probes (Lesson 8), and reports status back to the api-server. |
| kube-proxy | programs the node's networking so traffic to a Service reaches the right Pods (Lesson 5). |
| container runtime | containerd (or similar) — actually runs the containers. The OCI runtime from Course 1. |
Anchor — you've been talking to these all along
When Course 1's
sk.bash ran kubectl rollout restart deploy/bob,
that request hit the api-server, which updated the Deployment in
etcd; the controller-manager rolled a new ReplicaSet, the
scheduler placed the new Pods, and each node's kubelet
started them and ran the grpc_health_probe readiness check
(deployments/helm/libs/util/templates/_workload_containers.tpl:92).
Your kind cluster (Course 1 L6) runs this whole control plane inside Docker containers.
Managed vs self-run
In prod this repo runs on GKE (Course 7), where Google operates the control
plane for you — you only manage nodes and workloads. Locally, kind gives
you the full thing on your laptop. Either way the components are the same; that's why the
cert tests them.
Read this next
Kubernetes docs — Cluster architecture & components
The canonical diagram and one-line role for each component. Memorise this page for the CKA.
→ kubernetes.io — Cluster Architecture
→ kubernetes.io — Components
Check yourself (from memory)
Q1. The only component that reads/writes cluster state is…
The api-server is the hub; it's etcd's only client, and
everything else talks through it.
Q2. Which component runs on each node and starts its Pods?
The kubelet takes its node's assigned Pods, drives the
runtime, runs probes, and reports status.
Q3. Deciding which node a new Pod runs on is the job of…
The scheduler watches for unassigned Pods and binds each to
a suitable node; the kubelet then runs it.
Name the control-plane and node components, one job each.
recall, then click to reveal
CONTROL PLANE (brain): kube-apiserver — the front
door, only writer of state, everything talks through it; etcd — consistent
key-value store of ALL cluster state; kube-scheduler — assigns unscheduled
Pods to nodes; kube-controller-manager — runs the reconcile loops. NODES
(muscle): kubelet — node agent, starts Pods, runs probes, reports status;
kube-proxy — programs Service networking; container runtime
(containerd) — actually runs the containers. Controllers/scheduler don't talk to nodes
directly — they watch + write via the api-server. Repo: prod = GKE (managed CP), local =
kind (full CP in Docker).
Want to know why etcd needs an odd number of members, or what "watch" means at the api
level? Ask me.