Lesson 1 · Core objects & the control plane

What Kubernetes is & the control loop

One idea underneath all of it: you declare desired state, and controllers reconcile toward it — forever.

Your win: explain what Kubernetes actually does in one sentence, and why "declarative desired state + a reconciliation loop" is the mental model that makes every other object in this course make sense.

The problem it solves

You have ~25 containerised services (Course 1). Each needs to run in several copies, across several machines, survive crashes, roll out new versions without downtime, scale with load, and find each other on the network. Doing that by hand — docker run on the right box, restart it when it dies, wire up load balancing — doesn't survive contact with production. Kubernetes is the system that does it for you. The official definition: an open-source platform for automating deployment, scaling, and management of containerised applications.1

The one idea: declarative desired state

You don't tell Kubernetes how to do things step by step. You declare what you want — "run 5 copies of this image, expose it on this port" — as an object with a spec (desired) and a status (observed). Kubernetes stores that and takes responsibility for making the world match.2

Declarative, not imperative Imperative: "start a container." Declarative: "there should always be 5 running." The difference is who owns the outcome. In the declarative model, if a Pod dies at 3am, you don't get paged to restart it — a controller notices status (4 running) drifted from spec (5 wanted) and creates a replacement. You described the goal; the system maintains it.

How it keeps the promise: the control loop

Behind every object type is a controller running the same loop, forever:

┌───────────────────────────────────────────┐ │ │ ▼ │ observe actual state ──► compare to desired spec │ (status) │ │ ▼ │ act to close the gap ───┘ (create/delete/update objects)

Observe → diff → act → repeat. This is reconciliation, and it's the single most important idea in Kubernetes: "it's control loops all the way down."3 A Deployment controller, a ReplicaSet controller, the scheduler — all the same shape. Learn this loop once and every object in Parts 1–3 is just "what does this controller reconcile?"

Anchor — you've already written desired state In Course 1 you saw skaffold render hydrate Helm templates into manifests. Those manifests are desired-state objects. In this repo a single library-chart macro — deployments/helm/libs/util/templates/_app.tpl:7 (util.app) — declares a whole app's worth of objects at once: a ConfigMap, Secret, PodDisruptionBudget, ServiceAccount, Deployment, Service, and autoscaler. You never tell the cluster "start a pod"; you commit a desired spec, Skaffold/CI applies it, and the controllers reconcile the rest. That's why nobody here runs kubectl run by hand.
Why this matters for the cert too CKA/CKAD questions almost always reduce to "make the cluster's actual state match this desired state." If you think imperatively you'll fight the tool. Think "what object, with what spec, and which controller reconciles it?"
Read this next

Kubernetes docs — Overview & Controllers

What Kubernetes is, the object/desired-state model, and the controller reconcile loop. Three short, canonical pages.

→ kubernetes.io — Overview
→ kubernetes.io — Controllers (the loop)

Check yourself (from memory)

Q1. The Kubernetes model is best described as…

You declare what (spec); controllers continuously drive actual state (status) toward it. Not step-by-step commands.

Q2. A Pod dies unexpectedly at 3am. What happens?

status (fewer pods) drifted from spec; the reconcile loop closes the gap by creating a replacement. Self-healing.

Q3. "Reconciliation" in Kubernetes means…

The control loop: watch actual state, diff against desired, take action to converge — forever, for every object type.
In one breath: what is Kubernetes, and what's the control loop?
recall, then click to reveal
KUBERNETES automates deploying, scaling & managing containerised apps. Core model = DECLARATIVE DESIRED STATE: you describe an OBJECT with a spec (what you want) and it has a status (what's observed). CONTROLLERS run a RECONCILE LOOP — observe status → compare to spec → act to close the gap → repeat, forever. So it SELF-HEALS (a dead pod is recreated) and you never issue step-by-step commands. "It's control loops all the way down." Repo: util.app (libs/util/…/_app.tpl:7) declares a whole app's desired objects; Skaffold/CI applies them; controllers do the rest.
Want to see the exact objects util.app emits, or how a controller "watches" the api-server? Ask me — the components are Lesson 2.

1. Kubernetes — Overview.

2. Kubernetes — Objects & desired state (spec vs status).

3. Kubernetes — Controllers.