#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.