Implementing Blue-Green Deployment with Kubernetes and Helm:

John AbioyeJohn Abioye
6 min read

In the world of modern software delivery, the ability to deploy applications frequently, safely, and with minimal downtime is no longer a luxury; it’s a requirement. Businesses demand high availability, users expect uninterrupted service, and DevOps teams strive for seamless delivery pipelines. One powerful deployment strategy that addresses these demands is Blue-Green Deployment.

When paired with Kubernetes and Helm, blue-green deployments become not just achievable but repeatable, scalable, and manageable. This article will walk you through the what, why, and most importantly, the how of implementing blue-green deployments using Kubernetes and Helm charts.

Table of Contents

  1. What is Blue-Green Deployment?

  2. Why Use Blue-Green Deployment in Kubernetes?

  3. Key Components: Kubernetes and Helm

  4. Blue-Green Deployment Workflow in Kubernetes

  5. Step-by-Step Implementation:

    • Preparing the Helm Chart

    • Configuring Kubernetes Resources

    • Switching Traffic

    • Rollback Strategies

  6. Advanced Tips: Automation and CI/CD Integration

  7. Common Pitfalls and How to Avoid Them

  8. Final Thoughts

1. What is Blue-Green Deployment?

Blue-Green Deployment is a deployment strategy that reduces downtime and risk by running two identical production environments, known as Blue and Green. At any given time, one environment (say, Blue) is live, serving all production traffic, while the other (Green) remains idle or in testing.

When a new version of your application is ready:

  • You deploy it to the idle environment (Green).

  • You perform tests on Green while Blue is still live.

  • Once Green is verified, you switch the traffic router (like a LoadBalancer, Ingress, or Service selector) to Green.

  • The former production (Blue) now becomes idle and can either be kept for quick rollback or decommissioned.

This technique allows zero-downtime deployment with minimal risk because the previous version is still available and can be instantly reinstated.

2. Why Use Blue-Green Deployment in Kubernetes?

Kubernetes provides powerful primitives for container orchestration, but by default, its rolling updates may introduce a slight service disruption or risk of requests hitting pods that haven’t yet fully started.

Benefits of Blue-Green in Kubernetes:

  • ✅ True Zero-Downtime: Traffic is only switched once the new version is fully ready.

  • ✅ Quick Rollbacks: Rollbacks are instant because the previous version still exists.

  • ✅ Safe Testing: New versions can be tested in the real production environment without impacting users.

  • ✅ Controlled Traffic Switching: Full control over when and how traffic is routed.

By using Helm alongside Kubernetes, you can package, version, and parameterize your deployments, making blue-green deployments repeatable and manageable across different environments.

3. Key Components: Kubernetes and Helm

Before diving in, let’s briefly review the tools we’ll use.

Kubernetes Primitives:

  • Deployment: Manages ReplicaSets and rolling updates.

  • Service: Routes traffic to a set of pods based on selectors.

  • Ingress: Provides HTTP/HTTPS routing.

  • Labels & Selectors: The foundation of Kubernetes routing and filtering.

Helm:

  • Helm Charts: Templates that describe Kubernetes resources.

  • Values Files: Parameterized configurations for customizing deployments.

  • Release Management: Helm handles versioning and release histories, which is critical for blue-green switching.

4. Blue-Green Deployment Workflow in Kubernetes

Here’s a high-level overview of how blue-green deployment can be structured in Kubernetes:

  1. Deploy the new version (Green) using a Helm chart with a unique label (e.g., app=web, version=green).

  2. Point the Kubernetes Service to the Green pods by updating the selector.

  3. Verify the Green environment.

  4. Switch traffic to Green (either by changing the Service selector or swapping Ingress rules).

  5. Optionally, delete or retain the Blue deployment for rollback.

The magic happens in the Service: whichever set of pods the Service targets will receive the production traffic.

5. Step-by-Step Implementation

Let’s walk through a practical implementation using Helm and Kubernetes.

📂 Project Structure Example:

my-app/
├── charts/
├── templates/
│   ├── deployment.yaml
│   ├── service.yaml
│   └── ingress.yaml
├── values.yaml
└── Chart.yaml

Step 1: Preparing the Helm Chart

You’ll need a Helm chart that supports blue-green deployment via templating.

In your values.yaml:

appName: my-app
image:
  repository: my-app
  tag: "1.0.0"

deploymentColor: blue

service:
  name: my-app-service
  port: 80

Step 2: Configuring the Kubernetes Deployment

In deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Values.appName }}-{{ .Values.deploymentColor }}
  labels:
    app: {{ .Values.appName }}
    version: {{ .Values.deploymentColor }}
spec:
  replicas: 3
  selector:
    matchLabels:
      app: {{ .Values.appName }}
      version: {{ .Values.deploymentColor }}
  template:
    metadata:
      labels:
        app: {{ .Values.appName }}
        version: {{ .Values.deploymentColor }}
    spec:
      containers:
        - name: {{ .Values.appName }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          ports:
            - containerPort: 80

Key Point: The deployment uses a color-based version label (version: blue or version: green) to separate the environments.

Step 3: Configuring the Kubernetes Service

In service.yaml:

apiVersion: v1
kind: Service
metadata:
  name: {{ .Values.service.name }}
spec:
  selector:
    app: {{ .Values.appName }}
    version: {{ .Values.deploymentColor }}
  ports:
    - protocol: TCP
      port: {{ .Values.service.port }}
      targetPort: 80

Key Point: The Service selector controls which color (version) is live.

Step 4: Switching Traffic

To switch from Blue to Green:

  1. Deploy the Green version:

     helm upgrade my-app ./my-app --set deploymentColor=green --set image.tag=2.0.0

  2. Update the Service selector:

     helm upgrade my-app ./my-app --set deploymentColor=green

    The Service now points to Green pods.

  3. Test the Green environment. If successful, the Green deployment is now live.

Step 5: Rollback Strategies

If something goes wrong:

  • Simply update the Service selector back to Blue:

      helm upgrade my-app ./my-app --set deploymentColor=blue

  • Alternatively, if you used Ingress routing, you can switch back by updating the Ingress backend.

Rollback is fast because the Blue pods are still running.

6. Advanced Tips: Automation and CI/CD Integration

Automate with Helmfile or ArgoCD

Instead of manually running Helm commands, you can:

  • Use Helmfile to manage multi-environment deployments declaratively.

  • Use ArgoCD for GitOps-driven deployment with visual controls for traffic switching.

CI/CD Example: GitHub Actions

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Code
        uses: actions/checkout@v3

      - name: Helm Upgrade to Green
        run: helm upgrade my-app ./my-app --set deploymentColor=green --set image.tag=${{ github.sha }}

      - name: Run Integration Tests
        run: curl -f http://my-app-service-url/health

      - name: Switch Traffic
        run: helm upgrade my-app ./my-app --set deploymentColor=green

7. Common Pitfalls and How to Avoid Them

ProblemSolution
Service disruption during switchEnsure pods are fully ready using readiness probes before switching traffic.
Helm version confusionKeep strict Helm release naming conventions to differentiate blue and green versions.
Stale deployments piling upAutomate the cleanup of old environments post-successful deployments.
Uncontrolled rolloutUse manual approval gates in your CI/CD pipeline before switching traffic.
Service cachingConfigure load balancers to avoid sticky sessions if your application isn't session-aware.

8. Final Thoughts

Blue-green deployment is a powerful strategy that Kubernetes and Helm can execute with grace, giving you predictable, low-risk, and near-zero-downtime deployments. It’s especially valuable in environments where customer experience and availability are non-negotiable.

By combining the dynamic routing capabilities of Kubernetes Services and the flexible templating of Helm charts, you can:

  • Seamlessly switch between application versions

  • Perform real-time verifications

  • Rollback instantly if needed

  • Automate the entire process in your CI/CD pipelines

For DevOps teams, this approach simplifies complex deployments and strengthens system reliability.

Key Takeaways:

  • Helm enables parameterized blue-green deployments with minimal manual adjustments.

  • Kubernetes Services act as the switch that controls live traffic.

  • Careful label management is essential for clean version separation.

  • Automation enhances safety, especially with integrated test gates.

If you’re looking to take your Kubernetes deployment strategies to the next level, blue-green deployment with Helm should absolutely be in your toolbox.

0
Subscribe to my newsletter

Read articles from John Abioye directly inside your inbox. Subscribe to the newsletter, and don't miss out.

Helmhelm chartKuberneteskubernetes architecture#kubernetes #container

Written by

John Abioye
John Abioye