Demo Blue Green Deployment

Let’s explore how Argo Rollouts implements a Blue-Green deployment pattern to switch production traffic between application versions atomically.

A presentation slide with a blue-green gradient background and a centered white title reading "Argo Rollouts - Blue-Green Deployment." A small "© Copyright KodeKloud" appears in the bottom-left corner.

What makes Blue-Green different from Canary:

Argo Rollouts still manages ReplicaSets for each version, but in Blue-Green the rollout controller swaps Service resources to redirect traffic from the old ReplicaSet (blue) to the new ReplicaSet (green).
The Rollout spec references two Services (in the same namespace):
- activeService (required): receives production traffic and points to the currently active ReplicaSet (the stable version).
- previewService (optional): points to the new ReplicaSet so you can validate it without exposing it to production.

Key behaviors:

When autoPromotionEnabled is false, promotion to active must be done manually (via CLI or UI).
When promotion happens, the controller updates the activeService to point at the new ReplicaSet, switching production traffic atomically.

Table: Blue-Green rollout services

Service role	Purpose	Example name
activeService	Routes production traffic to the active ReplicaSet	`highway-bluegreen-active`
previewService	Optional: routes non-production/preview traffic to new ReplicaSet	`highway-bluegreen-preview`

Minimal Rollout spec that demonstrates the blueGreen strategy and both services:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: rollout-bluegreen
spec:
  replicas: 2
  revisionHistoryLimit: 2
  selector:
    matchLabels:
      app: rollout-bluegreen
  template:
    metadata:
      labels:
        app: rollout-bluegreen
    spec:
      containers:
      - name: rollouts-demo
        image: argoproj/rollouts-demo:blue
        imagePullPolicy: Always
        ports:
        - containerPort: 8080
  strategy:
    blueGreen:
      # activeService is mandatory; the rollout controller updates this service
      # to point to the ReplicaSet deemed "active" after promotion.
      activeService: rollout-bluegreen-active
      # previewService is optional; it is updated to point to the new ReplicaSet
      # while production (activeService) continues to serve the old ReplicaSet.
      previewService: rollout-bluegreen-preview
      # autoPromotionEnabled:false disables automated promotion. With this set to
      # false you must manually promote the new ReplicaSet (via CLI or UI).
      autoPromotionEnabled: false

Concrete example — highway animation application

Namespace: blue-green
10 replicas of the application for each version (blue or green)
Two Services referenced in the strategy: highway-bluegreen-active and highway-bluegreen-preview

Rollout manifest:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: highway-bluegreen
  namespace: blue-green
spec:
  replicas: 10
  revisionHistoryLimit: 2
  selector:
    matchLabels:
      app: highway-bluegreen
  template:
    metadata:
      labels:
        app: highway-bluegreen
    spec:
      containers:
      - name: highway-bluegreen
        image: siddharth67/highway-animation:blue
        ports:
        - containerPort: 3000
        env:
        - name: POD_COUNT
          value: "10"
  strategy:
    blueGreen:
      activeService: highway-bluegreen-active
      previewService: highway-bluegreen-preview
      autoPromotionEnabled: false

Service manifests (two services with identical selectors and ports; only the names differ):

apiVersion: v1
kind: Service
metadata:
  name: highway-bluegreen-active
  namespace: blue-green
spec:
  selector:
    app: highway-bluegreen
  ports:
    - protocol: TCP
      port: 3000
      targetPort: 3000
  type: NodePort
---
apiVersion: v1
kind: Service
metadata:
  name: highway-bluegreen-preview
  namespace: blue-green
spec:
  selector:
    app: highway-bluegreen
  ports:
    - protocol: TCP
      port: 3000
      targetPort: 3000
  type: NodePort

The preview service is optional. When present, it provides a non-production endpoint for the new ReplicaSet so you can validate the new version before switching production traffic to it.

Deployment steps

Create the namespace:

kubectl create ns blue-green

Apply the manifests:

kubectl apply -f .
# or explicitly
kubectl apply -f rollout.yml -n blue-green
kubectl apply -f service.yml -n blue-green

Verify resources:

kubectl -n blue-green get all

Expected sample output (consolidated):

10 pods for the current ReplicaSet
Two services with NodePort mappings
A ReplicaSet that reflects the current revision

NAME                                        READY   STATUS    RESTARTS   AGE
pod/highway-bluegreen-674c49d44d-2xp7m     1/1     Running   0          2m
...
pod/highway-bluegreen-674c49d44d-zf58b     1/1     Running   0          2m

NAME                                 TYPE       CLUSTER-IP       EXTERNAL-IP   PORT(S)             AGE
service/highway-bluegreen-active     NodePort   10.110.42.78     <none>        3000:30920/TCP      2m
service/highway-bluegreen-preview    NodePort   10.110.199.112   <none>        3000:31981/TCP      2m

NAME                                     DESIRED   CURRENT   READY   AGE
replicaset.apps/highway-bluegreen-674c49d44d   10        10        10      2m

Note: Because both services initially use the same selector, both will route to the same pods (blue). Production traffic is served through the activeService. Introducing a new version (green)

Update the Rollout manifest image to the green tag, for example:

# change this in the Rollout template spec
image: siddharth67/highway-animation:green

Apply the updated rollout manifest:

kubectl apply -f rollout.yml -n blue-green

Behavior:

With autoPromotionEnabled: false, Argo Rollouts creates a new ReplicaSet for the green version and updates the previewService to select the new ReplicaSet.
Both ReplicaSets run in parallel (10 blue + 10 green), so you’ll see ~20 pods while both versions are active.
activeService continues to serve the blue pods (production). previewService points to the green pods for validation.

Verify pods:

kubectl -n blue-green get pods

Promote the new version to production

Use the Argo Rollouts UI, or the kubectl plugin:

kubectl argo rollouts promote highway-bluegreen -n blue-green

After promotion, the rollout controller updates the activeService to point at the green ReplicaSet. Production traffic is now routed to the green pods. Rollback

If the green version has issues, you can rollback to a previous revision using the Argo Rollouts UI or CLI. The controller keeps revision history (controlled by revisionHistoryLimit), which enables safe rollbacks.

If autoPromotionEnabled is false, the new ReplicaSet will not receive production traffic until you manually promote it. Make sure to validate the previewService before promotion, and coordinate promotion with your release process.

Observability

The Argo Rollouts UI displays the strategy (blue-green), revisions, and which revision is active, preview, or stable.
Unlike Canary releases, Blue-Green does not show incremental traffic weights; traffic is switched atomically by updating the activeService.

Quick reference: common commands

Task	Command
Create namespace	`kubectl create ns blue-green`
Apply manifests	`kubectl apply -f rollout.yml -n blue-green`
List resources	`kubectl -n blue-green get all`
Promote rollout	`kubectl argo rollouts promote <rollout-name> -n <ns>`
Get rollout status	`kubectl argo rollouts get rollout <rollout-name> -n <ns>`

Summary

Blue-Green with Argo Rollouts uses two services (active and optional preview) to switch traffic atomically between ReplicaSets.
Use previewService to validate new versions without impacting production.
Set autoPromotionEnabled to false to require manual promotion for safer releases.
Use the Argo Rollouts UI or kubectl plugin for promotion, observation, and rollback.

Links and References

Argo Rollouts documentation: https://argoproj.github.io/argo-rollouts/
Kubernetes Services: https://kubernetes.io/docs/concepts/services-networking/service/
kubectl-argo-rollouts plugin: https://argoproj.github.io/argo-rollouts/installation/

Watch Video