Kubernetes Deployments Explained: Rolling Updates, Rollbacks, and Zero-Downtime Releases

Kubernetes Deployments Explained: Rolling Updates, Rollbacks, and Zero-Downtime Releases

A Kubernetes Deployment manages a set of Pods through ReplicaSets and continuously reconciles them toward the desired application state.

For stateless web applications and APIs, this is usually the workload controller you want.

Rolling Updates

Changing the Pod template—such as the container image—creates a new Deployment revision and ReplicaSet. Kubernetes gradually scales the new ReplicaSet up while scaling the old one down.

Two settings control rollout capacity:

• maxUnavailable — maximum desired replicas that may be unavailable.
• maxSurge — extra Pods allowed above desired replicas during rollout.

Kubernetes currently defaults both to 25%.

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 0
    maxSurge: 1

For a critical API, maxUnavailable: 0 can help preserve capacity, but you need enough cluster headroom for surge Pods.

Readiness Makes Zero-Downtime Possible

A new Pod should not receive traffic merely because its process started.

Use a meaningful readiness probe so the Service only routes traffic after the application can actually serve requests.

Also make shutdown graceful: stop accepting new traffic and allow in-flight requests to finish before termination.

Detect Stalled Rollouts

progressDeadlineSeconds tells Kubernetes when a rollout has failed to make progress. The current default is 600 seconds.

Typical causes include:

• invalid image
• failing readiness/startup probes
• missing ConfigMap/Secret
• insufficient resources
• image pull errors

A stalled rollout should alert the deployment system rather than remain unnoticed indefinitely.

Rollbacks

Kubernetes keeps Deployment revisions through old ReplicaSets according to revisionHistoryLimit (default 10).

kubectl rollout status deployment/api
kubectl rollout history deployment/api
kubectl rollout undo deployment/api

Rollback restores the earlier Pod template. It does not automatically undo database migrations or external side effects, so application releases still need backward-compatible data changes.

Common Mistakes

• deploying only one replica and expecting zero downtime
• readiness probe that always returns 200
• no spare node capacity for maxSurge
• destructive DB migration before rollout completes
• using mutable image tags like latest
• assuming kubectl apply success means the application is healthy

Production Checklist

• Multiple replicas exist for critical workloads
• Readiness reflects real traffic readiness
• maxSurge / maxUnavailable match capacity and SLOs
• Rollout progress is monitored
• Images use immutable versions/digests
• Database changes tolerate old and new versions together
• Rollback is tested
• Post-deploy synthetic/SLO checks run

Final Takeaway

Kubernetes Deployments provide the mechanism for safe rolling application updates, but health gates and compatibility make the rollout safe. Tune surge/unavailable capacity, use meaningful readiness, monitor progress, and keep rollback possible beyond just the container image.

References

• Kubernetes Deployments
• Update a Deployment Without Downtime