Deployments & ReplicaSets

Chapters 3 and 4 both pointed here: the controller you'll actually use almost all the time, rather than bare Pods. This chapter covers the Deployment, and the ReplicaSet mechanism underneath it.

The Problem With Bare Pods, Revisited

A bare Pod, once created, isn't automatically replaced if it fails or its node dies — unless something is actively watching it. You could theoretically write your own reconciliation logic by hand; Kubernetes already provides it, via Deployments.

ReplicaSets — Ensuring N Copies Are Always Running

The layer directly underneath Deployments. A ReplicaSet's job is simple and singular: ensure a specified number of pod replicas matching a given template are running at all times — a concrete instance of Chapter 2's reconciliation loop (observe how many matching pods exist, compare to the desired count, create or delete pods to reconcile). ReplicaSets use label selectors (Chapter 4's labels material) to know which pods belong to them — a genuinely important mechanism that explains a lot of later behavior.

Deployments — Managing ReplicaSets for You

A Deployment sits one layer above a ReplicaSet: you rarely create a ReplicaSet directly — you create a Deployment, and Kubernetes creates and manages the ReplicaSet(s) underneath it automatically. A Deployment's real value is managing the transition between different versions of a ReplicaSet — exactly what makes rolling updates and rollback possible.

Rolling Updates — Changing Versions Without Downtime

When a Deployment's pod template changes (a new container image version, for instance), Kubernetes creates a new ReplicaSet with the updated template, and gradually scales it up while scaling the old ReplicaSet down — a few pods at a time, never all at once. This is why routine deployment updates generally don't cause downtime: healthy pods are always serving traffic throughout the transition.

Two practical, configurable knobs: maxSurge (how many extra pods beyond the desired count can be created during rollout) and maxUnavailable (how many can be unavailable at once).

Rollback — Undoing a Bad Deployment

Kubernetes keeps a history of previous ReplicaSets/revisions for a Deployment. If a new rollout turns out to be broken, kubectl rollout undo reverts to the previous working ReplicaSet — genuinely fast compared to manually reconstructing the old configuration by hand. kubectl rollout status and kubectl rollout history are the practical commands for checking on this.

Self-Healing in Action

Tying together Chapter 3's "pods are disposable" material concretely: if a pod managed by a ReplicaSet dies or is deleted, the ReplicaSet's own reconciliation loop notices the actual count has dropped below the desired count, and creates a replacement automatically — the concrete mechanism behind the self-healing Chapter 1 promised. This happens without writing any recovery logic at all, simply by declaring the desired replica count.

A Complete Deployment YAML, Explained

Scaling — Changing Replica Count

Imperatively: kubectl scale deployment <name> --replicas=N. Declaratively (preferred, per Chapter 4's own guidance): edit the YAML's replicas field and re-apply. This chapter covers manual scaling; Course 2's k8s2-6 covers automatic scaling based on live metrics.

Hands-On Exercises