Create a Kubernetes Blue Green deployment
This topic will walk you through creating a Blue Green deployment in Harness for a Kubernetes Deployment workload.
For information on Blue Green deployments, see Deployment Concepts and Strategies.
Harness Canary and Blue Green strategies only support Kubernetes Deployment workloads. The Rolling strategy supports all other workloads, except Jobs. The Apply Step can deploy any workloads or objects.
Before you begin
What workloads can I deploy?
See What Can I Deploy in Kubernetes?.
Harness Blue Green deployments
Here's a quick summary of how Harness performs Blue Green deployments.
You can deploy one or two Kubernetes services as part of your Harness Blue Green deployment.
Single Kubernetes service
Only one Kubernetes service is mandatory and it doesn’t need any annotations to establish if it is the primary (production) service.
Here is a very generic service example that uses a values.yaml file for its values:
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}}
This file and sample deployment and values.yaml files are publicly available on the Harness Docs repo.
Note that there are no annotations to indicate that it is the primary service.
If you are using only one service in your manifest, Harness will create a duplicate of that service and name it with the -stage
suffix.
Two Kubernetes services
If you have more than one service, Harness does not automatically know which is the primary service unless you add the annotations like this:
- The primary service uses this annotation:
annotations: harness.io/primary-service: "true"
. You must have this annotation added in your manifest. - The stage service uses this annotation:
annotations: harness.io/stage-service: "true"
. You must have this annotation added in your manifest.
Here's an example:
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
If you use two services, please annotate them as described.
Let's look at the deployment process using two Kubernetes services:
- First deployment:
- Harness creates two services (primary and stage) and one pod set for the app.
- The primary service uses this annotation:
annotations: harness.io/primary-service: "true"
. You must have this annotation added in your manifest. - The stage service uses this annotation:
annotations: harness.io/stage-service: "true"
. You must have this annotation added in your manifest. - The pod set is given an annotation of
harness.io/color: blue
. - Harness points the stage service at the pod set and verifies that the set reached steady state.
- Harness swaps the primary service to pod set. Production traffic now flows to the app.
- Second deployment (new version of the same app):
- Harness creates a new pod set for new app version. The pod set is given the annotation
harness.io/color: green
. - Harness points the stage service at new pod set (with new app version) and verifies that the set reached steady state.
- Harness swaps the primary service to new pod set, stage service to old pod set.
- Harness creates a new pod set for new app version. The pod set is given the annotation
- Third deployment:
- Harness deploy new app version to the pod set not using the primary service.
- Harness points the stage service at new pod set (with new app version) and verifies that the set reached steady state.
- Harness swaps the primary service to new pod set, stage service to old pod set.
Visual summary
Here's a video walking through a Blue-Green deployment. It's 10 minutes long but it covers set up and two deployments.
Define the service and infrastructure
Create your CD Pipeline stage.
To set up your Service and Infrastructure in the stage, follow the steps in these topics:
Once the Service and Infrastructure are set up, you can add the execution steps.
Add the execution steps
In the stage's Execution, click Add Step, and select the Blue Green strategy.
Harness adds all the steps you need to perform the Blue Green strategy:
Additionally, you can add a Blue Green Stage Scale Down step to scale down the last successful stage environment created during a Blue Green deployment.
This functionality helps you efficiently manage your resources. You can configure the scale down step within the same stage or a different stage, based on your requirement.
Here's a quick video walking through a simple Blue Green Stage Scale Down step:
During scale down, the HorizontalPodAutoscaler
and PodDisruptionBudget
resources are removed, and the Deployments, StatefulSets, DaemonSets, and Deployment Configs resources are scaled down. Make sure that the infrastructure definition of these resources and the Blue Green service are the same. This is necessary as Harness identifies resources from the release history, which is mapped to a release name. If you configure a different infrastructure definition, it might lead to scaling down important resources.
That's it. Harness will deploy the artifact using the stage service initially, and swap traffic to the primary service.
Let's look at the default settings for the Stage Deployment step.
Stage deployment step
The Stage Deployment step is added automatically when you apply the Blue Green strategy.
Click the Stage Deployment step. The step simply includes a name, timeout, and Skip Dry Run options.
Skip Dry Run
By default, Harness uses the --dry-run
flag on the kubectl apply
command during the Initialize step of this command, which prints the object that would be sent to the cluster without actually sending it. If the Skip Dry Run option is selected, Harness will not use the --dry-run
flag. The first time you deploy, the Stage Deployment step creates two Kubernetes services, a new pod set, and deploys your app to the pod set.
Skip Deployment if Using the Manifest Used in a Previous Deployment
When running the Stage Deployment step, if you select this option, Harness renders the manifests and compares them with the last deployed manifests to see if there are any changes. If there are no changes in the manifests used in the step and the previous deployment, Harness skips the step and progresses to the subsequent steps in the pipeline. This ensures that no routes or labels associated with the primary or stage (Blue or Green) are manipulated when no manifest changes are present.
When you look at the Stage Deployment step in Harness Deployments, you will see the following log sections.
Fetch Files
Harness pulls the manifests and values.yaml from your repo.
Initialize
The Initialize stage initializes the two Kubernetes services and deployment object, validating their YAML.
Prepare
Typically, in a Prepare section, you can see that each release of the resources is versioned. This is used in case Harness needs to rollback to a previous version.
In the case of Blue Green, the resources are not versioned because a Blue Green deployment uses rapid rollback: network traffic is simply routed back to the original instances.
You do not need to redeploy previous versions of the service/artifact and the instances that comprised their environment.
The Prepare section shows that Harness has prepared two services, identified the deployment as blue, and pointed the stage service (blue) at the blue pod set for the deployment:
This example uses one Kubernetes service, hence the use of the -stage
suffix.
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.
Apply
The Apply section applies a services and deployment from the Prepare section. It uses a combination of all of the manifests in the Service Manifests section as one file using kubectl apply
.
kubectl --kubeconfig=config apply --filename=manifests.yaml --record
service/bgdemo-svc created
deployment.apps/bgdemo-blue created
service/bgdemo-svc-stage created
Done.
Wait for Steady State
The Wait for Steady State section shows Harness confirming the rollout and that the pods have reached steady state.
Next, the Swap Primary with Stage step will swap the primary and stage services to route primary network traffic to the pod set for the app.
If this were the second deployment, Harness would also swap the stage service to the pod set for the old app version.