Kubernetes Deployment Patterns: Rolling, Blue-Green, Canary & More

Deploying software is the riskiest thing most teams do on a regular basis. A bad deployment can take down production in seconds. Kubernetes gives you powerful primitives to control how new code rolls out — but only if you choose the right strategy for your situation.

This guide covers the major deployment patterns available in Kubernetes, when each one makes sense, and how to implement them with production-ready configurations.

Rolling Updates

Rolling updates are the default deployment strategy in Kubernetes. The cluster gradually replaces old pods with new ones, maintaining availability throughout the process.

How It Works

1. Kubernetes creates new pods running the updated version
2. Once new pods pass readiness probes, old pods are terminated
3. The process continues until all pods run the new version
4. At any point, a mix of old and new pods serves traffic

Configuration

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
  labels:
    app: api-server
spec:
  replicas: 6
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2
      maxUnavailable: 1
  selector:
    matchLabels:
      app: api-server
  template:
    metadata:
      labels:
        app: api-server
        version: v2.4.0
    spec:
      containers:
        - name: api
          image: registry.example.com/api-server:2.4.0
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 5
            failureThreshold: 3
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 15
            periodSeconds: 10
          resources:
            requests:
              cpu: 250m
              memory: 256Mi
            limits:
              cpu: 500m
              memory: 512Mi

The two key parameters:

• maxSurge: 2 — allow up to 2 extra pods above the desired count during rollout. This speeds up deployment by creating new pods before terminating old ones.
• maxUnavailable: 1 — allow at most 1 pod to be unavailable during the update. This ensures capacity stays near 100%.

Readiness Probes Are Critical

Without a properly configured readiness probe, Kubernetes will send traffic to pods that are not ready to serve requests. This causes errors during deployment.

readinessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5
  successThreshold: 1
  failureThreshold: 3

Your /healthz endpoint should verify that the application can actually serve requests — database connections are established, caches are warm, configuration is loaded.

When to Use Rolling Updates

• Stateless services where brief mixed-version traffic is acceptable
• APIs with backward-compatible changes
• Services that start quickly (under 30 seconds)
• Teams that want zero-config deployment with Kubernetes defaults

Limitations

• Traffic hits both old and new versions simultaneously during rollout
• Rollback requires another full rolling update (slow for large deployments)
• Not suitable for breaking database schema changes without additional coordination

Blue-Green Deployments

Blue-green deployments run two identical environments simultaneously. Traffic switches from the current version (blue) to the new version (green) all at once.

How It Works

1. The current production environment (blue) continues serving traffic
2. A complete new environment (green) is deployed alongside it
3. The green environment is tested and validated
4. Traffic is switched from blue to green instantly
5. Blue remains available for instant rollback

Implementation with Kubernetes Services

# Green deployment (new version)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server-green
spec:
  replicas: 6
  selector:
    matchLabels:
      app: api-server
      slot: green
  template:
    metadata:
      labels:
        app: api-server
        slot: green
        version: v2.5.0
    spec:
      containers:
        - name: api
          image: registry.example.com/api-server:2.5.0
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 5
---
# Service pointing to current production (blue)
apiVersion: v1
kind: Service
metadata:
  name: api-server
spec:
  selector:
    app: api-server
    slot: blue
  ports:
    - port: 80
      targetPort: 8080

To switch traffic from blue to green, update the service selector:

kubectl patch service api-server \
  -p '{"spec":{"selector":{"slot":"green"}}}'

Traffic instantly shifts to the green deployment. To roll back, patch the selector back to blue.

Automated Blue-Green with Argo Rollouts

For a more robust implementation, use Argo Rollouts which manages the lifecycle automatically.

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: api-server
spec:
  replicas: 6
  strategy:
    blueGreen:
      activeService: api-server-active
      previewService: api-server-preview
      autoPromotionEnabled: false
      prePromotionAnalysis:
        templates:
          - templateName: smoke-tests
        args:
          - name: service-url
            value: http://api-server-preview.default.svc.cluster.local
      scaleDownDelaySeconds: 300
  selector:
    matchLabels:
      app: api-server
  template:
    metadata:
      labels:
        app: api-server
    spec:
      containers:
        - name: api
          image: registry.example.com/api-server:2.5.0
          ports:
            - containerPort: 8080

This configuration:

• Creates a preview service for testing before promotion
• Runs automated smoke tests before switching traffic
• Waits for manual approval (autoPromotionEnabled: false)
• Keeps the old version running for 5 minutes after switch for rollback safety

When to Use Blue-Green

• Mission-critical services where rollback must be instant
• Applications with long startup times where rolling updates are too slow
• Database migrations that require all pods to run the same version
• Regulated industries where the new version needs pre-production validation

Limitations

• Requires double the cloud infrastructure during deployment
• Database schema changes still need careful coordination
• Long-lived WebSocket or gRPC connections may drop during switch

Canary Releases

Canary releases route a small percentage of traffic to the new version, gradually increasing it as confidence grows. This catches issues that only appear under real production traffic patterns.

How It Works

1. Deploy the new version alongside the current one
2. Route a small percentage (e.g., 5%) of traffic to the new version
3. Monitor error rates, latency, and business metrics
4. Gradually increase traffic to the new version
5. If metrics degrade, route all traffic back to the stable version

Implementation with Argo Rollouts

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: api-server
spec:
  replicas: 10
  strategy:
    canary:
      steps:
        - setWeight: 5
        - pause: { duration: 5m }
        - analysis:
            templates:
              - templateName: error-rate-check
            args:
              - name: service-name
                value: api-server
        - setWeight: 25
        - pause: { duration: 10m }
        - analysis:
            templates:
              - templateName: error-rate-check
        - setWeight: 50
        - pause: { duration: 10m }
        - analysis:
            templates:
              - templateName: latency-check
        - setWeight: 100
      canaryService: api-server-canary
      stableService: api-server-stable
      trafficRouting:
        nginx:
          stableIngress: api-server-ingress
  selector:
    matchLabels:
      app: api-server
  template:
    metadata:
      labels:
        app: api-server
    spec:
      containers:
        - name: api
          image: registry.example.com/api-server:2.5.0
          ports:
            - containerPort: 8080

Automated Analysis

The real power of canary releases is automated promotion based on metrics. Define analysis templates that query your monitoring system.

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: error-rate-check
spec:
  args:
    - name: service-name
  metrics:
    - name: error-rate
      interval: 60s
      successCondition: result[0] < 0.02
      failureLimit: 3
      provider:
        prometheus:
          address: http://prometheus.monitoring:9090
          query: |
            sum(rate(http_requests_total{
              service="{{args.service-name}}",
              status=~"5.."
            }[5m])) /
            sum(rate(http_requests_total{
              service="{{args.service-name}}"
            }[5m]))
---
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: latency-check
spec:
  metrics:
    - name: p99-latency
      interval: 60s
      successCondition: result[0] < 500
      failureLimit: 3
      provider:
        prometheus:
          address: http://prometheus.monitoring:9090
          query: |
            histogram_quantile(0.99,
              sum(rate(http_request_duration_seconds_bucket{
                service="api-server",
                canary="true"
              }[5m])) by (le)
            ) * 1000

If the error rate exceeds 2% or p99 latency exceeds 500ms at any step, Argo Rollouts automatically aborts the canary and routes all traffic back to the stable version.

When to Use Canary Releases

• High-traffic services where even brief outages have significant impact
• Changes that could have performance implications under load
• Feature releases where you want to measure real-user impact before full rollout
• Services with complex failure modes that unit tests cannot catch

A/B Testing with Kubernetes

A/B testing routes traffic based on user attributes rather than random percentages. This is distinct from canary releases — you are testing feature variations on specific user segments.

Implementation with Istio

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: api-server
spec:
  hosts:
    - api.example.com
  http:
    - match:
        - headers:
            x-user-group:
              exact: beta-testers
      route:
        - destination:
            host: api-server
            subset: v2
    - route:
        - destination:
            host: api-server
            subset: v1
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: api-server
spec:
  host: api-server
  subsets:
    - name: v1
      labels:
        version: v1.0.0
    - name: v2
      labels:
        version: v2.0.0

This routes users with the x-user-group: beta-testers header to v2, while all other traffic goes to v1.

Comparison Matrix

| Pattern | Downtime | Rollback Speed | Resource Overhead | Complexity | Mixed Versions | |---------|----------|----------------|-------------------|------------|----------------| | Rolling Update | None | Slow (re-roll) | Low (maxSurge) | Low | Yes, during rollout | | Blue-Green | None | Instant | High (2x resources) | Medium | No | | Canary | None | Fast (automatic) | Low-Medium | High | Yes, controlled | | A/B Testing | None | Fast | Medium | High | Yes, by design |

Production Readiness Checklist

Regardless of which strategy you choose, these practices apply to every Kubernetes deployment.

1. Health checks — configure both readiness and liveness probes. Readiness gates traffic; liveness restarts unhealthy pods.
2. Resource limits — set CPU and memory requests and limits on every container. Without them, a single pod can starve the node.
3. Pod Disruption Budgets — prevent voluntary evictions (node drains, cluster upgrades) from taking down too many pods at once.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-server-pdb
spec:
  minAvailable: 4
  selector:
    matchLabels:
      app: api-server

4. Rollback automation — define clear rollback triggers. Automated analysis with Argo Rollouts is ideal; at minimum, have a documented kubectl rollout undo procedure.
5. Observability — deploy metrics (Prometheus), logs (Loki or ELK), and traces (Jaeger or Tempo) before you need them. You cannot debug a bad deployment without observability.

Choosing the Right Pattern

Start with rolling updates if you are early in your Kubernetes journey. They work out of the box, require no additional tooling, and handle the vast majority of deployment scenarios.

Move to canary releases when you have Prometheus metrics, meaningful SLOs, and the operational maturity to define automated analysis rules. Argo Rollouts makes this accessible without building custom tooling.

Use blue-green for databases, stateful services, or regulated workloads where you need a complete, validated environment before switching traffic.

Add A/B testing when you need to measure business impact of feature variations on specific user segments, not just technical health.

If you are building your Kubernetes deployment pipeline or need help implementing progressive delivery for your infrastructure, talk to our team. We design and build deployment pipelines that ship code safely — from rolling updates to fully automated canary releases with metric-driven promotion.

Deploy with confidence. Measure everything. Roll back fast.