The default deployment strategy on Kubernetes is a rolling update. Rolling updates allow a Deployment update to take place with zero downtime by incrementally updating Pod instances with new ones. But most likely in a real production environment you need a more advanced deployment strategy.
Traffic Shifts are a
microservice pattern to shift traffic or parts of traffic to specific services. Traffic Shifts are especially useful for deployment strategies like:
A/B Testing is a randomized experiment with two variants, A and B. Version B is released to a subset of users under specific condition.
Blue/Green is a technique that reduces downtime and risk by running two identical production environments called Blue and Green. At any time, only one of the environments is live, with the live environment serving all production traffic and the idle environment being used for final testing. Version B is released alongside version A, then the traffic is switched to version B.
Shadowing allows version B alongside version A to receive live traffic without impacting the response.
Canary, in a Canary release, version B is released to a subset of users, before rolling it out to the entire platform and making it available to everybody.
This section will roughly implement the instructions from the official Istio documentation about Traffic Shifting at https://istio.io/docs/tasks/traffic-management/traffic-shifting/.
This section uses the example application Bookinfo to shift traffic. See the architecture of the microservices for the Bookinfo app.
Create a temporary working directory, e.g.
$ mkdir istio101-test$ cd istio101-test
Download the Istio release v1.3.2, corresponding to the release of Istio installed on IKS, which includes the
bookinfo application, and add the istio path to your current PATH environment,
$ curl -L https://git.io/getLatestIstio | ISTIO_VERSION=1.3.2 sh -$ cd istio-1.3.2$ export PATH=$PWD/bin:$PATH
The bookinfo application was already pre-installed in the Setup Istio on IKS section,
Check your current-context, it should correspond with the cluster name you created in the Setup Istio on IKS section,
$ kubectl config current-contextremkohdev-standard-iks-cluster
Check the current
bookinfo deployment, wait until all deployments are ready 1/1,
$ kubectl get deploymentsNAME READY UP-TO-DATE AVAILABLE AGEdetails-v1 1/1 1 1 112mproductpage-v1 1/1 1 1 112mratings-v1 1/1 1 1 112mreviews-v1 1/1 1 1 112mreviews-v2 1/1 1 1 112mreviews-v3 1/1 1 1 112m
Note that the reviews deployment has 3 concurrent versions running:
Make sure that your system has an external load balancer. If the
EXTERNAL-IP value is set, your cluster has an external load balancer that you can use for the ingress gateway.
$ kubectl get svc istio-ingressgateway -n istio-systemNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEistio-ingressgateway LoadBalancer 172.21.123.4 123.45.678.90 15020:32461/TCP,80:31380/TCP,443:31390/TCP,31400:31400/TCP,15029:31599/TCP,15030:32349/TCP,15031:32405/TCP,15032:30296/TCP,15443:30522/TCP 111s
You can access your deployments via the Ingress gateway's external IP using the HTTP port 80 or the HTTPS port 443. For details on how to see the Ingress IP and port, see https://istio.io/docs/tasks/traffic-management/ingress/ingress-control/#determining-the-ingress-ip-and-ports.
To access the Bookinfo application, open and browser and go to http://123.45.678.90:80/productpage
An ingress Gateway in a service mesh describes a load balancer operating at the edge of the mesh. Unlike Kubernetes Ingress Resources, an ingress Gateway in a service mesh does not include any traffic routing configuration. Traffic routing for ingress traffic is instead configured using Istio routing rules, using a VirtualService.
Get the VirtualServices for the
$ kubectl get virtualserviceNAME GATEWAYS HOSTS AGEbookinfo [bookinfo-gateway] [*] 21m
$ kubectl describe virtualservice bookinfoName: bookinfoNamespace: defaultAPI Version: networking.istio.io/v1alpha3Kind: VirtualServiceSpec:Gateways:bookinfo-gatewayHosts:*Http:Match:Uri:Exact: /productpageUri:Prefix: /staticUri:Exact: /loginUri:Exact: /logoutUri:Prefix: /api/v1/productsRoute:Destination:Host: productpagePort:Number: 9080
Review the VirtualService spec
Version 3 of the VirtualService for the reviews service uses weight-based routing,
$ cat samples/bookinfo/networking/virtual-service-reviews-50-v3.yamlapiVersion: networking.istio.io/v1alpha3kind: VirtualServicemetadata:name: reviewsspec:hosts:- reviewshttp:- route:- destination:host: reviewssubset: v1weight: 50- destination:host: reviewssubset: v3weight: 50
Create the Traffic Shifts where 50% of traffic is routed to v1 and 50% of traffic is routed to v3,
$ kubectl apply -f samples/bookinfo/networking/virtual-service-reviews-50-v3.yamlvirtualservice.networking.istio.io/reviews created
Now, if you refresh your browser with the
productpage of the
Bookinfo app, you will see that 2 different versions load 50-50 percent of the time, namely a version with the
reviews-v1 that has no review stars, and a version with the
reviews-v3 that has 5 red stars for the review.
An HttpMatchRequest specifies a set of criteria to be met in order for the rule to be applied to the HTTP request.
To create a Canary release based on a logged in user's email domain stored in a cookie, you would add the following
HTTPMatchRequest to the
spec:hosts:- reviewshttp:- match:- headers:cookie:regex: "^(.*?;)?(email=[^;]*@companyA.com)(;.*)?$"
To route traffic based on the platform of the mobile client, add the following
HTTPMatchRequest to the
- match:- headers:user-agent:regex: '^.*(Android|iPhone).*$'