Step 01 of 06
Learn the concept
A single container can look healthy right up until the laptop sleeps. A Deployment is the first Kubernetes object that says, in writing, that Beacon should keep existing after one process disappears.
The ideas this is made of
A Pod is the schedulable unit
Kubernetes does not schedule individual containers. It schedules Pods: one or more containers sharing a network namespace, volumes and lifecycle. Beacon usually needs one container per Pod. That still matters because the Pod receives the IP address, probes, volume mounts and restart policy. If the Pod dies, a controller must create another Pod; the same Pod is not healed in place.
You almost never create Pods directly
A naked Pod is useful for a quick diagnostic, not for a service. If its node dies, Kubernetes has no higher-level desired state telling it to create a replacement. A Deployment owns a ReplicaSet, and the ReplicaSet owns Pods. That chain is what turns replicas: 2 into two current Pods, even after failure.
Deployment rollouts are versioned changes
When a Deployment's Pod template changes, Kubernetes creates a new ReplicaSet and scales it while scaling the old one down. kubectl rollout status follows that process. kubectl rollout undo moves the Deployment back to a previous template. The rollback is not magic; it is another desired-state change to an earlier ReplicaSet.
Strategy numbers encode risk appetite
maxUnavailable: 0 says never reduce ready capacity during an update. maxSurge: 1 allows one extra Pod temporarily, which costs a little more CPU and memory. For two replicas, that means Kubernetes may run three Pods during the rollout. A cluster without spare capacity turns that careful strategy into Pending.
desired: 5 copies of the new edition
observed: 5 old copies
policy: never have fewer than 5 total
action: place 1 new, remove 1 old, repeatThe librarian tracks editions and shelf count. A Deployment tracks Pod templates and ready replicas. Nobody fondly names the individual copies.
Pod, ReplicaSet and Deployment
| Object | Job | Do you edit it? |
|---|---|---|
Pod | Runs the container now | No, it is disposable |
ReplicaSet | Keeps N matching Pods | Rarely; Deployment owns it |
Deployment | Manages rollouts and history | Yes |
Strategy | Controls update shape | Yes, with intent |
Rollout history | Records templates | Read during rollback |
What these are called on the job
Pod — The smallest unit Kubernetes schedules; one IP, one lifecycle, one or more containers.
ReplicaSet — A controller-owned object that keeps a requested number of matching Pods alive.
Deployment — A higher-level controller for ReplicaSets, rollouts and rollback history.
Rollout — The transition from one Pod template revision to another.