CoursesKubernetes administrationArchitecture & Core Objects

Deployments

Versioned rollouts and rollback over ReplicaSets.

Intermediate12 min · lesson 9 of 65
In plain terms
A Deployment is the store manager who rolls out the new uniform one cashier at a time — no one is ever left undressed — and if the new uniform turns out bad, instantly puts everyone back in the old one.
A rollout across two ReplicaSets
1New desiredstatekubectl set image…2New ReplicaSetcreatedat the new version3Pods shiftgraduallymaxSurge / maxUnavailable4Old ReplicaSetretainedscaled down, not deleted5rollout undoscales the old RS back up
Old ReplicaSets are kept, so rollback is just scaling a prior revision back up.

A Deployment is the object you actually use for stateless apps. It manages ReplicaSets to give you versioned, zero-downtime rollouts and instant rollback — which is the entire reason for the indirection through ReplicaSets.

terminal
$ kubectl create deploy web --image=nginx:1.25 --replicas=3
$ kubectl set image deploy/web nginx=nginx:1.26 # rolling update
$ kubectl rollout status deploy/web
deployment "web" successfully rolled out
$ kubectl rollout undo deploy/web # back to 1.25, instantly

A rollout creates a new ReplicaSet and shifts pods across gradually; old ReplicaSets are retained, so undo just scales a previous revision back up. The RollingUpdate strategy’s maxSurge and maxUnavailable control how aggressive that shift is — the knobs we tune in Application Lifecycle.

Rollback needs history
revisionHistoryLimit sets how many old ReplicaSets are kept (default 10). Set it to 0 and you keep a tidy cluster but lose the ability to roll back.