The Control Loop and Your First Cluster

Compose runs your stack on one machine. When that machine dies, so does your service, and nothing brings it back until a person notices. Kubernetes exists for the other case: many machines, containers that must keep running when any one of them fails, and changes rolled out without downtime. To use it well, you need one idea more than any command.

The control loop

In Kubernetes you don’t say “start three containers”. You say “there should be three replicas of notes-api”, and store that as an object in the cluster. Then a controller runs a loop, continuously:

1. Observe the actual state: how many notes-api Pods exist and are running?
2. Compare it with the desired state in the object.
3. Act to close the gap: create a Pod, delete one, replace one.

The loop never finishes. If a node dies and takes a Pod with it, the next pass sees two where three are wanted and creates one. If you change the desired count to five, it creates two more. If someone deletes a Pod by hand, it’s replaced within seconds. This is what people mean by declarative: you describe the destination, and the system keeps steering towards it.

The thermostat comparison helps. You set 21°C; the thermostat doesn’t run a fixed “heat for 20 minutes” script. It measures, compares and switches the heater on or off for as long as it’s powered.

The parts of a cluster

• The API server is the front door. kubectl, controllers and kubelets all talk to it, and it validates, authenticates and authorises every request.
• etcd is a consistent key-value store holding every object. Only the API server talks to it.
• The scheduler watches for Pods without a node and picks one, based on free resources, constraints and spreading.
• The controller manager runs the built-in controllers: Deployments, ReplicaSets, Jobs, node health, and more.
• On every worker node, the kubelet watches for Pods assigned to its node and starts their containers through a container runtime, usually containerd. Your Docker-built images run there unchanged, because images follow the OCI standard.

Managed services like Amazon EKS run the control plane for you. You still need to understand it, because every error message you’ll read refers to one of these parts.

A cluster on your laptop

kind (“Kubernetes in Docker”) runs a whole cluster inside Docker containers. It’s quick to create and quick to throw away, which is exactly what you want for learning:

kind create cluster --name notes
kubectl config current-context      # kind-notes
kubectl get nodes
kind load docker-image notes-api:1.0.0 --name notes

The last command copies your local image into the kind node, so the cluster can run it without a registry. minikube and Docker Desktop’s built-in Kubernetes work too; the kubectl commands in this course are the same everywhere.

In kind, the control plane itself runs as Pods on the control-plane node. Run kubectl get pods -n kube-system and you’ll see the API server, etcd, the scheduler and the controller manager listed like any other workload, along with the cluster DNS (CoreDNS) and kube-proxy. On a managed cluster you won’t see the control plane there, because the provider runs it out of sight.

Watch the loop work

Create a Deployment imperatively, once, to see reconciliation with your own eyes:

kubectl create deployment notes-api --image=notes-api:1.0.0 --replicas=3
kubectl get pods
kubectl delete pod <one-of-the-pod-names>
kubectl get pods --watch

Within seconds a new Pod with a new name appears. You didn’t ask for it; the controller did its job. Now look at what you created:

kubectl get deployment notes-api -o yaml
kubectl explain deployment.spec.replicas
kubectl delete deployment notes-api

-o yaml shows the full object Kubernetes stored, including many defaults you didn’t set. kubectl explain documents any field from the cluster itself; it’s the fastest reference you have. From the next lesson on you’ll write these objects as files and apply them, which is how real teams work.

Next: the objects you just glimpsed, written properly. Pods, ReplicaSets and Deployments.