Kubernetes Deployment Strategies: Blue/Green vs Canary

By default, Kubernetes uses a "Rolling Update" strategy for Deployments. It kills an old pod, spins up a new pod, and repeats until all pods are updated. While this is simple, it can be risky if a critical bug slips through testing. For enterprise applications, we need advanced strategies: Blue/Green and Canary.

Blue/Green Deployments

In a Blue/Green deployment, you have two identical environments. The "Blue" environment is currently live and receiving 100% of production traffic. You deploy the new version of your application to the "Green" environment.

Once the Green environment is fully booted and passes internal smoke tests, you instantly switch the Kubernetes Service selector (or Ingress) to point to the Green pods.

Pros and Cons

Pro: Instant rollback. If the new version crashes, you just flip the traffic router back to Blue.
Pro: No version mixing. Users either experience v1 or v2, never a mix of both.
Con: High resource utilization. You need enough server capacity to run two full copies of your production stack simultaneously.
Con: Database migrations are very tricky. Both v1 and v2 must be compatible with the database schema simultaneously.

Canary Deployments

A Canary deployment introduces the new version slowly to a small subset of users before rolling it out to everyone. For example, you route 95% of traffic to v1, and 5% to v2 (the Canary).

If error rates spike in the 5% group, you immediately halt the rollout and send 100% back to v1. If it's stable, you gradually increase traffic to the canary (10%, 25%, 50%, 100%).

Implementing with Istio or NGINX Ingress

While native Kubernetes doesn't support percentage-based traffic splitting out-of-the-box, Service Meshes like Istio or advanced Ingress controllers make it easy.

# Example NGINX Ingress Canary Configuration
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-canary
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "10" # 10% of traffic
spec:
  rules:
  - host: myapp.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: myapp-v2
            port: 
              number: 80

Pros and Cons

Pro: Minimizes blast radius. If v2 has a fatal flaw, only 5% of users are impacted.
Pro: Allows testing in production with real traffic and real data, which is often impossible to simulate accurately in staging.
Con: Slower deployment cycles. A full canary rollout might take hours to complete.

Conclusion

Choosing between Blue/Green and Canary depends on your constraints. If you prioritize speed and instant rollbacks (and have the budget for 2x capacity), use Blue/Green. If you prioritize safety and minimizing user impact during major architectural changes, implement Canary releases.