Spin up Version 2 and scale the pods

With Version 1 up and running in nine pods, it is time to get one pod running Version 2.

What you need

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

What you will learn

• How to spin up Version 2

• How to patch the deployment

• How to 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-v1 and gethostname-v2. Run the commands now:

If you are using Bash:

oc patch dc/gethostname-v1 -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"}}'

If you are using PowerShell:

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

Conclusion

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