Deployments and ReplicaSets

## The three objects Kubernetes builds workloads out of layered controllers, each reconciling one level: - A **Pod** is the smallest deployable unit: one or more containers sharing a network namespace and volumes. Pods are disposable and never repaired in place. - A **ReplicaSet** guarantees that a given number of pods matching its selector exist. It is tied to a *single* pod template — it has no notion of versions or upgrades. - A **Deployment** sits above ReplicaSets and adds versioning: it creates a new ReplicaSet per template revision and orchestrates the transition between them. Ownership is explicit in the API. Each ReplicaSet carries an `ownerReferences` entry pointing at its Deployment, and each pod carries one pointing at its ReplicaSet. That chain drives cascading deletion: delete the Deployment and garbage collection removes its ReplicaSets, which removes their pods. It is also why `kubectl delete pod` never helps for long — the ReplicaSet observes the shortfall and recreates one immediately. You rarely create ReplicaSets directly. They exist as a separate object because the split of concerns is real: "keep N of exactly this" versus "move from this to that". ## What happens on a template change Walk it step by step, because interviewers listen for the hash: 1. You `kubectl apply` a Deployment whose `spec.template` differs — new image, new env var, new annotation, new resource request. Any field under `template` counts. 2. The Deployment controller computes a hash of the pod template and looks for an owned ReplicaSet labelled with that `pod-template-hash`. 3. If none exists, it creates a new ReplicaSet with `replicas: 0`, whose selector includes the new hash, and bumps the Deployment's revision. 4. It then alternately scales the new ReplicaSet up and the old one down within the bounds of the rollout strategy, waiting for pods to become *available* (ready, and ready for `minReadySeconds`) before continuing. 5. When the new ReplicaSet reaches the desired count and the old is at 0, the rollout is complete. The old ReplicaSet object is **kept**, at zero, as the rollback target. The `pod-template-hash` label is the mechanism that makes this safe. Without it, the old ReplicaSet's selector would also match the new pods, and it would count them toward its own replica goal, deleting pods that belong to the new generation. The controller adds the label to the ReplicaSet selector, to its pod template and thus to its pods, so each generation's pods belong unambiguously to one ReplicaSet. A useful corollary: if the new template hashes to a template you have deployed before, the controller *reuses* the existing ReplicaSet rather than creating another. That is what makes a rollback simply a scale-up of an old ReplicaSet. ## Things that do and do not create a revision - Changing image, command, env, resources, labels or annotations **inside `spec.template`** → new ReplicaSet, new revision, rollout. - Changing `spec.replicas` → no new ReplicaSet; the current one is rescaled. - Changing a referenced ConfigMap or Secret's *contents* → **nothing**. The template is unchanged, so no rollout happens and pods keep the old values until they restart for other reasons. The standard fix is to put a checksum of the config in a pod-template annotation, which turns a config change into a template change. - Changing `spec.selector` → rejected. The selector is immutable after creation; you must delete and recreate the Deployment. ## Reading it with kubectl `kubectl get rs` shows every generation with DESIRED/CURRENT/READY: normally one row with your replica count and several rows at 0. A cluster showing two ReplicaSets both non-zero is mid-rollout or stuck. `kubectl describe deployment` prints `OldReplicaSets` and `NewReplicaSet` explicitly, and the events list narrates each scale step ("Scaled up replica set web-7d9f to 2"). How many zeroed ReplicaSets remain is governed by `revisionHistoryLimit` (default 10). Setting it to 0 keeps the object list clean but destroys your ability to roll back, which is a bad trade for a production service. ## Interview framing Lead with the chain and the ownerReferences, then narrate the template-hash mechanism, then name one non-obvious consequence — a ConfigMap edit does not trigger a rollout, or deleting a pod does not remove it because the ReplicaSet restores it. That last part distinguishes someone who has operated Deployments from someone who has read the docs page.