7 Kubernetes Deployment Strategies: Red-Black, Blue-Green, Canary & More

Key Takeaways

• Red-black (also called red/green or red-green deployment) runs two complete, isolated environments and switches traffic atomically — zero overlap, instant rollback.
• Blue-green is functionally the same pattern under a different naming convention; the two terms are used interchangeably across the industry.
• Rolling updates are Kubernetes' default Deployment behavior — gradual pod replacement with no extra infrastructure.
• Canary releases expose a new version to a small traffic percentage before full rollout, catching regressions with limited blast radius.
• Strategy choice depends on rollback speed requirements, infrastructure cost tolerance, and how safely you can run two versions simultaneously (shared database schema compatibility matters here).

Choosing a deployment strategy is a risk-management decision, not just a technical one. Here are seven approaches used in production Kubernetes environments, each with when to reach for it.

Deployment Strategy Comparison

1. Recreate

Terminates all old pods, then starts all new pods. Simple, but causes downtime.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 4
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
        - name: web-app
          image: myregistry/web-app:v2

Use case: dev/staging environments, or apps that cannot run two versions concurrently (e.g., exclusive file locks).

2. Rolling Update (Kubernetes Default)

Gradually replaces old pods with new ones, respecting maxUnavailable and maxSurge.

spec:
  replicas: 6
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 2

No extra infrastructure required, zero downtime if readiness probes are configured correctly. Rollback is a kubectl rollout undo, but it's also gradual — not instant.

kubectl rollout undo deployment/web-app
kubectl rollout status deployment/web-app

3. Red-Black (Red-Green) Deployment

Two fully separate, identically-sized environments — "red" (current/live) and "black" (new version) — run in parallel. Traffic cuts over atomically at the load balancer or Service level once the black environment passes validation.

# Service selector flip is the cutover mechanism
apiVersion: v1
kind: Service
metadata:
  name: web-app-svc
spec:
  selector:
    app: web-app
    version: black   # flip from "red" to "black" to cut over
  ports:
    - port: 80
      targetPort: 8080

# Instant rollback: flip the selector back
kubectl patch service web-app-svc -p '{"spec":{"selector":{"version":"red"}}}'

Trade-off: requires 2x compute capacity during the overlap window. Rollback is instantaneous since the old environment is still running, untouched.

4. Blue-Green Deployment

Mechanically identical to red-black — "blue" is current, "green" is new — just a different naming convention some teams and tools (e.g., AWS CodeDeploy) use. If your organization uses both terms, they describe the same pattern.

5. Canary Deployment

Routes a small percentage of live traffic to the new version before scaling it up, using a service mesh or ingress controller's weighted routing.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: web-app
spec:
  hosts:
    - web-app.example.com
  http:
    - route:
        - destination:
            host: web-app
            subset: v1
          weight: 90
        - destination:
            host: web-app
            subset: v2
          weight: 10

Best for catching regressions with real production traffic while limiting blast radius to a small user segment.

6. A/B Testing Deployment

Similar mechanics to canary, but traffic is routed based on specific attributes (cookie, header, geography) rather than random percentage — used for feature experimentation rather than safety validation.

7. Shadow Deployment

The new version receives a copy of live traffic but its responses are discarded — never seen by real users. Used to validate performance and correctness under real load with zero user-facing risk, at the cost of double the compute and more complex traffic mirroring setup (typically via a service mesh).

Choosing the Right Strategy

FAQ

Q: Is red-black deployment the same as blue-green? A: Yes, functionally identical — two naming conventions for the same two-environment, atomic-cutover pattern.

Q: Which strategy is safest for a database schema change? A: None of them fully solve this on their own — schema changes need backward/forward compatible migrations regardless of deployment strategy, since old and new app versions may run concurrently during any gradual rollout.

Q: Does red-black deployment require a service mesh? A: No — it can be done with a simple Kubernetes Service selector flip, an external load balancer target group swap, or DNS cutover. A service mesh is required for finer-grained strategies like canary and A/B testing.

Q: What's the cheapest strategy for a small team? A: Rolling update — it's the Kubernetes default, requires no extra infrastructure, and provides zero-downtime deployments out of the box.

Need Help Designing Your Deployment Pipeline?

F9infotech's DevOps consulting team designs CI/CD pipelines and Kubernetes deployment strategies tailored to your risk tolerance and infrastructure budget — talk to our team about your release process.