RollingUpdate keeps Kubernetes apps live during releases with readiness probes, surge tuning, ingress draining, and safe rollbacks. Read now.
How RollingUpdate Keeps Traffic on Healthy Pods
A RollingUpdate strategy replaces pods gradually instead of tearing down the whole set at once. Kubernetes creates new pods, waits until they pass readiness checks, then removes old ones. That sequence is what keeps the service addressable while a new release rolls out. Without readiness as a gate, the control plane can add a pod to service endpoints before it can actually serve traffic, which produces brief errors even when the rollout itself looks successful.
Readiness probes should test something that means “ready for real requests,” not only that the process is running. Hit a lightweight health path that checks critical dependencies the app needs to answer correctly. Keep the probe interval and failure thresholds tight enough to drop a bad pod from the endpoints quickly, but not so aggressive that a slow cold start flapping marks a healthy pod as not ready. Liveness is separate: use it for crash recovery, not as a substitute for readiness during deploys.
Surge, Unavailable Pods, and Capacity During the Cutover
Two knobs shape how much spare capacity you need and how fast the roll proceeds: max surge and max unavailable. Surge allows extra pods above the desired count so new versions come up before old ones leave. Max unavailable limits how many pods can be down at once. Higher surge speeds the rollout and reduces the risk of under-capacity, but needs headroom on the cluster. Higher unavailable frees resources sooner, but can shrink the serving set if traffic is spiky.
Pick values that match how much spare capacity you actually have and how long new pods take to become ready. If startup is slow or resource limits are tight, favor more surge and less concurrent unavailability so the live fleet never drops below what peak load needs. If the app is small and starts fast, a more aggressive unavailable setting can finish the roll with less temporary waste. Always leave room for the new pods to schedule; a surge setting that cannot place pods stalls the rollout mid-way.
Ingress Draining and Connection-Aware Cutover
Pod readiness alone does not finish the story if long-lived connections or cached endpoints still point at pods that are leaving. When a pod is marked not ready, it should leave the Service endpoints, and the ingress or load balancer should stop sending new requests to it. In-flight work still needs time to complete. Configure termination grace so the process can finish active requests, and have the app stop accepting new work as soon as it receives the shutdown signal.
- Stop accepting new connections on SIGTERM, then drain what is already open.
- Keep the grace period longer than your typical request or stream duration.
- Confirm the readiness probe fails promptly so the Service drops the pod before the process exits.
If you skip draining, users can hit closed connections or truncated responses even though the Deployment reported a successful update. Treat the window between “not ready” and “process exit” as part of the deploy design, not an afterthought.
Safe Rollbacks When the New Version Misbehaves
Zero downtime includes a clean way back. If the new revision fails readiness or returns errors under traffic, pause or reverse the rollout so old pods remain or return. Prefer rolling back to a known-good revision rather than patching live under pressure. Because the previous pods were only scaled down after the new ones became ready, a controlled rollback can restore capacity without a full rebuild—provided you still have images, config, and resource quota for the prior revision.
Practice the failure path: force a bad image or a probe that never passes, and confirm traffic stays on healthy pods while the bad revision is blocked or reversed. Zero-downtime deploys are not a single flag; they are readiness gating, surge and capacity choices, connection draining, and a rollback you have already proven works.