> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/kubernetes-executions/create-a-kubernetes-blue-green-deployment.md).

# Create a Kubernetes Blue Green deployment

This guide shows you how to create a Blue Green deployment for Kubernetes workloads. Blue Green deployments maintain two identical environments (blue and green) and switch traffic between them, enabling rapid rollback by routing traffic back to the previous environment without redeploying.

For conceptual information on Blue Green deployments, go to [Deployment Concepts and Strategies](/continuous-delivery/use-continuous-delivery/manage-deployments/deployment-concepts.md) to understand the strategy. For a comparison across platforms, go to [Blue-Green Deployment Across Platforms](/continuous-delivery/use-continuous-delivery/manage-deployments/blue-green-across-platforms.md) to see platform-specific differences.

***

### Before you begin <a href="#before-you-begin" id="before-you-begin"></a>

* **Harness account with Continuous Delivery enabled:** You need access to **Continuous Delivery** in Harness. For how to access or create a Harness account, go to [Getting started with Harness Platform](/harness-ai/new-to-harness-platform/get-started.md) to set up your account.

  <div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p><strong>CONTACT HARNESS SUPPORT:</strong></p><p>If Continuous Delivery does not appear, go to <a href="/pages/fvQQvQYBT7VqrZOlJj6k">Get started with CD</a> to review requirements or contact your account administrator or <a href="mailto:support@harness.io">Harness Support</a>.</p></div>
* **Kubernetes cluster:** You need a target Kubernetes cluster where you can deploy workloads. Go to [Define Your Kubernetes Target Infrastructure](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/define-your-kubernetes-target-infrastructure.md) to configure your cluster connection.
* **Kubernetes manifests:** You need Deployment manifests and Service manifests for your application. Go to [Add Kubernetes Manifests](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/cd-kubernetes-category/define-kubernetes-manifests.md) to add manifests to your service.
* **Pipeline permissions:** You need **View**, **Create/Edit**, and **Execute** for [Pipelines](/harness-ai/use-harness-platform/platform-access-control/permissions-reference.md#pipelines). To get these, an administrator must assign you a role that includes them. Go to [RBAC in Harness](/harness-ai/use-harness-platform/platform-access-control.md) to understand roles and go to [Manage roles](/harness-ai/use-harness-platform/platform-access-control/add-manage-roles.md) to learn how to assign them.

{% hint style="warning" %}
**SUPPORTED WORKLOADS**

Harness Blue Green strategy supports Kubernetes Deployment workloads only. Only one deployment workload is supported per service. Having multiple workloads in service manifests results in deployment failure. For other workload types, go to [What Can I Deploy in Kubernetes?](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/cd-k8s-ref/what-can-i-deploy-in-kubernetes.md) to review supported options.
{% endhint %}

***

### Configure service manifests for Blue Green <a href="#configure-service-manifests-for-blue-green" id="configure-service-manifests-for-blue-green"></a>

Before creating the pipeline, configure your Kubernetes service manifests with the annotations Harness uses to identify primary and stage environments.

#### Single service configuration <a href="#single-service-configuration" id="single-service-configuration"></a>

When you use only one Kubernetes service in your manifests, Harness automatically creates a duplicate stage service with the `-stage` suffix. No annotations are required.

<details>

<summary>Single Kubernetes service example</summary>

```yaml
apiVersion: v1
kind: Service
metadata:
  name: {{.Values.name}}-svc
spec:
  type: {{.Values.serviceType}}
  ports:
  - port: {{.Values.servicePort}}
    targetPort: {{.Values.serviceTargetPort}}
    protocol: TCP
  selector:
    app: {{.Values.name}}
```

</details>

This service does not include any `harness.io` annotations because Harness automatically identifies it as the primary service and creates a corresponding stage service.

Sample deployment and values.yaml files are publicly available on the [Harness Docs repo](https://github.com/wings-software/harness-docs/tree/main/k8s-bluegreen).

#### Two services configuration <a href="#two-services-configuration" id="two-services-configuration"></a>

When you use two services in your manifests, annotate them so Harness can identify which is primary and which is stage.

Add these annotations:

* **Primary service:** `harness.io/primary-service: "true"`
* **Stage service:** `harness.io/stage-service: "true"`

<details>

<summary>Two Kubernetes services example</summary>

```yaml
apiVersion: v1
kind: Service
metadata:
  name: test-deploy-svc-1
  annotations:
    harness.io/primary-service: "true"
spec:
  type: ClusterIP
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP
  selector:
    app: nginx
---
apiVersion: v1
kind: Service
metadata:
  name: test-deploy-svc-2
  annotations:
    harness.io/stage-service: "true"
spec:
  type: ClusterIP
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP
  selector:
    app: nginx
```

</details>

***

### Understand the Blue Green deployment flow <a href="#understand-the-blue-green-deployment-flow" id="understand-the-blue-green-deployment-flow"></a>

Harness manages Blue Green deployments by maintaining two pod sets (blue and green) and swapping service selectors to route traffic. The deployment flow differs between first deployment and subsequent deployments.

#### First deployment <a href="#first-deployment" id="first-deployment"></a>

1. Harness creates two services (primary and stage) and one pod set for the application
2. The pod set receives the annotation `harness.io/color: blue`
3. Harness points the stage service at the blue pod set and verifies steady state
4. Harness swaps the primary service to the blue pod set, routing production traffic to the application

#### Second deployment (new version) <a href="#second-deployment-new-version" id="second-deployment-new-version"></a>

1. Harness creates a new pod set for the new application version with annotation `harness.io/color: green`
2. Harness points the stage service at the green pod set and verifies steady state
3. Harness swaps the primary service to the green pod set and the stage service to the blue pod set

#### Third and subsequent deployments <a href="#third-and-subsequent-deployments" id="third-and-subsequent-deployments"></a>

1. Harness deploys the new app version to the pod set not currently serving production traffic
2. Harness points the stage service at the new pod set and verifies steady state
3. Harness swaps the primary service to the new pod set and the stage service to the old pod set

***

### Create the deployment pipeline <a href="#create-the-deployment-pipeline" id="create-the-deployment-pipeline"></a>

The following steps configure a CD pipeline with the Blue Green deployment strategy.

#### Step 1: Create the pipeline stage <a href="#step-1-create-the-pipeline-stage" id="step-1-create-the-pipeline-stage"></a>

In the Harness project, create a CD pipeline and add a deployment stage. On the **Service** tab, select or create a service that includes your Kubernetes manifests.

On the **Infrastructure** tab, select or create an infrastructure definition that points to your target Kubernetes cluster. Go to [Define Your Kubernetes Target Infrastructure](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/define-your-kubernetes-target-infrastructure.md) to configure the infrastructure if needed.

#### Step 2: Add Blue Green execution steps <a href="#step-2-add-blue-green-execution-steps" id="step-2-add-blue-green-execution-steps"></a>

In the stage **Execution** tab, select **Add Step** and choose the **Blue Green** deployment strategy.

Harness automatically adds the required steps:

<figure><img src="/files/xJTOurMPUhqvwIor5iJb" alt=""><figcaption><p>Click to view full size image</p></figcaption></figure>

The Blue Green strategy includes these steps:

* **Stage Deployment:** Deploys the new version to the stage environment
* **Swap Primary with Stage:** Routes production traffic to the new version

You can add optional steps:

* **Verification steps:** Add between Stage Deployment and Swap steps to validate the stage environment before routing traffic
* **Blue Green Stage Scale Down:** Scales down the previous stage environment to conserve resources
* **Blue Green Stage Scale Up:** Restores a previously scaled-down environment

#### Step 3: Configure Stage Deployment step <a href="#step-3-configure-stage-deployment-step" id="step-3-configure-stage-deployment-step"></a>

The **Stage Deployment** step deploys your application to the stage environment and verifies it reaches steady state.

Select the **Stage Deployment** step to configure these options:

**Skip Dry Run:** By default, Harness uses the `--dry-run` flag on `kubectl apply` during initialization to validate manifests without applying them. Enable this option to skip the dry run and apply manifests immediately.

**Skip Deployment if Using the Manifest Used in a Previous Deployment:** Enable this option to have Harness compare rendered manifests with the last deployment. If no changes are detected, Harness skips the step and progresses to subsequent steps. This prevents manipulation of routes or labels when manifests are unchanged.

#### Step 4: Configure Swap Primary with Stage step <a href="#step-4-configure-swap-primary-with-stage-step" id="step-4-configure-swap-primary-with-stage-step"></a>

The **Swap Primary with Stage** step switches the primary and stage service selectors to route production traffic to the new version.

After the swap:

* The primary service points to the new version (blue or green, depending on the deployment)
* The stage service points to the previous version

{% hint style="info" %}
**POST-SWAP VALIDATION**

This step does not perform post-swap health checks. Harness assumes the stage deployment was successful and the service is ready for traffic. To verify the new primary environment after the swap, add a **Verify**, **Shell Script**, or **HTTP** step after the Swap step to check pod readiness or hit health endpoints.
{% endhint %}

***

### Optional: Add Blue Green Stage Scale Down step <a href="#optional-add-blue-green-stage-scale-down-step" id="optional-add-blue-green-stage-scale-down-step"></a>

After routing production traffic to the new version, you can scale down the inactive environment to conserve resources.

Select **Add Step** and choose **Blue Green Stage Scale Down**. This step scales down the last successful stage environment.

<figure><img src="/files/APgsuFAA73Gn9J51fMyh" alt=""><figcaption><p>Click to view full size image</p></figcaption></figure>

The Scale Down step performs these operations:

* Removes HorizontalPodAutoscaler and PodDisruptionBudget resources
* Deletes Deployments, DeploymentConfigs, and StatefulSets
* Scales down DaemonSets to zero replicas

{% hint style="info" %}
**BEHAVIOR CHANGE**

Previously, Harness scaled down deployments by setting replicas to 0. This caused issues when HPA was configured because the replicas field remained 0 on subsequent deployments. Harness now deletes these resources instead of scaling them to 0. The Scale Up step can restore deleted workloads (with declarative rollback) using stored manifests and replica counts. Note that HPA and PDB resources are permanently removed and require redeployment to restore.
{% endhint %}

You can configure the Scale Down step in the same stage as the deployment or in a different stage, based on when you want to scale down resources.

{% hint style="warning" %}
**RELEASE NAME REQUIREMENT**

When deploying multiple services to the same namespace using Blue Green, ensure each service has a unique release name. If multiple services share the same release name in the same namespace, the Scale Down step may incorrectly identify which deployment to scale down.
{% endhint %}

The Scale Down step identifies resources from the release history, which is mapped to a release name. Ensure the infrastructure definition for the Scale Down step matches the infrastructure definition used for the Blue Green deployment.

#### When to use Scale Down <a href="#when-to-use-scale-down" id="when-to-use-scale-down"></a>

Use Scale Down when you want to conserve cluster resources after a successful deployment and you are confident you will not need to roll back to the previous version. Blue Green deployments enable rapid rollback by routing traffic back to the previous pods, but this requires keeping the previous environment running.

{% hint style="info" %}
**REVERSIBILITY**

The Scale Down step removes or deletes workloads to conserve resources. You can restore scaled-down environments using the **Blue Green Stage Scale Up** step. The Scale Up step can restore workloads that were scaled to zero replicas and deleted workloads (with declarative rollback). However, **HPA and PDB resources are permanently removed** during Scale Down and are not recreated by Scale Up. Scale Up can only restore environments if the release history contains the captured state from a prior Scale Down operation. If you delete the release history or perform cleanup that removes historical data, Scale Up cannot restore the environment.
{% endhint %}

***

### Optional: Add Blue Green Stage Scale Up step <a href="#optional-add-blue-green-stage-scale-up-step" id="optional-add-blue-green-stage-scale-up-step"></a>

After scaling down a stage environment, you can restore it using the **Blue Green Stage Scale Up** step. This step reverses the Scale Down operation.

{% hint style="info" %}
**FEATURE FLAG**

This feature is behind the feature flag `CDS_K8S_BG_STAGE_SCALE_UP`. Contact [Harness Support](mailto:support@harness.io) to enable the feature.
{% endhint %}

#### How Scale Up works <a href="#how-scale-up-works" id="how-scale-up-works"></a>

When you scale down a stage environment, Harness captures and stores the original replica counts and resource configurations. The Scale Up step uses this information to restore the environment.

The Scale Up step performs these operations:

1. Checks the release history for workloads that were scaled down in a previous Blue Green Stage Scale Down step
2. Scales workloads back to their original replica counts (works for both scaled-to-zero and deleted workloads with declarative rollback)
3. Optionally waits for scaled-up workloads to reach steady state

{% hint style="warning" %}
**LIMITATIONS**

* **Deleted workloads:** Can only be recreated with declarative rollback. With imperative rollback, recreation is only possible if the workload was scaled to zero (not deleted).
* **HPA and PDB:** These resources are deleted during Scale Down and are **not** recreated during Scale Up. You must redeploy to restore HPA and PDB resources.
  {% endhint %}

#### When to use Scale Up <a href="#when-to-use-scale-up" id="when-to-use-scale-up"></a>

Use the Scale Up step when you need to restore a scaled-down environment in these scenarios:

* **Preparing for rollback:** Scale up the previous version before performing a rollback to ensure pods are running and healthy
* **Re-validation:** Bring the inactive environment back online to re-test or validate the previous version
* **Gradual resource management:** Scale down during low-traffic periods and scale up when you need capacity
* **Failed deployments:** Restore the stage environment after a deployment failure to maintain both environments for troubleshooting

#### Configure the Scale Up step <a href="#configure-the-scale-up-step" id="configure-the-scale-up-step"></a>

Select **Add Step** and choose **Blue Green Stage Scale Up**. Configure these options:

<figure><img src="/files/cZFgSRXHOAiUELLLJG2G" alt=""><figcaption><p>Click to view full size image</p></figcaption></figure>

**Replica Count Mode:** Choose how to determine the replica count when scaling up:

* **Auto (use original count)** (recommended): Harness automatically restores workloads to the replica counts captured before the Scale Down operation. This ensures the environment is restored exactly as it was.
* **Custom:** Specify a fixed replica count to use when scaling up all workloads, overriding the captured values.

**Skip Steady State Check:** When enabled, Harness scales up the workloads but does not wait for them to reach steady state before proceeding. Use this when you want to scale up in the background and continue the pipeline without waiting.

#### Scale Up behavior <a href="#scale-up-behavior" id="scale-up-behavior"></a>

The Scale Up step handles different scenarios:

* **No prior scale down:** If no Blue Green Stage Scale Down was performed for the current release, the step skips execution
* **Already scaled up:** If the stage environment is already running with non-zero pods, the step skips those workloads
* **Deleted workloads:** With declarative rollback, the Scale Up step can recreate deleted workloads using manifests and replica counts stored in the release history. With imperative rollback, only scaled-to-zero workloads can be restored (not deleted workloads).

#### Example workflow with Scale Up and Scale Down <a href="#example-workflow-with-scale-up-and-scale-down" id="example-workflow-with-scale-up-and-scale-down"></a>

A common Blue Green deployment workflow:

1. **Stage Deployment:** Deploy new version to stage environment
2. **Verification:** Run tests against stage environment
3. **Swap Primary with Stage:** Route production traffic to new version
4. **Scale Down:** Scale down the old version to conserve resources

Time passes while a new deployment is prepared.

5. **Scale Up:** Before deploying the next version, scale up the current stage environment to ensure rollback capacity
6. **Stage Deployment:** Deploy next version to the now-active stage environment

This workflow ensures you always have a standby environment ready for rapid rollback while minimizing resource usage between deployments.

{% hint style="info" %}
**PREPARE BEFORE ROLLBACK**

Consider using Scale Up before performing rollbacks to ensure the inactive environment is ready to receive traffic. The Blue Green deployment strategy shifts traffic between environments but does not validate whether the active environment is running the correct version. That validation is the responsibility of the **Stage Deployment** step and any verification steps you add.
{% endhint %}

***

### Optional: Configure traffic routing <a href="#optional-configure-traffic-routing" id="optional-configure-traffic-routing"></a>

For advanced traffic management during Blue Green deployments, you can configure gradual traffic shifts between primary and stage services.

Traffic routing allows you to split traffic percentages between the two environments during the swap phase, enabling canary-style validation of the new version before committing full production traffic.

Go to [Traffic Routing Step Reference](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/cd-k8s-ref/traffic-shifting-step.md) to configure traffic routing for Blue Green deployments.

***

### Optional: Use Horizontal Pod Autoscaler (HPA) <a href="#optional-use-horizontal-pod-autoscaler-hpa" id="optional-use-horizontal-pod-autoscaler-hpa"></a>

{% hint style="info" %}
**FEATURE FLAG**

This functionality is behind the feature flag `CDS_SUPPORT_HPA_AND_PDB_NG`. Contact [Harness Support](mailto:support@harness.io) to enable the feature.
{% endhint %}

The Horizontal Pod Autoscaler automatically scales workloads based on CPU utilization or custom metrics. When you use HPA with Blue Green deployments, Harness creates separate HPA resources for the blue and green environments.

#### How Harness handles HPA in Blue Green <a href="#how-harness-handles-hpa-in-blue-green" id="how-harness-handles-hpa-in-blue-green"></a>

When the feature flag is enabled, Harness automatically creates blue and green HPA configurations that reference the blue and green deployments. The HPA resource name includes the color suffix (for example, `test-hpa-blue` or `test-hpa-green`).

<details>

<summary>HPA example with Blue Green deployments</summary>

Original HPA manifest:

```yaml
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx-deployment
  minReplicas: 1
  maxReplicas: 10
  targetCPUUtilizationPercentage: 50
```

Harness creates a blue HPA:

```yaml
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: test-hpa-blue
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: test-deployment-blue
  minReplicas: 1
  maxReplicas: 10
  targetCPUUtilizationPercentage: 50
```

</details>

#### Using HPA without the feature flag <a href="#using-hpa-without-the-feature-flag" id="using-hpa-without-the-feature-flag"></a>

If you use HPA without enabling the feature flag, create separate blue and green HPA configurations manually that point at your deployments.

<details>

<summary>Manual HPA configuration for Blue Green</summary>

Create `templates/hpa-blue.yaml`:

```yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: {{.Values.name}}-blue
  labels:
    harness.io/color: blue
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: {{.Values.name}}-blue
  minReplicas: {{ .Values.autoscaling.minReplicas }}
  maxReplicas: {{ .Values.autoscaling.maxReplicas }}
  metrics:
    {{- toYaml .Values.autoscaling.metrics | indent 4 }}
```

Create `templates/hpa-green.yaml`:

```yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: {{.Values.name}}-green
  labels:
    harness.io/color: green
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: {{.Values.name}}-green
  minReplicas: {{ .Values.autoscaling.minReplicas }}
  maxReplicas: {{ .Values.autoscaling.maxReplicas }}
  metrics:
    {{- toYaml .Values.autoscaling.metrics | indent 4 }}
```

Add scaling configuration to values.yaml:

```yaml
autoscaling:
  minReplicas: 1
  maxReplicas: 5
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 20
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 20
```

</details>

HPA checks metrics every 15 seconds by default and adjusts replicas accordingly. When you use traffic routing with HPA, pods scale automatically as the new version begins receiving heavier loads.

***

### Optional: Use Pod Disruption Budget (PDB) <a href="#optional-use-pod-disruption-budget-pdb" id="optional-use-pod-disruption-budget-pdb"></a>

{% hint style="info" %}
**FEATURE FLAG**

This functionality is behind the feature flag `CDS_SUPPORT_HPA_AND_PDB_NG`. Contact [Harness Support](mailto:support@harness.io) to enable the feature.
{% endhint %}

A Pod Disruption Budget defines the minimum availability threshold during voluntary disruptions. When you use PDB with Blue Green deployments, Harness creates separate PDB resources for the blue and green environments.

#### How Harness handles PDB in Blue Green <a href="#how-harness-handles-pdb-in-blue-green" id="how-harness-handles-pdb-in-blue-green"></a>

When the feature flag is enabled, Harness automatically creates blue and green PDB configurations and adds the `harness.io/color` label to the selectors.

<details>

<summary>PDB example with Blue Green deployments</summary>

Original PDB manifest:

```yaml
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: pdb
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: nginx
```

Harness creates a blue PDB:

```yaml
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: test-pdb-blue
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: test-deployment
      harness.io/color: blue
```

</details>

PDB can have `minAvailable` or `maxUnavailable` fields with absolute or percentage values. The selectors for PDB (`.spec.selector`) must match the controller's `.spec.selector`.

The release history contains the name of the stage PDB resource as part of the resource list, which the Scale Down and Scale Up steps use to manage PDB resources.

***

### Review deployment execution logs <a href="#review-deployment-execution-logs" id="review-deployment-execution-logs"></a>

After you save and run the pipeline, you can review the execution logs to understand what Harness does during each step.

#### Stage Deployment step logs <a href="#stage-deployment-step-logs" id="stage-deployment-step-logs"></a>

**Fetch Files:** Harness pulls manifests and values.yaml from your repository.

**Initialize:** Harness initializes the services and deployment object, validating their YAML.

**Prepare:** Harness prepares two services, identifies the deployment color, and points the stage service at the pod set. In Blue Green deployments, resources are not versioned because rapid rollback works by routing traffic back to the original pods rather than redeploying previous versions.

<details>

<summary>Prepare section example output</summary>

```
Manifests processed. Found following resources:

Kind                Name                                    Versioned
Service             bgdemo-svc                              false
Deployment          bgdemo                                  false

Primary Service is bgdemo-svc

Created Stage service [bgdemo-svc-stage] using Spec from Primary Service [bgdemo-svc]

Primary Service [bgdemo-svc] not found in cluster.

Stage Service [bgdemo-svc-stage] not found in cluster.

Primary Service is at color: green

Stage Service is at color: blue

Cleaning up non primary releases

Current release number is: 1

Versioning resources.

Workload to deploy is: Deployment/bgdemo-blue

Done.
```

</details>

**Apply:** Harness applies services and deployment using `kubectl apply` with all manifests combined.

**Wait for Steady State:** Harness confirms the rollout completed and pods reached steady state.

#### Swap Primary with Stage step logs <a href="#swap-primary-with-stage-step-logs" id="swap-primary-with-stage-step-logs"></a>

The Swap step switches service selectors to route traffic to the new version.

<details>

<summary>Swap step example output</summary>

```
Selectors for Service One : [name:bgdemo-svc]

app: bgdemo

harness.io/color: green

Selectors for Service Two : [name:bgdemo-svc-stage]

app: bgdemo

harness.io/color: blue

Swapping Service Selectors..

Updated Selectors for Service One : [name:bgdemo-svc]

app: bgdemo

harness.io/color: blue

Updated Selectors for Service Two : [name:bgdemo-svc-stage]

app: bgdemo

harness.io/color: green

Done
```

</details>

On subsequent deployments, the swap alternates which color serves production traffic.

***

### Scale down using shell script (alternative method) <a href="#scale-down-using-shell-script-alternative-method" id="scale-down-using-shell-script-alternative-method"></a>

As an alternative to the Blue Green Stage Scale Down step, you can add a [Shell Script step](/continuous-delivery/use-continuous-delivery/cd-building-blocks/cd-steps/utilities/shell-script-step.md) in the post-deployment steps to scale down the stage environment.

Use the pipeline expression `<+pipeline.stages.[stage_name].spec.execution.steps.stageDeployment.output.stageServiceName>` to reference the stage service name dynamically.

<details>

<summary>Shell script scale down example</summary>

```bash
export KUBECONFIG=${HARNESS_KUBE_CONFIG_PATH}
kubectl scale deploy -n <+infra.namespace> $(kubectl get deploy -n <+infra.namespace> -o jsonpath='{.items[?(@.spec.selector.matchLabels.harness\.io/color=="'$(kubectl get service/<+pipeline.stages.nginx.spec.execution.steps.stageDeployment.output.stageServiceName> -n <+infra.namespace> -o jsonpath='{.spec.selector.harness\.io/color}')'")].metadata.name}') --replicas=0
```

Replace `nginx` with your stage name.

</details>

If you use a Delegate installed outside the target cluster, scripts must use `${HARNESS_KUBE_CONFIG_PATH}` to reference the Harness-generated kubeconfig file.

This script example scales to zero replicas, which is suitable for single-deployment namespaces. If you have multiple deployments in the same namespace, add a label or selector specific to the deployment to avoid scaling down all blue deployments in the namespace.

***

### Next steps <a href="#next-steps" id="next-steps"></a>

You have successfully created a Blue Green deployment pipeline for Kubernetes workloads. You can now route production traffic between two identical environments and roll back by switching services.

* [Create a Kubernetes Rolling Deployment](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/kubernetes-executions/create-a-kubernetes-rolling-deployment.md): Use a rolling strategy for workloads that do not require Blue Green
* [Create a Kubernetes Canary Deployment](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/kubernetes-executions/create-a-kubernetes-canary-deployment.md): Deploy incrementally with percentage-based rollout
* [Traffic Routing Step Reference](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/cd-k8s-ref/traffic-shifting-step.md): Configure advanced traffic management for Blue Green deployments