Kubernetes Deployment Strategies and Update Scenarios: 7 Essential Patterns Explained

Kubernetes supports seven primary deployment strategies—Rolling Update, Recreate, Blue‑Green, Canary, A/B Testing, Shadow, and Rolling with Partitioning—that control how traffic shifts between application versions to balance deployment risk, downtime tolerance, and rollback speed.

The litu54/DevOps-Interview-Guide repository documents these patterns extensively, compiling real‑world interview scenarios from companies like EPAM and Sigmoid. Mastering these strategies enables you to execute zero‑downtime rollouts while maintaining system reliability across diverse production environments.

Core Kubernetes Deployment Strategies

Rolling Update (Default Strategy)

Rolling Update is the default deployment strategy in Kubernetes, implemented in the Deployment controller. It updates Pods gradually while respecting maxSurge and maxUnavailable limits, ensuring the desired replica count is maintained throughout the rollout.

According to Others/DevOps_Engineer_15.md, this strategy creates new Pods before terminating old ones, allowing the application to serve traffic continuously during the update. The controller respects the configured surge limits: maxSurge controls how many extra Pods can be created above the desired count, while maxUnavailable determines how many Pods can be unavailable during the update.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp
spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1       # at most one extra Pod

      maxUnavailable: 0 # keep all Pods available

  selector:
    matchLabels:
      app: webapp
  template:
    metadata:
      labels:
        app: webapp
    spec:
      containers:
      - name: webapp
        image: myrepo/webapp:v2   # changed version triggers rollout

        ports:
        - containerPort: 80

Recreate Strategy

The Recreate strategy deletes all existing Pods before creating new ones, resulting in brief downtime while the new Pods start. As noted in the interview guide's discussions about deployment failures, this approach is suitable when a clean slate is required—such as during major schema changes—or for simple workloads where brief downtime is acceptable.

Unlike Rolling Update, Recreate does not maintain availability during the transition, making it inappropriate for production services requiring continuous uptime.

Blue‑Green Deployment

Blue‑Green deployments run two complete environments side‑by‑side. Traffic is switched from the old version (Blue) to the new version (Green) by modifying a Service selector or Ingress rule, enabling instant rollback by reversing the selector.

As documented in Sigmoid/DevOps_Engineer_3.md, this pattern requires changing your Service configuration to reroute traffic. The old version remains available for immediate switch‑back if the new version misbehaves, making it ideal for production‑critical services where recovery time must be minimized.

# Service that points to the "green" version

apiVersion: v1
kind: Service
metadata:
  name: webapp-svc
spec:
  selector:
    app: webapp
    version: green   # change to "blue" to switch traffic

  ports:
  - port: 80
    targetPort: 8080

# Green Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp-green
spec:
  replicas: 3
  selector:
    matchLabels:
      app: webapp
      version: green
  template:
    metadata:
      labels:
        app: webapp
        version: green
    spec:
      containers:
      - name: webapp
        image: myrepo/webapp:v2

Canary Deployment

Canary deployments route a small subset of traffic to the new version while the majority remains on the old version. The traffic proportion can be gradually increased as confidence grows, often implemented using service meshes like Istio or sophisticated Ingress controllers.

The EPAM/DevOps_Engineer_3.md file specifically addresses implementing canary strategies with real‑time monitoring and rollback capabilities. This approach validates new releases gradually, particularly when performance or compatibility concerns exist.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: webapp
spec:
  hosts:
  - webapp.example.com
  http:
  - route:
    - destination:
        host: webapp
        subset: stable
      weight: 90
    - destination:
        host: webapp
        subset: canary
      weight: 10

# DestinationRules defining subsets

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: webapp
spec:
  host: webapp
  subsets:
  - name: stable
    labels:
      version: v1
  - name: canary
    labels:
      version: v2

A/B Testing and Shadow Deployments

A/B Testing resembles Canary but serves different user cohorts to measure business metrics like conversion rates, making it ideal for feature‑flag driven experiments. Shadow (Dark) Deployments send a copy of live traffic to the new version without returning responses to users; results are logged for analysis, enabling safe validation of new code paths without affecting production users.

Both patterns require advanced traffic management capabilities typically provided by service meshes or custom Ingress controllers.

Rolling with Partitioning

Rolling with Partitioning utilizes spec.strategy.rollingUpdate.partition to halt the rollout at a specific replica count, allowing operators to manually verify each step before completing the update. This strategy provides controlled rollouts where human verification is required between stages, reducing the blast radius of potential defects.

Common Kubernetes Update Scenarios

Kubernetes updates trigger when any field changes in a Deployment, StatefulSet, DaemonSet, or Job. The interview guide identifies five critical update scenarios:

Container Image Updates

Changing spec.template.spec.containers[].image initiates a rolling update (or recreate, if configured). The controller detects the template change and orchestrates the replacement of Pods according to the defined strategy.

ConfigMap and Secret Changes

Updating ConfigMaps or Secrets does not automatically reload existing Pods by default. As noted across multiple files in the repository, you must trigger a rollout using kubectl rollout restart deployment/<name> unless using subPath mounts or specific restart policies. This ensures applications pick up configuration changes without manual Pod deletion.

Resource Limits and Requests

Adjusting CPU or Memory limits in spec.template.spec.resources triggers a rolling update, allowing the scheduler to place new Pods on nodes with appropriate capacity. This prevents resource starvation while maintaining availability during the transition.

Replica Count Changes

Scaling operations (changing replicas) occur instantaneously without introducing new versions. This horizontal scaling does not trigger a rolling update but simply adds or removes Pod instances.

Pod Template Annotation Changes

Adding annotations like kubectl.kubernetes.io/restartedAt forces a rollout without functional changes. This technique is useful for "restart‑only" scenarios, such as refreshing stale connections or reloading certificates, without modifying container images or configurations.

Summary

• Rolling Update provides zero‑downtime deployments using maxSurge and maxUnavailable controls, as documented in Others/DevOps_Engineer_15.md.
• Recreate offers simplicity at the cost of brief downtime, suitable for schema migrations or non‑critical workloads.
• Blue‑Green enables instant traffic switching and rollback via Service selector changes, detailed in Sigmoid/DevOps_Engineer_3.md.
• Canary validates releases gradually using traffic weighting, with implementation guidance in EPAM/DevOps_Engineer_3.md.
• Shadow and A/B Testing provide risk‑free validation and business metric testing through traffic duplication and cohort routing.
• Rolling with Partitioning supports manual gates during rollouts for high‑risk changes.
• Updates trigger from image changes, resource adjustments, or forced rollouts via annotations, while ConfigMap updates require explicit restarts.

Frequently Asked Questions

What is the difference between Canary and Blue‑Green deployment?

According to Others/DevOps_Engineer_10.md, Blue‑Green maintains two complete environments with immediate traffic switching, while Canary gradually shifts percentages of traffic to the new version. Blue‑Green enables instant rollback by switching Service selectors, whereas Canary requires adjusting traffic weights (e.g., Istio VirtualService weights) to dial back changes. Use Blue‑Green when you need immediate switch‑back capability; use Canary when you want to validate performance with real traffic before full commitment.

How do you trigger a rolling update without changing the container image?

You can force a rolling update by modifying the Pod template annotation kubectl.kubernetes.io/restartedAt with a timestamp, or by changing any field in spec.template such as environment variables or resource limits. Running kubectl rollout restart deployment/<name> achieves the same result by automatically adding the restart annotation. This technique is essential when ConfigMaps or Secrets change, as Pods do not automatically reload these references.

What are maxSurge and maxUnavailable in Kubernetes rolling updates?

maxSurge controls how many extra Pods can be created above the desired replica count during an update (absolute number or percentage), while maxUnavailable defines how many Pods can be unavailable during the process. Setting maxUnavailable: 0 ensures zero downtime by preventing termination of old Pods before new ones are ready, while maxSurge: 1 limits resource overhead by allowing only one extra Pod at a time. These parameters balance availability against resource consumption and update speed.

When should I use the Recreate strategy instead of RollingUpdate?

Use Recreate when your application cannot run multiple versions simultaneously—such as during database schema migrations that are incompatible with the previous code version—or when resource constraints prevent running extra Pods (surge capacity). As referenced in deployment failure scenarios within the repository, Recreate is also appropriate for development environments or simple stateless applications where brief downtime is acceptable and infrastructure costs must be minimized.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}