Kubernetes Workloads
Deployments — Rolling Updates and Rollbacks
Updating applications, rollouts, strategies, and history checks.
Interview: Deployments are one of the most heavily tested workloads. Understand the difference between the RollingUpdate and Recreate strategies, how maxSurge and maxUnavailable control container rollouts, and how to roll back changes using undo commands.
Introduction to Deployments
A **Deployment** is a higher-level abstraction that sits on top of ReplicaSets. It provides declarative updates for Pods and ReplicaSets. You describe a desired state in a Deployment manifest, and the Deployment controller manages the transition from the current state to the desired state.
Deployment Strategies
When updating container versions (e.g. changing the image tag), Deployments use two main strategies:
- Recreate: Terminates all running Pods first, before spinning up the new version. This results in service downtime, but guarantees that two different versions of the code never run simultaneously.
- RollingUpdate (Default): Gradually replaces old Pods with new ones, ensuring zero downtime. You configure rolling updates using two parameters:
maxSurge: The maximum number of Pods that can be created above the desired replica count during the update (e.g. 25%).maxUnavailable: The maximum number of Pods that can be unavailable during the update process (e.g. 25%).
Under the Hood: Double ReplicaSet Swapping
When you update a Deployment's container configuration, the Deployment controller automatically creates a **new** ReplicaSet representing the new version. It then scales up the new ReplicaSet (adding new pods) while scaling down the **old** ReplicaSet (removing old pods).
Rollback and History Management CLI
If an update introduces a bug or causes container crashes, you can inspect rollout history and roll back changes instantly: