ReplicaSets and Deployments

Rensin’s Kubernetes: Scheduling the Future at Cloud Scale (2015), ch. 3, "Organize, Grow, and Go", describes the only self-healing controller Kubernetes had at the time: the ReplicationController (kind: ReplicationController, core v1 API, field spec.replicas with a spec.template and a plain equality-based spec.selector). It already had the two ideas that survive unchanged today — a desired replica count reconciled continuously against reality, and loose coupling: the controller does not track "its" Pods by name or by having created them, it finds them by matching a label selector against whatever Pods currently exist in the namespace. Deleting a ReplicationController without deleting its Pods, and then later creating a fresh one with the same selector, was already the book’s worked example of that same loose coupling.

ReplicaSet (apps/v1beta2 when Kubernetes: Up and Running’s 2017 sampler was written, later graduating to apps/v1) is the ReplicationController’s direct successor: an identical replicas / selector / template shape, but with a selector that also accepts the set-based label expressions covered in Objects and the Kubernetes API (matchLabels and matchExpressions), where a ReplicationController’s selector could only be a flat equality map. The extensions/v1beta1 API group the 2017 sampler shows Deployments and DaemonSets served under (and that the ReplicaSet examples of that era assumed alongside them) was removed from the API server entirely in Kubernetes 1.16 — any manifest still written against extensions/v1beta1 or apps/v1beta1/apps/v1beta2 must be rewritten against apps/v1 before it will apply to a 1.37 cluster, exactly as the deprecation guide in Objects and the Kubernetes API describes. ReplicationController itself was never removed — it is still served under the core v1 group — but the official documentation has recommended a Deployment-managed ReplicaSet over a bare ReplicationController for years, and no Bookshelf manifest in this section uses kind: ReplicationController.

Neither a ReplicationController nor a bare ReplicaSet, on its own, knows how to change its Pod template safely: edit spec.template.spec.containers[0].image on a running ReplicaSet and every existing Pod is left untouched, because the selector still matches them and the controller only creates new Pods to reach the replica count, it never touches existing ones. That gap is what a Deployment (apps/v1, since Kubernetes 1.9) fills: a Deployment owns one or more ReplicaSets (see the owner-reference chain in Objects and the Kubernetes API) and, whenever its own Pod template changes, creates a new ReplicaSet with the new template and drives traffic from the old ReplicaSet to the new one according to a strategy, covered below. In practice almost no Bookshelf manifest creates a ReplicaSet directly; it is written as a Deployment, and the Deployment controller manages the ReplicaSet underneath it.

Source: Kubernetes Docs — ReplicaSet.

A Deployment adds one field on top of everything a ReplicaSet already has: spec.strategy, which controls how the old ReplicaSet is scaled down and the new one scaled up whenever spec.template changes.

A rolling update is what delivers zero-downtime releases: with maxUnavailable: 0 and a readiness probe, capacity never drops below the desired replica count during a rollout. Combined with self-healing replacement of failed Pods, this is the mechanism behind "five nines" (99.999%) availability targets, which allow only about five minutes of downtime a year; a Deployment alone is necessary but not sufficient, since probes, PodDisruptionBudgets and multiple nodes all contribute.

kubectl rollout is the command group for everything about a Deployment’s (or DaemonSet’s, or StatefulSet’s) history and in-flight state, alongside kubectl scale for the replica count and kubectl set image for the most common single-field template edit.

kubectl set image triggers a rollout the same way editing spec.template by hand would. kubectl scale does not: spec.replicas is not part of the Pod template, so scaling resizes the current ReplicaSet without creating a new revision. The --record flag that used to fill in CHANGE-CAUSE is deprecated, so the supported way to leave a message for kubectl rollout history is the kubernetes.io/change-cause annotation, set with kubectl annotate right after the change (as above) or written straight into the manifest. The Deployment controller copies the annotation onto the newest ReplicaSet, so annotating right after set image labels the revision that command created; a later annotation overwrites the message of whichever revision is current at that time. kubectl rollout restart is the tool for "the image tag did not change but the Pods must still be replaced" — picking up a ConfigMap/Secret edit that has no checksum annotation wired in (see ConfigMaps), or simply forcing a fresh set of Pods — without editing the Pod template at all: it patches a kubectl.kubernetes.io/restartedAt annotation on the template instead, which still goes through the same RollingUpdate/Recreate strategy as any other change. kubectl rollout pause and kubectl rollout resume are for batching several template edits (e.g. set image plus an env var change) into one rollout instead of triggering a rollout per edit: pause, make every edit, then resume to let one rollout apply them all together. Source: Kubernetes Docs — kubectl rollout and Kubernetes Docs — Deployment.