Zero‑Downtime Deployment Strategies in Kubernetes — RollingUpdate vs Blue/Green vs Canary

By Kevin Marcondes · Published on Oct 1, 2026 · Updated on Oct 10, 2026 · 7 min read

This comparison lines up zero‑downtime deployment approaches for Kubernetes: RollingUpdate, Blue/Green and Canary. You'll learn how each works, when to use them, their trade‑offs and costs, with practical examples using Service, Ingress and Istio/Argo Rollouts. Use the criteria at the end to choose with confidence.

What zero‑downtime means in Kubernetes, in practice

Zero‑downtime means the application continues serving requests without user‑perceived errors during a version swap. In Kubernetes this depends on readinessProbes, health checks, your update policy and spare capacity to overlap versions.

Define clear SLOs: acceptable error budget, p95 latency and the observation window. Without metrics you can’t validate whether a rollout was truly "zero downtime."

Critical aspects: tolerance for long connections, sticky sessions, warm‑up time, caches and backward/forward database schema compatibility.

• Correct and fast readiness/liveness probes
• maxSurge/maxUnavailable tuned for your traffic
• Spare capacity to overlap versions safely
• Per‑version logs and metrics to compare impact
• Clear, automated rollback

RollingUpdate: simple and effective for most cases

RollingUpdate replaces pods gradually within the same Deployment. You control how many can be unavailable and how many extras can be created via maxUnavailable and maxSurge.

Pros: simple, low infrastructure cost and quick rollback by switching back to the previous ReplicaSet. Cons: traffic mixes versions, which complicates comparisons and can affect persistent sessions.

Works very well when the app is stateless and version‑compatible. Automate it in your CI/CD pipeline with health gates and validations.

See also how to build a pipeline in CI/CD with GitHub Actions: PHP/Laravel guide.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 6
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: registry.example.com/api:v2
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 5

Blue/Green: full isolation with traffic swap

Blue/Green keeps two complete environments: Blue (current) and Green (new). You test Green in isolation and, when approved, flip traffic at once via Service, Ingress or your load balancer.

Pros: strong separation and instant rollback by reverting the selector. Cons: duplicated capacity during testing and swap.

Ideal when you must validate end‑to‑end behavior with real data without mixing versions. Be careful with database migrations: prefer evolving schemas with direct and reverse compatibility. For databases, see the CDC approach in Zero‑Downtime Database Migration with CDC.

apiVersion: v1
kind: Service
metadata:
  name: api-svc
spec:
  selector:
    app: api
    version: green  # mude para 'blue' no rollback
  ports:
    - port: 80
      targetPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-green
spec:
  replicas: 6
  selector:
    matchLabels:
      app: api
      version: green
  template:
    metadata:
      labels:
        app: api
        version: green
    spec:
      containers:
        - name: api
          image: registry.example.com/api:v2

Canary: measure impact with partial traffic and promote

Canary sends a fraction of traffic to the new version and compares metrics. Promotion is gradual, e.g. 5% → 25% → 50% → 100%. You can implement this with Ingress controllers that support canary or with a service mesh.

Tools like Istio or Argo Rollouts allow weighted splits, rule‑based routing and automated analysis. Combine canaries with metrics for errors, p95 latency and saturation. Integrate feature flags to safely expose code paths in parallel with the canary, as discussed in Feature flags in PHP monoliths: safe rollout.

Check cloud provider docs for Istio weighted routing examples, such as Google Cloud’s Service Mesh traffic guides.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: api
spec:
  hosts:
    - api.example.com
  http:
    - route:
        - destination:
            host: api-svc
            subset: v1
          weight: 95
        - destination:
            host: api-svc
            subset: v2
          weight: 5
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: api
spec:
  host: api-svc
  subsets:
    - name: v1
      labels:
        version: v1
    - name: v2
      labels:
        version: v2

Comparative table: objective selection criteria

Compare by the criteria that matter most to the business and operations. Below is a practical summary of the three approaches.

Routing: Service, Ingress and service mesh (Istio/Linkerd)

Service routes versions via selectors. Ingress can route by host/path and some controllers support canary via annotations. Service meshes add weighted traffic splits, circuit breaking and rich telemetry.

For mesh‑based canary and traffic management examples, check provider documentation such as Google Cloud’s Service Mesh and weighted routing guides. Blue/Green with managed load balancers (EKS) is also common.

• Service: swap label selector for Blue/Green
• Ingress: split by host/path and, in some controllers, canary via annotations
• Service Mesh: subset weights, retries and mTLS policies

Costs, risks and rollout governance

Costs vary by replica counts, traffic, canary windows and duplicated environments for Blue/Green. High traffic and large images increase egress and rollout time.

Common risks: incompatible migrations, performance regressions in the new version and lost sessions. Mitigate with E2E tests, automated smoke tests and per‑version metrics.

Document promotion and rollback criteria. Clear schedules, playbooks and responsibilities help. If you struggle with frequent deployment incidents, consider a Deployment process audit and remediation plan.

• Define guard metrics: error rate, latency and saturation
• Automate promotion and rollback gates
• Reserve capacity for safe overlap
• Plan reversible, compatible migrations
• Validate sessions and sticky routing when required

Frequently asked questions

When should I choose RollingUpdate instead of Blue/Green or Canary?

Choose RollingUpdate when the service is stateless, versions are compatible and you want simplicity and low cost. RollingUpdate is a solid default. If you need isolated E2E tests or precise impact measurement, consider Blue/Green or Canary.

Can I do Canary without a service mesh?

Yes. Some Ingress controllers support canary via annotations to route a fraction of traffic. However, observability and policy controls are usually more limited than with a service mesh, which offers subset weights and integrated telemetry.

How should I handle database migrations during a deploy?

Use migrations that are compatible with simultaneous versions. First apply additive changes and keep old fields. Roll out the application, then remove obsolete fields later. For critical scenarios, evaluate CDC to transition without downtime.

Which strategy offers the fastest rollback?

Blue/Green typically allows instant rollback by reverting the selector or route. RollingUpdate rolls back to the previous ReplicaSet. In Canary you can quickly set the new version’s weight to 0%. System readiness and automation determine the actual speed.

Which metrics should I watch during a canary release?

Errors per second, relevant 5xx/4xx rates, p95/p99 latency, CPU/memory saturation, queue lengths and timeouts. Monitor per version to compare against the baseline and set thresholds and observation windows for automatic promotion or rollback.

See also

• Ceph vs NFS vs GlusterFS for shared storage on VPS with containers
• Prometheus & Grafana vs Loki & Tempo for PHP observability
• Amazon SQS vs Managed RabbitMQ for ERP–Marketplace Integrations
• Comparing Traefik and Caddy for HTTPS routing in Docker environments