Run the Canary Deployment pattern on Kubernetes

Learning path | 3 resources | 30 mins | Published on March 27, 2024

One of the benefits of using containers to develop applications is the ease and speed with which you can deploy new versions. In this learning path, you will use basic Kubernetes skills to understand and implement the Canary Deployment.

  1. Overview: Run the Canary Deployment pattern on Kubernetes
  2. Create a host service using the Developer Sandbox Page | 15 mins
  3. Spin up Version 2 and scale the pods Page | 15 mins

Page

Spin up Version 2 and scale the pods

Containers Java Kubernetes Microservices Quarkus Service Mesh
Don Schenck
Canary_deploymen

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

What you need

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.

Info alert:For more information about labels, check out the Kubernetes documentation.

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\"}}'

Info alert: The oc patch command allows you to change an existing OpenShift object.

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

Previous resource
Create a host service using the Developer Sandbox