Alauda Container Platform

Application Blue Green Deployment

In the modern world of software development, deploying new versions of applications is a crucial part of the development cycle. However, rolling out updates to production environments can be a risky proposition, as even small issues can result in significant downtime and lost revenue. Blue-Green Deployments are a deployment strategy that mitigates this risk by ensuring that new versions of applications can be deployed with zero downtime.

A Blue-Green Deployment is a deployment strategy where two identical environments, the “blue” environment and the “green” environment, are set up. The blue environment is the production environment, where the live version of the application is currently running, and the green environment is the non-production environment, where new versions of the application are deployed.

When a new version of the application is ready to be deployed, it is deployed to the green environment. Once the new version is deployed and tested, traffic is switched to the green environment, making it the new production environment. The blue environment then becomes the non-production environment, where future versions of the application can be deployed.

Benefits of Blue Green Deployments

  • Zero Downtime: Blue-Green Deployments allow new versions of applications to be deployed with zero downtime, as traffic is switched from the blue environment to the green environment seamlessly.

  • Easy Rollback: If a new version of the application has issues, rolling back to the previous version is easy, as the blue environment is still available.

  • Reduced Risk: By using Blue-Green Deployments, the risk of deploying new versions of applications is reduced significantly. This is because the new version can be deployed and tested in the green environment before traffic is switched over from the blue environment. This allows for thorough testing and reduces the chance of issues arising in production.

  • Increased Reliability: By using Blue-Green Deployments, the reliability of the application is increased. This is because the blue environment is always available, and any issues with the green environment can be quickly identified and resolved without affecting users.

  • Flexibility: Blue-Green Deployments provide flexibility in the deployment process. Multiple versions of an application can be deployed side-by-side, allowing for easy testing and experimentation.

Blue Green Deployment with Argo Rollouts

Argo Rollouts is a Kubernetes controller and set of CRDs which provide advanced deployment capabilities such as blue-green, canary, canary analysis, experimentation, and progressive delivery features to Kubernetes.

Argo Rollouts (optionally) integrates with ingress controllers and service meshes, leveraging their traffic shaping abilities to gradually shift traffic to the new version during an update. Additionally, Rollouts can query and interpret metrics from various providers to verify key KPIs and drive automated promotion or rollback during an update.

With Argo Rollouts, you can automate blue green deployments on Alauda Container Platform (ACP) clusters. The typical process includes:

  1. Defining Rollout resources to manage different application versions.
  2. Configuring Kubernetes services to route traffic between blue (current) and green (new) environments.
  3. Deploying the new version to the green environment.
  4. Verifying and testing the new version.
  5. Promoting the green environment to production by switching traffic.

This approach minimizes downtime and enables controlled, safe deployments.

Key Concepts:

  • Rollout: A custom resource definition (CRD) in Kubernetes that replaces standard Deployment resources, enabling advanced deployment control such as blue-green, canary deployment.

TOC

Prerequisites

  1. ACP (Alauda Container Platform).
  2. Kubernetes Cluster managed by ACP.
  3. Argo Rollouts installed in the cluster.
  4. Argo Rollouts kubectl plugin.
  5. A project to create a namespace in it.
  6. A namespace in the cluster where the application will be deployed.

Procedure

Creating the Deployment

Start by defining the "blue" version of your application. This is the current version that users will access. Create a Kubernetes deployment with the appropriate number of replicas, container image version (e.g., hello:1.23.1), and proper labels such as app=web.

Use the following YAML:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: hello:1.23.1
          ports:
            - containerPort: 80

Explanation of YAML fields:

  • apiVersion: The version of the Kubernetes API used to create the resource.
  • kind: Specifies that this is a Deployment resource.
  • metadata.name: The name of the deployment.
  • spec.replicas: Number of desired pod replicas.
  • spec.selector.matchLabels: Defines how the Deployment finds which pods to manage.
  • template.metadata.labels: Labels applied to pods, used by Services to select them.
  • spec.containers: The containers to run in each pod.
  • containers.name: Name of the container.
  • containers.image: Docker image to run.
  • containers.ports.containerPort: Port exposed by the container.

Apply the configuration using kubectl:

kubectl apply -f deployment.yaml

This sets up the production environment.

Alternative, you could use helm chart to create the deployments and services.

Creating the Blue Service

Create a Kubernetes Service that exposes the blue deployment. This service will forward traffic to the blue pods based on matching labels. Initially, the service selector targets pods labeled with app=web.

apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

Explanation of YAML fields:

  • apiVersion: The version of the Kubernetes API used to create the Service.
  • kind: Specifies this resource is a Service.
  • metadata.name: Name of the Service.
  • spec.selector: Identifies pods to route traffic to, based on labels.
  • ports.protocol: The protocol used (TCP).
  • ports.port: Port exposed by the Service.
  • ports.targetPort: The port on the container to which the traffic is directed.

Apply it using:

kubectl apply -f web-service.yaml

This allows external access to the blue deployment.

Verify the Blue Deployment

Confirm that the blue deployment is running correctly by listing the pods:

kubectl get pods -l app=web

Check that all expected replicas (2) are in the Running state. This ensures the application is ready to serve traffic.

Verify Traffic Routing to Blue

Ensure that the web service is correctly forwarding traffic to the blue deployment. Use this command:

kubectl describe service web | grep Endpoints

The output should list the IP addresses of the blue pods. These are the endpoints receiving traffic.

Creating the Rollout

Next, creating the Rollout resource from Argo Rollouts with BlueGreen strategy.

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: rollout-bluegreen
spec:
  replicas: 2
  revisionHistoryLimit: 2
  selector:
    matchLabels:
      app: web
  workloadRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
    scaleDown: onsuccess
  strategy:
    blueGreen:
      activeService: web
      autoPromotionEnabled: false

Explanation of YAML fields:

  • spec.selector: Label selector for pods. Existing ReplicaSets whose pods are selected by this will be the ones affected by this rollout. It must match the pod template's labels.

  • workloadRef: Specify the workload reference and scale down strategy to apply the rollouts.

    • scaleDown: Specifies if the workload (Deployment) is scaled down after migrating to Rollout. The possible options are:
      • "never": the Deployment is not scaled down.
      • "onsuccess": the Deployment is scaled down after the Rollout becomes healthy.
      • "progressively": as the Rollout is scaled up the Deployment is scaled down. If the Rollout fails the Deployment will be scaled back up.

  • strategy: The rollout strategy, support BlueGreen and Canary strategy.

    • blueGreen: The BlueGreen rollout strategy definition.
      • activeService: Specifies the service to update with the new template hash at time of promotion. This field is mandatory for the blueGreen update strategy.
      • autoPromotionEnabled: autoPromotionEnabled disables automated promotion of the new stack by pausing the rollout immediately before the promotion. If omitted, the default behavior is to promote the new stack as soon as the ReplicaSet are completely ready/available. Rollouts can be resumed using: kubectl argo rollouts promote ROLLOUT

Apply it with:

kubectl apply -f rollout.yaml

This sets up the rollouts for the deployment with BlueGreen strategy.

Verify the Rollouts

After the Rollout was created, the Argo Rollouts will create a new ReplicaSet with same template of the deployment. While the pods of new ReplicaSet is healthy, the deployment is scaled down to 0.

Use the following command to ensure the pods are running properly:

kubectl argo rollouts get rollout rollout-bluegreen
Name:            rollout-bluegreen
Namespace:       default
Status:          ✔ Healthy
Strategy:        BlueGreen
Images:          hello:1.23.1 (stable, active)
Replicas:
  Desired:       2
  Current:       2
  Updated:       2
  Ready:         2
  Available:     2

NAME                                           KIND        STATUS     AGE  INFO
⟳ rollout-bluegreen                            Rollout     ✔ Healthy  95s
└──# revision:1
   └──⧉ rollout-bluegreen-595d4567cc           ReplicaSet  ✔ Healthy  18s  stable,active
      ├──□ rollout-bluegreen-595d4567cc-mc769  Pod         ✔ Running  8s   ready:1/1
      └──□ rollout-bluegreen-595d4567cc-zdc5x  Pod         ✔ Running  8s   ready:1/1

The service web will forward traffic to the pods created by rollouts. Use this command:

kubectl describe service web | grep Endpoints

Preparing Green Deployment

Next, prepare the new version of the application as the green deployment. Update the deployment web with the new image version (e.g., hello:1.23.2).

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: hello:1.23.2
          ports:
            - containerPort: 80

Explanation of YAML fields:

  • Identical to the original deployment, with the exception of:
    • containers.image: Updated to new image version.

Apply it with:

kubectl apply -f deployment.yaml

This sets up the new application version for testing.

The rollouts will create a new Replicaset to manage the green pods, and the traffic still forward to the blue pods. Use the following command to verify:

kubectl argo rollouts get rollout rollout-bluegreen
Name:            rollout-bluegreen
Namespace:       default
Status:          ॥ Paused
Message:         BlueGreenPause
Strategy:        BlueGreen
Images:          hello:1.23.1 (stable, active)
                 hello:1.23.2
Replicas:
  Desired:       2
  Current:       4
  Updated:       2
  Ready:         2
  Available:     2

NAME                                           KIND        STATUS     AGE  INFO
⟳ rollout-bluegreen                            Rollout     ॥ Paused   14m
├──# revision:2
│  └──⧉ rollout-bluegreen-776b688d57           ReplicaSet  ✔ Healthy  24s
│     ├──□ rollout-bluegreen-776b688d57-kxr66  Pod         ✔ Running  23s  ready:1/1
│     └──□ rollout-bluegreen-776b688d57-vv7t7  Pod         ✔ Running  23s  ready:1/1
└──# revision:1
   └──⧉ rollout-bluegreen-595d4567cc           ReplicaSet  ✔ Healthy  12m  stable,active
      ├──□ rollout-bluegreen-595d4567cc-mc769  Pod         ✔ Running  12m  ready:1/1
      └──□ rollout-bluegreen-595d4567cc-zdc5x  Pod         ✔ Running  12m  ready:1/1

Currently, there are 4 pods running, with blue and green version. And the active service is the blue version, the rollout process is paused.

If you use helm chart to deploy the application, use helm tool to upgrade the application to the green version.

Promoting the Rollout to Green

When the green version is ready, promote the rollout to switch traffic to the green pods. Use the following command:

kubectl argo rollouts promote rollout-bluegreen

To Verify if the rollout is completed:

kubectl argo rollouts get rollout rollout-bluegreen
Name:            rollout-bluegreen
Namespace:       default
Status:          ✔ Healthy
Strategy:        BlueGreen
Images:          hello:1.23.2 (stable, active)
Replicas:
  Desired:       2
  Current:       2
  Updated:       2
  Ready:         2
  Available:     2

NAME                                           KIND        STATUS         AGE   INFO
⟳ rollout-bluegreen                            Rollout     ✔ Healthy      3h2m
├──# revision:2
│  └──⧉ rollout-bluegreen-776b688d57           ReplicaSet  ✔ Healthy      168m  stable,active
│     ├──□ rollout-bluegreen-776b688d57-kxr66  Pod         ✔ Running      168m  ready:1/1
│     └──□ rollout-bluegreen-776b688d57-vv7t7  Pod         ✔ Running      168m  ready:1/1
└──# revision:1
   └──⧉ rollout-bluegreen-595d4567cc           ReplicaSet  • ScaledDown   3h1m
      ├──□ rollout-bluegreen-595d4567cc-mc769  Pod         ◌ Terminating  3h    ready:1/1
      └──□ rollout-bluegreen-595d4567cc-zdc5x  Pod         ◌ Terminating  3h    ready:1/1

If the active Images is updated to hello:1.23.2, and the blue ReplicaSet is scaled down to 0, that means the rollout is completed.

View full docs as PDF