Kubernetes Rolling Updates and Rollbacks

When you deploy a new version of your application, you do not want to take the old version down all at once — that would cause downtime. Rolling updates solve this by gradually replacing old Pods with new ones. If something goes wrong, rollbacks let you revert to the previous version with a single command.

Think of it like replacing light bulbs in a long hallway one at a time. The hallway is never dark because most bulbs are always on. If the new bulbs are the wrong color, you can swap the old ones back in.

Rolling updates are the default strategy for Kubernetes Deployments. You control the speed and safety of the rollout with two parameters: maxSurge and maxUnavailable.

Core Concepts

Step 1 — Deployment Strategy Types

Kubernetes Deployments support two strategy types:

Use Recreate only when your app cannot tolerate running two versions simultaneously (e.g., database schema conflicts). In all other cases, use RollingUpdate.

Step 2 — maxSurge and maxUnavailable

These two parameters control the pace of a rolling update:

1. maxSurge — the maximum number of Pods that can be created above the desired replica count during the update. Can be an absolute number or a percentage.
2. maxUnavailable — the maximum number of Pods that can be unavailable during the update. Can be an absolute number or a percentage.

With these settings, Kubernetes creates 1 new Pod first, waits until it is ready, then terminates 1 old Pod. This ensures zero downtime — there is always at least the desired number of Pods running.

Step 3 — How a Rolling Update Works

When you update the container image (or any field in the Pod template), Kubernetes:

1. Creates a new ReplicaSet with the updated Pod template.
2. Scales the new ReplicaSet up gradually (respecting maxSurge).
3. Scales the old ReplicaSet down gradually (respecting maxUnavailable).
4. When all new Pods are ready and all old Pods are terminated, the update is complete.

Step 4 — Rollback with Revision History

Kubernetes keeps a history of Deployment revisions. If a new version is buggy, you can roll back instantly:

This reverts to the previous revision. To go back to a specific revision:

The number of revisions kept is controlled by spec.revisionHistoryLimit (default: 10).

Step 5 — The Recreate Strategy

When set to Recreate, Kubernetes terminates all existing Pods before creating new ones. This causes downtime but guarantees that only one version runs at a time.

Hands-On: Kubernetes Commands

Trigger a Rolling Update

Example:

Watch the Rollout Progress

This command blocks until the rollout is complete or fails.

View Rollout History

Shows all revisions with their change causes.

View Details of a Specific Revision

Roll Back to the Previous Version

Roll Back to a Specific Revision

Pause and Resume a Rollout

Pausing lets you make multiple changes to the Deployment without triggering multiple rollouts.

Step-by-Step Example

Scenario — Zero-Downtime Update of a Logistics API

You will deploy version 1.0 of a logistics-api, then perform a rolling update to version 2.0, and finally roll back to version 1.0 if needed.

Step 1 — Deploy Version 1.0

Save the following as logistics-api-deployment.yaml:

Step 2 — Verify All Pods Are Running

You should see 3 Pods in Running state with READY 1/1.

Step 3 — Trigger a Rolling Update to Version 2.0

Step 4 — Watch the Rollout

You will see messages like "Waiting for deployment ... rollout to finish: 1 out of 3 new replicas have been updated..." and eventually "deployment ... successfully rolled out".

Step 5 — Check Rollout History

Shows revision 1 (v1.0) and revision 2 (v2.0).

Step 6 — Roll Back to Version 1.0

The Deployment reverts to the v1.0 Pod template. Verify:

Summary

1. RollingUpdate (default) replaces Pods gradually — no downtime.
2. Recreate terminates all old Pods first — causes downtime but guarantees single-version.
3. maxSurge controls how many extra Pods can exist during update.
4. maxUnavailable controls how many Pods can be down during update.
5. Use kubectl rollout undo to instantly roll back to a previous revision.
6. Use kubectl rollout pause/resume to batch multiple changes into one rollout.
7. Set revisionHistoryLimit to control how many old ReplicaSets are kept.