Rolling Updates

Understand rolling updates for Kubernetes Deployments, maxSurge, maxUnavailable, readiness, availability, and safe release strategy.

Last reviewed: June 2026

·Kubernetes 1.28+kubectl 1.28+Helm 3+Managed Kubernetes: EKS, AKS, GKE
✅
Quick Understanding: A rolling update gradually replaces old Pods with new Pods while keeping the service available.

🔍 What Is It?

A rolling update is the default Deployment strategy for changing Pod templates without replacing all replicas at once.

🎯 Why Do We Need It?

Production services need controlled releases that avoid downtime and allow health validation while versions change.

Common developer mistakes:

  • →Treating Kubernetes YAML as copy-paste configuration instead of production architecture
  • →Ignoring requests, limits, health probes, security context, and rollout behavior
  • →Debugging only the Pod while forgetting Services, DNS, NetworkPolicies, nodes, and admission controls
  • →Manually changing live objects without updating Git or infrastructure automation

🏗️ What Happens in Real Projects?

A retail API rolls from version 1.24.0 to 1.25.0 with maxUnavailable 1 and maxSurge 1. Readiness probes hold traffic until each new Pod is ready. Monitoring watches error rate during rollout.

⚙️ How It Works

The Deployment creates a new ReplicaSet and scales it up while scaling the old ReplicaSet down according to strategy. Readiness controls when new Pods enter Service endpoints.

💻 Example

Rolling update controls — Deployment rollout settings.

yaml
strategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 1
    maxSurge: 1
minReadySeconds: 10
progressDeadlineSeconds: 600

🤔 Common Confusions

❓ Does rolling update guarantee zero downtime?

Only if capacity, readiness, compatibility, and dependencies are designed correctly.

❓ Can old and new versions run together?

Yes. Applications must be compatible during the rollout window.

❓ Does rolling update handle database migration?

No. Database changes need compatible migration strategy.

🚨 Common Production Issues

**Readiness lies** causes broken Pods to receive traffic.

**Mixed-version incompatibility** breaks users during rollout.

**Too aggressive maxUnavailable** reduces capacity too much.

**No monitoring gate** lets bad releases finish.

✅ Best Practices

Use truthful readiness probes

Design backward-compatible API and schema changes

Tune maxSurge and maxUnavailable

Monitor rollouts and stop on bad signals

Use canary or blue-green for high-risk changes

🏛️ Architect's Note

Senior Architect's Perspective

Rolling updates are safe only when the application is designed for mixed versions. Kubernetes controls mechanics; architecture controls compatibility.

💬 Frequently Asked Questions

Interview: How would you explain Rolling Updates in a real Kubernetes project?

Rolling Updates should be explained through the workload it supports, the Kubernetes object relationships, the failure modes, the security controls, and how it is observed and rolled back in production.

Interview: What production mistake do developers commonly make with Rolling Updates?

The common mistake is making the object work once, then skipping ownership, resource sizing, rollout safety, monitoring, least privilege, and recovery behavior.

🎯 Key Takeaways

1Rolling updates replace Pods gradually
2Readiness is central
3Mixed-version compatibility matters
4Database migrations need separate care

🎯 Practice this topic in interviews

↗ Where this topic fits

Sources

Sources / References

Use these Kubernetes references to verify the concept in official docs and continue into the most relevant SplashRide pages.