6 Kubernetes deployment strategies (with sample code) featured image

Deploying applications to Kubernetes can be a nerve-wracking experience. You're managing containers, pods, services, and configurations—and every little piece needs to work right or the whole system could fail. 

And failure means downtime, degraded performance, and frustrated users. Not to mention the potential for new bugs to be unleashed upon your entire user base simultaneously. 

Fortunately, employing the right Kubernetes deployment strategy can help you roll out new features with confidence. Choosing the right strategy helps you:

  • Minimize risk when rolling out new features
  • Maintain service availability during updates
  • Better manage resources across your cluster
  • Quickly roll back if something goes wrong
  • Test new versions of the application with real traffic before full release

Bugs and software problems are inevitable. However, the disruptions and issues they cause don’t have to be. The right Kubernetes deployment strategy will position you to ship better products and features, while also having the capabilities to reverse if (and when) things don’t go according to plan.

This guide will show you everything you need to know about the different Kubernetes deployment strategies at your disposal.

What is a Kubernetes deployment strategy?

A Kubernetes deployment strategy is your plan for updating applications in production without things going sideways. It’s your playbook for swapping out the old version of your application for the new one—while keeping your services running and your users happy.

It’s more than just updating your YAML files and hoping for the best (or at least it should be). A proper deployment strategy defines exactly how your new application version will replace the old one, including:

  • How many pods you'll replace at once
  • Whether you'll run old and new versions side by side
  • What happens if something breaks
  • How traffic gets routed during the update
  • How to roll back if needed

The strategy you choose impacts everything from your application's availability to your resource usage to your ability to test new features safely. And while Kubernetes provides several built-in deployment strategies, each has its own tradeoffs.

For example, you might choose a more cautious approach for your payment processing service and gradually shift traffic to new pods while keeping the old ones around for quick rollback. But for an internal dashboard that can handle a few minutes of downtime? A simpler, faster strategy might make more sense.

Ultimately, it’s all about matching your deployment strategy to your specific needs—your application architecture, your DevOps team's capabilities, your users' expectations, and your business requirements. 

Kubernetes deployments vs. alternatives

Before we get into the deployment strategies, let's look at what makes deployments different from other Kubernetes services and resources:

Deployments vs. Pods

  • Pods are the smallest deployable units in Kubernetes clusters—they run your containers
  • Deployments manage sets of pods, handling updates and scaling automatically
  • If a pod fails, deployments can automatically replace it
  • Deployments make it easy to roll back to previous versions

Deployments vs. ReplicaSets

  • ReplicaSets guarantee a desired number of pod replicas are running
  • Deployments manage ReplicaSets for you, adding update and rollback capabilities
  • Think of ReplicaSets as the engine, and Deployments as the driver's controls

Deployments vs. StatefulSets

  • Deployments work best for stateless applications
  • StatefulSets maintain pod identity and desired state—critical for databases
  • StatefulSets update pods in order, while deployments can update in parallel

Deployments vs. DaemonSets

  • DaemonSets run one pod per node (great for logging or monitoring)
  • Deployments let you choose how many replicas to run and where
  • DaemonSets update pods automatically when nodes are added or removed

6 types of Kubernetes deployment strategies

There's no one-size-fits-all approach to deploying applications on Kubernetes. Each strategy provides different tradeoffs between speed, safety, complexity, and resource usage. Some prioritize zero-downtime updates, while others focus on testing in production or managing risk through gradual rollouts.

Let’s look at the different strategies, how they work, and when to use them:

  1. Recreate deployment
  2. Rolling update
  3. Blue/green deployment
  4. Canary deployment
  5. Shadow deployment
  6. A/B testing deployment

1. Recreate deployment

A recreate deployment strategy does exactly what it sounds like—it terminates all the existing pods running your old version before spinning up new ones with your updated application.

It’s like flipping a switch: old version off, new version on.

Here's what it looks like in practice:

  1. All existing pods running version 1.0 are terminated
  2. Kubernetes waits for them to shut down completely
  3. New pods with version 2.0 are created
  4. Service resumes once the new deployment pods are ready

Here's a basic YAML configuration:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-app:2.0

When to use recreate deployment

The recreate strategy makes the most sense when:

  • Your application can't handle running multiple versions simultaneously
  • You're working in development environments where downtime is acceptable
  • You need to run database schema migrations between versions
  • You want the simplest possible deployment strategy
  • Resource constraints prevent running both old and new versions at once

Challenges

The biggest tradeoff is downtime. Your application will be completely unavailable during the transition from old to new versions. The duration depends on how long it takes to:

  • Terminate all old pods
  • Start up new pods
  • Complete any initialization processes
  • Pass readiness checks

Plus, you'll want to consider that if something goes wrong with the new version, you'll face additional downtime while rolling back.

2. Rolling update

Rolling updates are Kubernetes' default deployment strategy—and for good reason. Instead of replacing all pods at once, rolling deployments gradually swap out old pods for new ones. This means your application stays available during the update, and you can catch issues before they affect all users.

Here's what the rolling update process looks like in practice:

  1. A new pod with version 2.0 is created
  2. Once the new pod is healthy and ready, an old pod running version 1.0 is removed
  3. This process repeats until all pods are running the new version of the application
  4. If any new pod fails to start, the deployment process can be paused or rolled back

Here's a basic YAML configuration:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-app:2.0

When to use rolling update strategy

Rolling updates are a great default choice when:

  • You need zero-downtime deployments
  • Your application can handle running multiple versions of an application simultaneously
  • You want to catch issues early before affecting all users
  • You need to control the pace of updates
  • Resource constraints prevent running double capacity (unlike blue/green)

Challenges

Rolling updates aren't perfect, though:

  • Both versions of your application need to run simultaneously
  • Database schema changes can be tricky to coordinate
  • Users might get inconsistent experiences during the rollout
  • Network connections may need to handle version differences
  • Rolling back can take time if issues are discovered late in the update

3. Blue/Green deployment

With blue/green application deployment, you run two identical environments—blue (current) and green (new)—and switch traffic between them. When it's time to update, you deploy the new version to the inactive environment, test it thoroughly, and then flip the switch.

It's a bit more complex than rolling updates, but it gives you a higher level of certainty. You can test your new version in a production environment with real data before any users see it.

Here's what it looks like in practice:

  1. Blue environment serves all production traffic (version 1.0)
  2. Green environment is created and updated (version 2.0)
  3. Green environment is tested with real production data
  4. Once verified, traffic is switched from blue to green
  5. Blue environment stays available for quick rollback

Here's a basic YAML configuration:

# Blue deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-blue
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
      version: blue
  template:
    metadata:
      labels:
        app: my-app
        version: blue
    spec:
      containers:
      - name: my-app
        image: my-app:1.0

---
# Green deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
      version: green
  template:
    metadata:
      labels:
        app: my-app
        version: green
    spec:
      containers:
      - name: my-app
        image: my-app:2.0

---
# Service for routing traffic
apiVersion: v1
kind: Service
metadata:
  name: my-app
spec:
  selector:
    app: my-app
    version: blue  # Switch to 'green' when ready
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

When to use blue/green deployment

Blue/green deployments are a great option when:

  • You need to test thoroughly in a production environment
  • Downtime during switchover isn't an issue
  • You want fast rollbacks (just switch back to blue)
  • Your application requires extensive warm-up time
  • You're making significant changes that need validation
  • Database compatibility isn't a concern between versions

Challenges

It’s not all sunshine and roses, though. The main challenges with blue/green deployments:

  • You need double the resources during deployment
  • Database migrations require special handling
  • Service discovery and DNS caching can complicate the switch
  • Stateful applications need careful planning
  • Cost implications of running two environments

4. Canary deployment

You release your new version to a small subset of users or traffic first. This gives you an opportunity to spot any signs of trouble before rolling out to everyone.

Canary deployments are like having a trusted group of beta testers (but in production). If something goes wrong, you've limited the blast radius. And if everything looks good, you can gradually increase traffic to the new version.

Here's what it looks like in practice:

  1. Most traffic (say, 95%) goes to version 1.0
  2. A small portion (5%) gets routed to version 2.0
  3. Monitor for errors, performance issues, and user feedback
  4. Gradually increase traffic to version 2.0 if all looks good
  5. Roll back quickly if any issues appear

Here's a basic YAML configuration:

# Main deployment (version 1.0)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-stable
spec:
  replicas: 9  # 90% of pods
  selector:
    matchLabels:
      app: my-app
      version: stable
  template:
    metadata:
      labels:
        app: my-app
        version: stable
    spec:
      containers:
      - name: my-app
        image: my-app:1.0

---
# Canary deployment (version 2.0)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-canary
spec:
  replicas: 1  # 10% of pods
  selector:
    matchLabels:
      app: my-app
      version: canary
  template:
    metadata:
      labels:
        app: my-app
        version: canary
    spec:
      containers:
      - name: my-app
        image: my-app:2.0

When to use canary deployments

Canary releases are perfect when:

  • You want to test new functionality with real users and traffic
  • You need to validate performance in production
  • You're making significant changes that could impact users
  • You want to gather feedback before full rollout
  • Risk management is a top priority

Challenges

Here are a few things to keep in mind with canary deployments:

  • You need good monitoring and metrics to detect issues
  • Traffic splitting can be complex to set up
  • Session handling needs careful consideration
  • Database schema changes require special planning
  • Testing with a small subset might miss edge cases

Shadow deployments (sometimes called mirror deployments) are equivalent to a "try before you buy" strategy. You run your new version alongside the existing one and send it a copy of all live traffic. However, the responses from the new version are thrown away. Only the current version handles real user traffic.

It’s simply a practice run with real data. Your new version gets battle-tested with production traffic, but if it breaks, no users are affected because they're still being served by the stable version.

Here's what it looks like in practice:

  1. Version 1.0 handles all user traffic
  2. Version 2.0 receives a copy of the traffic
  3. Both versions process requests, but only version 1.0 responds to users
  4. Compare metrics, logs, and performance between versions
  5. Switch to version 2.0 only after thorough validation

Here's a basic configuration approach:

# Main deployment (version 1.0)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-prod
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
      version: prod
  template:
    metadata:
      labels:
        app: my-app
        version: prod
    spec:
      containers:
      - name: my-app
        image: my-app:1.0

---
# Shadow deployment (version 2.0)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-shadow
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
      version: shadow
  template:
    metadata:
      labels:
        app: my-app
        version: shadow
    spec:
      containers:
      - name: my-app
        image: my-app:2.0

When to use shadow deployments

Consider shadow testing when:

  • You're making major architectural changes
  • Performance testing matters
  • You need to validate with real production patterns
  • You're dealing with complex microservice interactions
  • Failure in production costs are extremely high
  • You need to test with real data volumes

Challenges

Shadow deployments have a few obstacles, though:

  • You need double the computing resources
  • Complex to set up proper traffic mirroring
  • Handling stateful operations requires careful planning
  • Difficult to test actual user interactions
  • Monitoring and comparing metrics can be tricky

6. A/B testing deployment

Instead of assuming your new version is better, you can prove it by running different versions simultaneously and comparing their performance.

You split your traffic between version A and version B, measure everything from user behavior to system performance, and let the data tell you which version wins.

Here's what it looks like in practice:

  1. Version A (control) and Version B (variant) run simultaneously
  2. Traffic is split between versions based on defined rules
  3. Metrics are collected for both versions
  4. Statistical analysis determines which performs better
  5. The winning version is rolled out to all end-users

Here's a basic YAML configuration:

# Version A deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-a
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
      version: A
  template:
    metadata:
      labels:
        app: my-app
        version: A
    spec:
      containers:
      - name: my-app
        image: my-app:1.0

---
# Version B deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-b
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
      version: B
  template:
    metadata:
      labels:
        app: my-app
        version: B
    spec:
      containers:
      - name: my-app
        image: my-app:2.0

When to use A/B testing deployments

A/B testing makes sense when:

  • You need data to validate changes
  • You're testing UX improvements
  • You’re focusing on performance optimization
  • You want to compare different implementations
  • You need to validate hypotheses about user behavior

Challenges

A/B testing has a few challenges:

  • Need clear success metrics before starting
  • Statistical significance requires sufficient traffic
  • Session persistence can complicate testing
  • Multiple variants increase complexity
  • Analysis needs to account for external factors

Improve your risk management with feature flags

Unfortunately, even the most carefully planned Kubernetes deployment strategy can't eliminate all risks. However, combining your deployment strategy with feature flags gives you an extra layer of control and safety.

Think of it this way: your deployment strategy handles how code gets to production, while feature flags control what happens once it's there. This separation of deployment from release means you can:

  • Deploy code without exposing features
  • Test in production safely
  • Roll back instantly without pod changes
  • Target specific users or regions
  • Gradually release features to validate performance

How LaunchDarkly works with Kubernetes

LaunchDarkly integrates seamlessly with any Kubernetes deployment strategy:

With recreate deployments:

  • Keep new features off during the initial deployment
  • Enable features gradually after pods are stable
  • Kill problematic features without redeploying

With rolling updates:

  • Maintain feature consistency across pod versions
  • Test new features before starting the rollout
  • Control feature exposure independently of pod updates

With blue/green:

  • Test features in green environment before switching
  • Maintain consistent feature states across environments
  • Roll back features without switching environments

With canary:

  • Fine-tune exposure beyond pod-level traffic splitting
  • Target specific users or segments for testing
  • Control multiple features independently
  • Get feature-level metrics to inform rollout decisions

And feature flags aren't just for deployments—they help you manage risk throughout your application lifecycle:

  • Emergency kill switches for critical features
  • A/B testing for performance optimization
  • Regional or segment-specific releases
  • Capacity management during high-traffic periods
  • Progressive feature rollouts
  • Quick incident response without code changes

Don't just ship and hope. Combine smart deployment strategies with feature management to deploy with confidence. Start your free full-access 14-day trial to try for yourself.

Like what you read?
Get a demo
Related Content

More about Industry Insights

November 2, 2024