Why a cluster changes the question

Everything in this series so far has named machines. The Kamal configuration says hosts: [203.0.113.10], and you are the one who decided that this application runs on that server. When the server is full you add another line, and when the server is down you find out and act.

Kubernetes removes the line. You stop saying where and start saying what:

replicas: 3

Three copies of this application should be running somewhere in the cluster, on no particular machine. Deciding where is somebody else's job now, and that somebody is software.

The reconciliation loop

This is the central idea. Everything else in Kubernetes follows from it.

You write a description of the state you want and give it to the API server. A set of controllers continuously compares that description against what is running, and takes whatever action closes the gap. Nobody executes your instructions, because you wrote a description, not a list of steps.

flowchart LR
  Y["Your YAML: desired state"] --> A["API server"]
  A --> S[("etcd")]
  C["Controllers"] --> A
  C --> D{"desired == actual?"}
  D -->|"no"| ACT["create / delete / reschedule"]
  ACT --> N["nodes running your containers"]
  N --> C
  D -->|"yes"| W["do nothing"]

A pod's node catches fire. Actual is now two, desired is three, and something starts a third somewhere else, with no human in the loop. That is the property people are buying.

It is also why "I deleted the pod and it came back" is the first thing everyone learns the hard way. You deleted nothing the cluster cares about. You disturbed the actual state, and the loop corrected you.

The parts, briefly

A node is a machine, and the control plane is the set of parts above it. In a managed cluster (EKS, GKE, AKS) you rent the control plane and never see it. That removes the hardest part of running Kubernetes, and leaves the second-hardest to you.

The honest cost

This course teaches Kubernetes, so it starts by saying when not to use it.

The Kamal setup from two courses ago is about sixty lines of YAML and one command. The equivalent Kubernetes setup is a Deployment, a Service, an Ingress, a ConfigMap, a Secret, probes, resource requests and a rollout strategy: several hundred lines across several files. Add a cluster to run them on, and somebody who knows what a CrashLoopBackOff means at 3 a.m.

That trade is worth making when you have some of these:

• More applications than one team can place on machines by hand.
• Traffic that needs autoscaling instead of a number you set on Tuesday.
• A requirement that a lost machine repairs itself without a person.
• An organization already running a cluster, where being outside it costs more than being in it.

"Serious companies use it" is no reason to make it. A Rails application on one well-configured server with Kamal serves an enormous amount of traffic, and plenty of teams moved to Kubernetes and got slower.

The ability to read this stuff is always worth having, though. You will inherit clusters, review manifests, and talk to platform teams. That is what this course is for.

What this course covers

1. Why a cluster changes the question (you are here).
2. Pods and Deployments.
3. Services and getting traffic in.
4. Configuration and secrets.
5. Health, resources, and scheduling.
6. Running Rails on Kubernetes.
7. Putting it together: a full manifest set.

Key takeaways

• Kamal names machines; Kubernetes takes a description of desired state and decides placement itself.
• The reconciliation loop (controllers closing the gap between desired and actual) is the idea everything else follows from.
• The control plane is the API server, etcd, controllers and scheduler; a node runs a kubelet and your containers.
• Kubernetes costs hundreds of lines and an operational skillset; it earns that at many applications, real autoscaling, or self-repair requirements.
• Reading manifests is worth learning even when running a cluster is not.