- Istio an introduction
- Getting started with Istio
- Istio in Practice – Ingress Gateway
- Istio in Practice – Routing with VirtualService
- Istio out of the box: Kiali, Grafana & Jaeger
- A/B Testing – DestinationRules in Practice
- Shadowing – VirtualServices in Practice
- Canary Deployments with Istio
- Timeouts, Retries and CircuitBreakers with Istio
- Authentication in Istio
- Authorization in Istio
- Istio series Summary
Canary Deployment is the process of rolling out a new version of an application to a small set of users, as a step to verify the absence of issues, and then with a higher assurance of quality release to the wider audience.
Let’s continue with the same buggy subset of sa-logic to demonstrate canary deployments, by boldly sending 20% of the users to the buggy version (this represents the canary deployment) and 80% to the healthy service by applying the VirtualService below:
- Weight specifies the percentage of requests to be forwarded to the destination or subset of the destination.
Update the previous sa-logic
virtual service configuration using the following commands:
$ kubectl apply -f resource-manifests/istio/canary/sa-logic-subsets-canary-vs.yaml virtualservice.networking.istio.io/sa-logic configured
We immediately see that some of our requests are failing:
$ while true; do \ curl -i http://$EXTERNAL_IP/sentiment -H "Content-type: application/json" \ -d '{"sentence": "I love yogobella"}' \ --silent -w "Time: %{time_total}s \t Status: %{http_code}\n" -o /dev/null; \ sleep .1; done Time: 0.153075s Status: 200 Time: 0.137581s Status: 200 Time: 0.139345s Status: 200 Time: 30.291806s Status: 500
VirtualServices enable Canary Deployments and with this method, we reduced potential damages to 20% of our user base. Beautiful! Now we can use Shadowing and Canary Deployments every time we are insecure about our code, basically always 😜.
If you enjoyed the article, please share and comment below!