Rolling updates, blue-green, canary, feature flags — there are many ways to deploy with zero downtime. Here's when each strategy applies and the Kubernetes configuration that makes them work.
Vikram Patel
DevOps & Cloud Architect
Most Kubernetes deployments that cause downtime aren't caused by the deployment strategy — they're caused by misconfigured readiness probes, missing graceful shutdown handling, or database migrations that break the currently-running version of the app. The deployment strategy is the last 20% of zero-downtime; the first 80% is configuration and application-level work. This is the kind of audit our DevOps services team runs before touching a client's deployment pipeline.
Kubernetes rolling updates replace pods gradually, maintaining a minimum number of healthy pods throughout. This is the right default for most deployments. Configure maxUnavailable: 0 and maxSurge: 1 for the safest rolling update: at least one old pod stays healthy until new pods are confirmed healthy, and only one additional pod is added at a time.
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 0
maxSurge: 1A readiness probe tells Kubernetes when a pod is ready to receive traffic. Without it, Kubernetes routes traffic to new pods immediately after they start — before your application has finished initializing, connected to the database, or warmed up its caches. This causes brief errors that look like deployment failures but are actually missing readiness configuration.
Configure your readiness probe to check something that confirms the application is fully ready — not just that the process has started. An HTTP endpoint that verifies database connectivity and cache warmup is the right target.
Blue-green maintains two identical production environments. The "blue" environment serves live traffic. You deploy to "green", test it, then switch the load balancer to point at green. Rollback is instant — switch back to blue. The cost: double the infrastructure during deployments.
Implement blue-green in Kubernetes using two Deployments (blue and green) and a single Service that points to either via label selectors. Switch traffic by updating the Service's selector from version: blue to version: green. This is a single Kubernetes API call with no restart required.
Canary releases route a percentage of traffic to the new version while the rest continues on the old version. If metrics look good, the canary percentage increases. If metrics degrade, you roll back. This is the most conservative and safest deployment strategy — you validate new code against real production traffic before committing.
Argo Rollouts adds canary deployment support to Kubernetes with Prometheus metric analysis gates: the rollout automatically pauses or rolls back based on error rate and latency thresholds. No manual monitoring required — the deployment succeeds or rolls back based on your SLOs.
Database migrations are the most common cause of deployment downtime even with zero-downtime deployment strategies. The problem: you deploy version 2 of your application with a schema migration, but version 1 pods are still running and can't handle the new schema. The solution: always make schema changes backwards compatible. Add new columns with defaults (never NOT NULL without a default). Rename by adding a new column, backfilling, then dropping the old column in a separate release. Never remove a column that version N-1 of your application reads.
When Kubernetes terminates a pod, it first removes it from the Service endpoints (stopping new traffic), then sends SIGTERM to the container. Your application needs to catch SIGTERM and finish processing in-flight requests before exiting. Configure terminationGracePeriodSeconds to give your application enough time. Without graceful shutdown, in-flight requests get dropped during every rolling update. Teams running production clusters on AWS often pair this work with our AWS consulting services to validate the full deployment pipeline end to end.
Even with readiness probes and graceful shutdown correctly configured, deployments occasionally fail in ways that only show up under real production load. Set up automated rollback triggers, not just manual ones: if error rate exceeds a defined threshold (we typically use 2x the pre-deployment baseline) within the first 5 minutes of a rollout, Argo Rollouts or a custom Kubernetes operator should trigger an automatic rollback without waiting for a human to notice the dashboard. Manual rollback response time in our experience averages 8-12 minutes from first alert to action — automated rollback cuts that to under 60 seconds.
Keep at least the previous two container image versions available in your registry and never let a Kubernetes Deployment's revision history (controlled by the revisionHistoryLimit field) drop below 3. We've seen teams unable to roll back cleanly because their CI pipeline pruned old images too aggressively.
Deployment strategy alone doesn't guarantee zero downtime if your load balancer or DNS layer isn't cooperating. AWS ALB target group deregistration delay (the connection draining period) needs to exceed your application's terminationGracePeriodSeconds, or the load balancer will stop routing before in-flight requests finish. We set deregistration delay to terminationGracePeriodSeconds plus a 10-second buffer as a standard practice.
For multi-region deployments, DNS-based failover (Route 53 weighted routing) introduces its own delay from client-side DNS caching — TTLs of 300 seconds or higher mean some clients keep hitting the old region for up to 5 minutes after a cutover. For deployments requiring tighter cutover windows, a global load balancer like AWS Global Accelerator or Cloudflare bypasses DNS caching entirely.
Watch the right metrics during a rollout, not just aggregate error rate. Per-version error rate and latency, tagged by pod revision, surfaces regressions the aggregate number hides, since a bad new version at 10% traffic barely moves the overall average. We dashboard error rate, p99 latency, and request volume split by deployment revision for every rollout, and treat any per-revision anomaly as a rollback signal regardless of what the aggregate metric shows.
Tags
Continue Reading
Both tools provision cloud infrastructure from code. Both support every major cloud provider. The difference is the programming model: declarative HCL vs general-purpose languages. Here's when each approach wins.
AWS bills grow organically with your business. Without active cost management, you'll overspend by 30–50%. Here are the specific techniques we used to reduce a $180K/month AWS bill to $108K without sacrificing performance.
A practical guide to building AI agents that actually work outside of demos — covering tool selection, memory, error recovery, and deployment patterns we've validated in production.
From AI agents to mobile apps — iMOBDEV builds what your business needs.
