7 Kubernetes Deployment Strategies and When to Use Each

Arvind VermaOct 26, 2026

7 Kubernetes Deployment Strategies and When to Use Each

Rolling Updates, Blue-Green, Canary, A/B Testing, and Shadow Deployments Explained

Arvind Verma

Oct 26

Imagine deploying a new version of your application to production.

The new version starts successfully. Kubernetes reports that the Pods are running. Everything looks healthy.

Then users begin reporting errors.

Some requests succeed, while others fail. Latency increases. Your monitoring dashboard turns red, and your team starts investigating what changed.

The problem might not be Kubernetes itself. It might be how you released the new version.

Deployment strategy matters because a successful deployment is not just about starting new Pods. It is about controlling risk, maintaining availability, validating application behavior, and recovering safely when something goes wrong.

Kubernetes provides built-in Deployment strategies, while additional delivery patterns can be implemented using Services, ingress controllers, service meshes, and progressive delivery tools.

Let’s explore seven strategies, when to use each, and what to watch for in production.

1. Rolling Update: The Default Workhorse

What is it?

A Rolling Update gradually replaces old Pods with new ones instead of terminating every old Pod at once.

Kubernetes Deployments use the RollingUpdate strategy by default.

You can control the rollout using maxSurge and maxUnavailable.

maxSurge defines how many additional Pods can be created above the desired replica count during the update.
maxUnavailable defines how many Pods can be unavailable during the rollout.

Example

Suppose your application has four replicas. You can configure a rolling update like this:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: my-app
          image: nginx:1.28
          ports:
            - containerPort: 80
          readinessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 5
            periodSeconds: 5

Apply and monitor the deployment:

kubectl apply -f deployment.yaml
kubectl rollout status deployment/my-app
kubectl rollout history deployment/my-app

The readiness probe helps Kubernetes determine when a Pod is ready to receive traffic. In a real application, the probe should test meaningful application readiness rather than merely whether a process exists.

Advantages

Gradual replacement instead of an all-at-once switch.
Suitable for most stateless applications.
No separate blue environment is required.
Supports controlled rollouts through standard Kubernetes resources.

Risks

Old and new versions may serve traffic simultaneously. Your application must tolerate that overlap.

Database schema changes, API incompatibilities, and shared state can make mixed-version operation dangerous.

Also, a readiness probe does not guarantee that the application is free from bugs.

When should you use it?

Use Rolling Updates for routine releases of stateless applications when the old and new versions can safely coexist.

Interview takeaway: Rolling Updates reduce deployment disruption, but they do not automatically guarantee zero downtime.

2. Ramped Slow Rollout: A More Conservative Rolling Update

What is it?

A ramped slow rollout is not a separate built-in Kubernetes Deployment strategy. It is a controlled way to perform a Rolling Update using conservative settings.

For example:

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 1

With four desired replicas, Kubernetes can create up to one additional Pod and allow up to one desired replica to be unavailable during the update.

However, these values do not guarantee that only one Pod changes at a time. The controller may make progress faster when the state of the Deployment permits it.

For a more conservative rollout, use appropriate readiness probes and monitor progress between steps. If you require explicit pauses, approval gates, or automated metric checks, use a delivery controller or deployment pipeline that supports those controls.

Advantages

Limits the pace and size of some rollout changes.
Gives teams more opportunity to observe application health.
Uses standard Kubernetes Deployment capabilities.

Risks

Releases can take longer.
Conservative settings do not replace monitoring.
A rollout may still progress without a human inspecting each intermediate state.

When should you use it?

Use a conservative Rolling Update for services where gradual replacement is preferred and you want to limit the pace of change.

Interview takeaway: maxSurge: 1 and maxUnavailable: 1 control rollout capacity, but they do not by themselves implement a fully step-by-step approval process.

3. Recreate: Stop the Old Version, Then Start the New One

What is it?

The Recreate strategy terminates the existing Deployment’s Pods before creating Pods for the new version.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 4
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: my-app
          image: nginx:1.28
          ports:
            - containerPort: 80

Advantages

Simple deployment behavior.
Avoids overlap between the old and new ReplicaSets’ Pods managed by this Deployment during the replacement process.
Useful when simultaneous versions cannot safely run together.

Risks

There is typically a period when the Deployment has no available Pods. That can cause downtime.

Also, Recreate does not guarantee that no old and new versions can ever coexist in the entire cluster. Other Deployments, Jobs, or independently managed workloads may still run the old version.

When should you use it?

Consider Recreate for development workloads, certain batch jobs, or applications that cannot safely run multiple versions simultaneously and can tolerate downtime.

For production systems, evaluate the impact on availability before choosing this strategy.

Interview takeaway: Recreate simplifies version replacement, but the downtime trade-off must be explicit.

4. Blue-Green Deployment: Prepare, Validate, Switch

What is it?

Blue-Green deployment maintains two application environments:

Blue: The currently active version.
Green: The new version being prepared and validated.

Once Green passes the required checks, traffic is switched to it.

One Kubernetes implementation uses separate Deployments and a Service whose selector determines which version receives traffic.

Example

The blue Deployment has labels such as:

app: my-app
version: blue

The green Deployment uses:

app: my-app
version: green

A Service can select the active version:

apiVersion: v1
kind: Service
metadata:
  name: my-app
spec:
  selector:
    app: my-app
    version: blue
  ports:
    - port: 80
      targetPort: 80

After deploying and validating Green, update the selector to:

selector:
  app: my-app
  version: green

The selector change redirects new Service-routed traffic toward the green Pods as endpoints are updated.

Advantages

The new version can be validated before the traffic switch.
Switching traffic can be fast.
Reverting the Service selector can provide a quick recovery path when the old environment remains healthy.

Risks

Running two environments costs more resources.
Service endpoint propagation and existing connections mean the switch is not necessarily instantaneous.
Database migrations and shared state can make rollback unsafe.
Keeping Blue running indefinitely increases cost and operational complexity.

When should you use it?

Use Blue-Green when a clean traffic switch and a prepared recovery environment are worth the extra infrastructure.

Interview takeaway: Blue-Green can simplify application rollback, but it cannot automatically reverse incompatible database changes or other external side effects.

5. Canary Deployment: Release to a Small Audience First

What is it?

A Canary deployment exposes a new version to a limited portion of production traffic, then increases exposure as confidence grows.

A typical progression might be:

5% → 25% → 50% → 100%

The exact percentages and waiting periods depend on traffic volume, service criticality, and risk.

How it works

Deploy the new version alongside the stable version.
Route a small share of requests to the new version.
Monitor errors, latency, resource usage, and business-critical signals.
Increase traffic if the results meet your release criteria.
Stop or roll back the rollout if the new version behaves badly.

A basic Kubernetes Service does not automatically split traffic by percentages. Canary routing generally requires an ingress controller with suitable traffic-splitting capabilities, a service mesh, a Gateway API implementation with supported weighted routing, or a progressive delivery tool.

Tools such as Argo Rollouts can automate progressive analysis and promotion when configured with compatible traffic routing and metrics providers.

What should you monitor?

Error rate and HTTP 5xx responses.
p95 and p99 latency.
CPU and memory usage.
Request success rate.
Business metrics such as checkout completion or transaction failures.

Advantages

Limits exposure to a potentially faulty release.
Tests the new version with real production traffic.
Enables promotion based on observable evidence.

Risks

Requires traffic-routing capabilities and reliable monitoring.
Low traffic may not provide enough evidence.
A bad canary can still affect real users.
Metrics and promotion thresholds must be designed carefully.

When should you use it?

Use Canary deployments for high-impact services where gradual exposure and evidence-based promotion are important.

Interview takeaway: Canary without meaningful metrics is not progressive delivery. It is just a small deployment with extra steps.

6. A/B Testing: Compare User Experiences

What is it?

A/B testing runs two or more versions to compare outcomes for different user groups.

Unlike a typical Canary release, whose main goal is to validate the safety of a new release, A/B testing is often designed to compare product or business outcomes.

For example:

Version A uses the current checkout design.
Version B uses a redesigned checkout.
The team compares conversion rates, completion times, or other defined outcomes.

How it works

Traffic is assigned according to rules such as user identity, cookie, request header, or experiment assignment.

The routing layer must support those rules. A standard Kubernetes Service does not provide arbitrary user-based routing on its own.

Advantages

Supports evidence-based product decisions.
Allows controlled comparison of user experiences.
Can measure outcomes beyond basic application health.

Risks

Requires reliable experiment design and routing.
Poorly selected metrics can lead to incorrect conclusions.
Sample size, experiment duration, and user assignment matter.
Multiple simultaneous changes can make results difficult to interpret.

When should you use it?

Use A/B testing when you want to compare product behavior or business outcomes rather than merely confirm that a new build is healthy.

Interview takeaway: Canary asks, “Can this release operate safely?” A/B testing asks, “Which experience performs better against our chosen outcome?”

7. Shadow Deployment: Test With Real Traffic Without Serving the Response

What is it?

A Shadow deployment sends a copy of production requests to a new version while the existing version continues serving the actual responses to users.

The new version processes the mirrored requests, but its responses are not returned to the original users.

Example

Suppose you are replacing an API service.

The current version handles production requests. A traffic-mirroring layer duplicates selected requests to the new version. Engineers compare the two versions’ latency, errors, logs, and outputs.

Advantages

Tests behavior under realistic traffic patterns.
Helps uncover performance and compatibility problems.
Does not expose users directly to the shadow version’s responses.

Risks

Requires traffic mirroring or request duplication support.
Consumes additional compute and network resources.
Duplicate requests may trigger unintended side effects if the application is not designed for them.
It does not directly reveal how users would react to the new responses.

Be especially careful with writes, payments, notifications, and other non-idempotent operations. Shadow traffic must not accidentally execute production side effects twice.

When should you use it?

Use Shadow deployments for risky service rewrites, API migrations, or performance validation when realistic request patterns matter.

Interview takeaway: Shadow traffic can reduce user-facing risk, but it does not mean the new version has zero operational impact.

How Do You Choose the Right Deployment Strategy?

The best strategy depends on availability requirements, compatibility, traffic controls, resource budgets, and how you will detect failure.

Quick decision guide

Routine application updates: Rolling Update.
Conservative, capacity-controlled rollout: Rolling Update with carefully chosen parameters and monitoring.
Downtime is acceptable and versions must not overlap within the Deployment: Recreate.
You need a prepared alternate environment and a quick traffic switch: Blue-Green.
You want gradual exposure with production metrics: Canary.
You want to compare user or business outcomes: A/B testing.
You need realistic traffic validation without serving new responses: Shadow deployment.

These strategies are not mutually exclusive. For example, a team might use Blue-Green environments and then introduce a Canary rollout within the green environment.

The important question is not which strategy is most fashionable. It is which strategy controls the risks that matter for your workload.

Five Production Mistakes to Avoid

1. Missing readiness probes

Without a meaningful readiness probe, a Pod may receive traffic before the application is actually ready to serve it.

Improve it: Configure readiness checks that reflect application readiness and verify that they behave correctly during startup and failure.

2. Breaking compatibility between versions

During a Rolling Update or Canary deployment, old and new versions may run simultaneously.

A database schema change that the old application cannot understand can break the release even when every Pod is healthy.

Improve it: Use backward-compatible changes, such as expand-and-contract database migrations, and remove old schema elements only after the old application version is no longer needed.

3. Promoting a Canary without metrics

A successful Pod startup does not prove that the application is behaving correctly.

Improve it: Define release thresholds for error rates, latency, resource usage, and business-critical signals before increasing traffic.

4. Forgetting the cost of Blue-Green

Keeping two complete environments running can increase compute, storage, and supporting-service costs.

Improve it: Define when the inactive environment should be scaled down or removed, while preserving an appropriate recovery option.

5. Assuming rollback reverses everything

Kubernetes can restore an earlier application version, but it cannot automatically undo every database migration, message, external API call, or persistent data change.

Improve it: Design rollback procedures alongside the release plan, including compatibility checks and data-recovery requirements.

Final Thoughts

Kubernetes deployment strategies are not just different ways to replace Pods. They represent different approaches to managing release risk.

Rolling Updates are a practical default. Recreate is simple but can introduce downtime. Blue-Green provides an alternate environment. Canary gradually increases exposure. A/B testing compares outcomes. Shadow deployments validate behavior using mirrored traffic.

The real engineering skill lies in knowing when each approach is appropriate, how to measure success, and what to do when the release goes wrong.

A successful deployment is not simply one where the new Pods are running. It is one where the application remains reliable, the change is validated, and the team has a clear recovery plan.

That is the mindset that turns Kubernetes knowledge into production engineering.

Continue Learning

Explore practical DevOps resources, Kubernetes guides, interview preparation, and production troubleshooting:

DevOps Resource Hub: https://topmate.io/arvindverma021/

Connect on LinkedIn: https://www.linkedin.com/in/arvindverma021/

Read on Medium: https://medium.com/@arvindverma021

Follow on Substack:

Arvind Verma

Hashtags

#Kubernetes #DevOps #KubernetesDeployment #RollingUpdate #BlueGreenDeployment #CanaryDeployment #GitOps #ArgoRollouts #ArgoCD #CloudNative #PlatformEngineering #SRE #AWS #EKS #ProductionEngineering

Arvind Verma is free today. But if you enjoyed this post, you can tell Arvind Verma that their writing is valuable by pledging a future subscription. You won't be charged unless they enable payments.

Pledge your support