Canaries with Istio and Argo RolloutsStep 12 of 13: Performing a Canary Deployment
All Labs

Performing a Canary Deployment

At this point, we have successfully set up our demo application with Istio and Argo Rollouts. The frontend and API services are now managed by Argo Rollouts, and we can use the canary deployment strategy defined in the Rollout manifests. To perform a canary deployment, we will update the image of the frontend and API services to a new version.

As you might have noticed, the current version of our application is sometimes a bit unstable. Although this was not intentional at the beginning, it is a good opportunity to demonstrate the benefits of canary deployments. Therefore, we will deploy a new version of the application that fixes some of the issues and changes the UI a bit.

Therefore, change the image field in both Rollout manifests to the new version: ghcr.io/tsclabs-eu/lab-istio-rollouts/learning-tracker-frontend:v2 for the frontend and ghcr.io/tsclabs-eu/lab-istio-rollouts/learning-tracker-api:v2 for the API. After that, apply the changes using the following commands:

kubectl apply -f rollout-frontend.yaml -n learning-tracker
kubectl apply -f rollout-api.yaml -n learning-tracker

When opening the Web UI of the demo application and inspecting the status section of it, you should see that functionality changes a bit. Sometimes, you see a newly added Database field, that is part of the UI, sometimes this has a value and sometimes not which is a part of the new API. When inspecting the application in Kiali, you should see that it's much more stable than the initial version, as the new version fixes some of the issues.

During the rollout, you can also inspect the virtual services to see the changed traffic weights:

kubectl get virtualservice learning-tracker-frontend -n learning-tracker -o yaml
kubectl get virtualservice learning-tracker-api -n learning-tracker -o yaml

You should see that the weights for the canary subset are increasing while the weights for the stable subset are decreasing. This indicates that traffic is being shifted from the stable version to the canary version.

Finally, all traffic should be shifted to the new version and all pods are updated to the new version.

🎉Congratulations

You have successfully performed a canary deployment using Argo Rollouts and Istio. You have seen how traffic is shifted between different versions of the frontend and backend services, and how the new version of the application is more stable than the initial version. This demonstrates the benefits of using a service mesh and a deployment tool like Argo Rollouts to manage deployments in a Kubernetes environment.