Kubernetes Deployment Strategies

Six deployment strategies for zero-downtime releases: Canary (gradual %), Blue-Green (instant switch), A/B Testing (user segment), Rolling Update (pod-by-pod), Recreate (delete all then create), Shadow (mirror traffic). Each has distinct downtime and rollback characteristics.

Overview

Choosing a deployment strategy

The deployment strategy decides how much risk you accept per release and how quickly you can recover from a bad one. Six strategies cover almost every case.

Rolling update, the Kubernetes default

Kubernetes replaces Pods one by one: new Pods start, pass readiness probes, then old Pods terminate. There is no downtime, but V1 and V2 run side by side during the rollout.

maxSurge — How many extra Pods can exist during the rollout
maxUnavailable — How many old Pods can be removed before new ones are ready

> [!WARNING] Because V1 and V2 overlap, backward-incompatible API or DB changes break a rolling update.

Recreate

Terminate ALL old Pods first, then create new ones, which leaves a window of downtime.

Development
Stateful workloads that cannot run two versions simultaneously
A new version that requires a clean DB migration

Canary

Deploy V2 alongside V1 and route only a small share of traffic (5 to 20 percent) to V2. Monitor error rates, latency and business metrics, then shift gradually to 100 percent.

> [!IMPORTANT] Canary needs an Ingress controller or service mesh that supports traffic weighting: nginx-ingress, Istio, Flagger.

Blue-green

Run V2 (green) on a separate set of Pods while V1 (blue) handles all traffic. When green is ready, switch the load balancer or Ingress in a single step; rollback is switching back.

All six at a glance

Rolling update — Pod by Pod after readiness — Roll back Pod by Pod — Versions overlap
Recreate — All old down, then all new up — Redeploy — Downtime window
Canary — Small percentage, then gradual — Weight V2 to 0% — Traffic-weighting Ingress or mesh
Blue-green — Single switch — Switch back instantly — Double infrastructure while both run
A/B testing — By user attribute, for example V1 for mobile, V2 for desktop — Change the routing rule — Smart Ingress or mesh with header-based routing
Shadow — Copy of every request to V2; users get V1's response — Nothing to roll back — Service mesh or proxy support (Istio, Envoy)

> [!TIP] Shadow validates V2 behavior and performance under real load with no user impact.

Key concepts

maxSurge: Rolling Update parameter. Maximum number of extra pods above the desired count that can exist during rollout. Default: 25%. Higher = faster rollout but more resource usage.
maxUnavailable: Rolling Update parameter. Maximum number of pods that can be unavailable during rollout. Default: 25%. Lower = safer (more capacity maintained) but slower rollout.
Canary weight: The percentage of traffic routed to the new version. Implemented via Ingress annotations (nginx.ingress.kubernetes.io/canary-weight) or Istio VirtualService weight fields. Flagger automates canary progression and rollback.
Blue-Green switch: The act of changing the Ingress or Service selector to point from blue (old) to green (new) pods. In Kubernetes: update the Service spec.selector to match green pod labels, or update Ingress backend Service name.
Traffic mirroring (Shadow): Envoy/Istio feature that duplicates every inbound request and forwards a copy to a second cluster or Service. The mirrored traffic is "fire-and-forget" — responses from the shadow are discarded. Real users only see responses from the primary.
Flagger: Kubernetes operator that automates canary deployments. Integrates with Istio, nginx-ingress, AWS ALB. Automatically shifts traffic, queries Prometheus metrics, and rolls back if error rate or latency thresholds are breached.

When to use it

Canary: risk-averse teams rolling out to a fraction of users before full release
Blue-Green: mission-critical services where instant rollback is required and infra cost is acceptable
Rolling Update: standard releases of stateless services with backward-compatible changes
Recreate: stateful apps that cannot tolerate two versions running simultaneously
A/B Testing: product experiments where different user segments should see different behavior
Shadow: load testing a new version without any user risk before any canary traffic is shifted

Interview questions

Compare rolling update vs blue-green vs canary deployment.
How do you implement a canary deployment in Kubernetes without a service mesh?