Summary
A Rolling Upgrade replaces running instances of an application one at a time (or in small batches), ensuring the service remains available throughout the deployment without requiring duplicate environments.
What is a Rolling Upgrade?
In a rolling upgrade, the deployment system takes a subset of instances out of the load balancer rotation, upgrades them to the new version, verifies their health, and then proceeds to the next batch. This continues until all instances run the new version. At no point is the entire service offline.
Kubernetes natively supports rolling upgrades through its Deployment resource. Parameters like maxUnavailable and maxSurge control how many pods can be unavailable or over-provisioned during the rollout. Rollback is straightforward: Kubernetes can revert to the previous ReplicaSet if the new pods fail their readiness probes.
The main challenge of rolling upgrades is backward compatibility: during the transition period, both old and new versions run simultaneously and must handle the same requests, database schemas, and API contracts. This requires careful versioning and feature flag management.
Why is Rolling Upgrade relevant?
- No environment duplication: Unlike Blue/Green, rolling upgrades do not require a second full production environment
- Gradual risk exposure: Problems with the new version surface incrementally rather than all at once
- Native Kubernetes support: Kubernetes Deployments implement rolling upgrades as the default release strategy