beginner~4h

Workloads I: Deployment & ReplicaSet

A Deployment is the standard way to run stateless applications. A Deployment manages ReplicaSets; a ReplicaSet manages Pods. This two-layer design enables rolling updates: when the Pod template changes, Kubernetes creates a new ReplicaSet and gradually shifts replica count from old to new. Old ReplicaSets are retained at zero replicas for rollback.

A ReplicaSet's only job is maintaining an exact Pod count matching its label selector.
A Deployment creates a new ReplicaSet when the Pod template changes and orchestrates the transition using maxUnavailable and maxSurge.
Rolling update: scale up new ReplicaSet, scale down old one, repeat. Only Pods passing readiness probes count as available.
Deployment rollout history retained via revisionHistoryLimit -- what kubectl rollout undo operates against.
progressDeadlineSeconds turns a silently stalled rollout into a detectable condition.

Apply a manifest via kubectl.
API Server validates and persists to etcd.
Controller detects change and reconciles.
kubelet implements changes on the node.
Status reported back to API Server.

A checkout API behind a Deployment with 6 replicas, deployed via kubectl rollout during business hours with zero customer-visible downtime, because the readiness probe holds new Pods out of the Service's endpoint list until they can actually serve traffic.
A team rolling back a bad release in seconds with kubectl rollout undo deployment/checkout-api, because the Deployment kept its prior ReplicaSet around (governed by revisionHistoryLimit) instead of deleting it on update.
A Black Friday traffic spike handled by scaling a Deployment's replica count up temporarily (manually or via HPA, Chapter 10), relying on the ReplicaSet controller to reconcile the new desired count without any manual Pod management.

Always define a readiness probe -- rolling update safety depends on knowing when a Pod is ready.
Tune maxUnavailable and maxSurge deliberately based on capacity and risk tolerance.
Set progressDeadlineSeconds and integrate kubectl rollout status exit code into CI/CD.
Keep revisionHistoryLimit reasonable (5-10) -- enough for rollback without unbounded objects.

Editing a ReplicaSet directly -- changes are overwritten by the Deployment controller.
Not setting a readiness probe so traffic reaches not-yet-ready Pods during rollout.
Setting both maxUnavailable: 0 and maxSurge: 0 -- makes rolling update structurally impossible.

Right-size requests before tuning replica count -- HPA (Scaling chapter) scales based on utilization relative to requests, so an inaccurate request undermines both the Deployment's scheduling efficiency and any autoscaler built on top of it.
Tune maxSurge higher for faster rollouts when spare cluster capacity allows it -- each extra surge Pod is temporary capacity purely for rollout speed, not steady-state load.
Keep revisionHistoryLimit reasonable -- every retained old ReplicaSet, even at zero replicas, is still an etcd object the API server tracks; unbounded history adds control-plane overhead with no runtime benefit.
For Deployments with many replicas, a large maxUnavailable speeds up rollouts but temporarily reduces serving capacity -- balance against real traffic headroom, not just deployment-speed convenience.

Gate kubectl rollout status's exit code in CI/CD so a stalled or failed rollout (caught via progressDeadlineSeconds) blocks the pipeline instead of silently leaving a broken partial rollout in production.
Practice kubectl rollout undo as a real, tested rollback path before you need it in an incident -- confirm it works against your actual revisionHistoryLimit and rollout history.
Set PodDisruptionBudgets on production Deployments so voluntary disruptions (node drains, cluster upgrades) don't take out more replicas simultaneously than the service can tolerate.
Monitor rollout-specific signals (ReplicaSet age/health, progressDeadlineSeconds condition) separately from steady-state application metrics -- a rollout stuck half-complete looks different from a healthy-but-degraded steady state.

Create a Deployment with 3 replicas and a readiness probe with a deliberately long initialDelaySeconds; watch with kubectl get pods -w and confirm new Pods don't receive traffic until the probe passes.
Update the Deployment's image to a new tag and run kubectl rollout status deployment/<name> while it happens; then run kubectl get replicasets and confirm the old ReplicaSet is still present, scaled to 0.
Deliberately push an image that crashes on startup and observe kubectl rollout status block with progressDeadlineSeconds exceeded, then run kubectl rollout undo to recover.
Try kubectl edit replicaset <name> directly on a Deployment-owned ReplicaSet and observe the Deployment controller revert your change on its next reconcile pass.

Deployments manage ReplicaSets; ReplicaSets manage Pods -- two layers enable rolling updates and rollback.
Rolling updates governed by maxUnavailable (below desired) and maxSurge (above desired).
Readiness probes are safety-critical -- the rolling update mechanism depends on accurately knowing when a new Pod is ready.
Old ReplicaSets retained at zero replicas (revisionHistoryLimit) for instant rollback.
progressDeadlineSeconds turns a silently stalled rollout into a detectable condition.

Want a visual for this concept?

Generate a diagram tailored to “Workloads I: Deployment & ReplicaSet” — the AI picks whichever visual (flowchart, comparison, sequence, etc.) best fits.

Practice quiz

Next Step

Continue to Workloads II: StatefulSet & DaemonSet →← Back to all Kubernetes chapters