Spin up Version 2 and scale the pods

The Canary deployment model allows you to run two versions — a current version and a new version — side-by-side. You begin by routing a small percentage of traffic to the new version, then increase the percentage for traffic toward the new version while decreasing traffic to the current version. You continue this until either: The new version is receiving 100 percent of the traffic, or the new version is defective and all traffic is directed to the current version. For this lesson, with Version 1 up and running in nine pods, it is time to get one pod running Version 2.

Prerequisites

• A Developer Sandbox for Red Hat OpenShift (Developer Sandbox) account
• The OpenShift command-line interface (CLI) 

In this lesson, you will learn:

• Spin up Version 2
• Patch the deployment
• Change pod counts

Spin up Version 2 of gethostname

Run the following command to get a pod running Version 2 of our microservice: 

oc new-app quay.io/rhdevelopers/gethostname:v2 --name gethostname-v2 --as-deployment-config=true -l app=gethostname

Patch both versions to use same route

Now it's time to see the Canary Deployment in action. The first two of the following commands will patch the deployment configuration objects for Version 1 and Version 2 so that they have the label svc:gethostname. The third command will change the route that you created earlier to search for the label svc:gethostname-v1 regardless of the associated service.

In other words, our route will access both microservices: gethostname and gethostname-v2. Run the commands now:

oc patch dc/gethostname -p '{"spec":{"template":{"metadata":{"labels":{"svc":"gethostname"}}}}}'

oc patch dc/gethostname-v2 -p '{"spec":{"template":{"metadata":{"labels":{"svc":"gethostname"}}}}}'

oc patch svc/gethostname -p '{"spec":{"selector":{"svc":"gethostname","app": null, "deploymentconfig": null}, "sessionAffinity":"ClientIP"}}'

Observe results in the cURL command loop  

After running the commands in the previous section, return to the cURL command loop window to observe the results.

In the next section, to fully appreciate the impact of the commands you are running, run the cURL command in one visible window while running the commands in another window. This will allow you to see the results as you run the commands.

Change pod counts and observe results

Run the following two commands and observe the results:

oc scale --replicas=5 dc/gethostname-v2

oc scale --replicas=5 dc/gethostname

You will see the distribution become even between the two versions.

Shut down Version 1

Run the following command to shut down Version 1 and observe the results. All of the requests are now being serviced by Version 2: 

oc scale --replicas=0 dc/gethostname

Summary

This activity demonstrates the principle of the Canary Deployment by scaling pods up and down in an OpenShift cluster. While the concept is the same, a better and more enterprise-ready solution is to use Istio Service Mesh. With Istio, you won’t need to scale the pod counts. Instead, you can set the percentage of traffic to each version specifically.

Read more about it: Red Hat Developer has a wealth of material related to Service Mesh.

More resources

• How to prevent computer overload with remote kind clusters
• A developer's guide to using OpenShift with Kubernetes
• How to easily generate Helm charts using Dekorate
• How Kubernetes storage improves developer agility
• Tools for the Developer Sandbox
• Create AWS resources with Kubernetes and Operators
• How to use Operators with AWS Controllers for Kubernetes
• Containers without Docker | DevNation Tech Talk