The Harbor Master (pods, deployments, services)

The objects a cluster actually keeps records of, and how one creates the next. This lesson follows one line you write all the way down to a running container, and names every object it passes through.

Before you start. A container is one program sealed in a box with everything it needs, running on a machine; an image is the frozen copy of that box you start containers from. From One Crate to a Fleet (why Kubernetes) showed the reconcile loop: a cluster does nothing but compare what you asked for against what is running, over and over, and fix the gap. This lesson is about the records that loop reads: what you actually write, and what it turns into.

The idea in 30 seconds

A cluster only understands records. Write a Deployment, and the running count, containers, and traffic all fall out of loops reading that record.
A Pod is a disposable copy; a ReplicaSet is the clerk keeping a fixed number alive; a Deployment is what you edit, and owns the ReplicaSet.
A Service is a stable address that finds Pods by flag, not name or address, so the Pods behind it keep changing unnoticed.
Labels are the only wiring in the system. Repaint a Pod’s flag and a ReplicaSet drops it and replaces it live, nothing crashing.
The scheduler never starts a container, the kubelet never chooses a machine - each writes one fact, and everyone talks through the API server, never each other.
Because a Service only matches flags, two unrelated Deployments behind it split traffic for free: a canary on a good day, a leak on a bad one.

Read the story · Skip to the numbers