Deployment & ReplicaSet
A Deployment manages a ReplicaSet which ensures a specified number of identical pod replicas are running. Deployments enable rolling updates and rollbacks.
Deployment = a rolling restaurant shift change. New waiters (pods) arrive one by one, old waiters leave as new ones prove they can carry plates (readiness). maxSurge = how many extra waiters on the floor at once. Rollback = calling the old crew back in.
Deployment → manages → ReplicaSet → manages → Pods. Rolling update strategy (default): creates a new ReplicaSet, scales it up while scaling down the old one. maxSurge (extra pods during update) and maxUnavailable (pods that can be down) control the rollout speed. kubectl rollout status deployment/name, rollout undo for rollback. Recreate strategy: kills all pods then starts new ones (downtime, use when old and new versions can't run simultaneously).
Deployments keep a history of ReplicaSets (revisionHistoryLimit, default 10). kubectl rollout undo rolls back to the previous ReplicaSet — the old RS is scaled up and new RS is scaled down. kubectl rollout undo --to-revision=N for specific version. Each rollout creates a new ReplicaSet (even if the template didn't change). Deployment pauses: kubectl rollout pause lets you apply multiple changes before triggering a rollout — prevents thrashing. minReadySeconds: pod must be Ready for this duration before being considered available — prevents premature traffic. The Deployment controller ensures the desired replica count even during node failures.
A Deployment is what you use for stateless apps. It manages ReplicaSets which manage pods. Rolling updates create a new ReplicaSet and gradually shift traffic from old to new — zero downtime. maxSurge and maxUnavailable control the speed. For rollback: kubectl rollout undo deployment/name. The history of ReplicaSets is kept so you can roll back to any previous version. Key: set readiness probes — rolling updates only proceed when new pods pass their readiness check. A bad deployment with no readiness probe will happily roll out broken pods.
A Deployment rollback undoes the pod template change — it does NOT rollback your application's database migrations or any external state changes. Rollbacks are partial — only the container image and pod spec revert.