Simple Route Rules

For this use case, we need to use a modified version of Recommendations

Deploy recommendation:v2

You will deploy docker images that were previously built for this tutorial. If you want to build recommendation V2 with Quarkus visit: Create Recommendation V2
You will deploy docker images that were previously built for this tutorial. If you want to build recommendation V2 with Spring Boot visit: Create Recommendation V2 Spring Boot
We have a 2nd Deployment to manage the v2 version of recommendation.

If you have not built the images on your own then let’s deploy the customer pod with its sidecar using the already built images for this tutorial:

Deploy Recommendation microservice V2 using an existing image

  1. oc apply -f <(istioctl kube-inject -f recommendation/kubernetes/Deployment-v2.yml) -n tutorial
  2. or
  3. kubectl apply -f <(istioctl kube-inject -f recommendation/kubernetes/Deployment-v2.yml) -n tutorial

Wait for v2 to be deployed

Wait for those pods to show "2/2", the istio-proxy/envoy sidecar is part of that pod

  1. oc get pods -w -n tutorial
  2. NAME                                  READY     STATUS    RESTARTS   AGE
  3. customer-3600192384-fpljb             2/2       Running   0          17m
  4. preference-243057078-8c5hz           2/2       Running   0          15m
  5. recommendation-v1-60483540-9snd9     2/2       Running   0          12m
  6. recommendation-v2-2815683430-vpx4p   2/2       Running   0         15s

and test the customer endpoint

  1. curl istio-ingressgateway-istio-system.$(minishift ip).nip.io/customer

you likely see "customer => preference => recommendation v1 from '99634814-d2z2t': 3", where '99634814-d2z2t' is the pod running v1 and the 3 is basically the number of times you hit the endpoint.

  1. curl istio-ingressgateway-istio-system.$(minishift ip).nip.io/customer

you likely see "customer => preference => recommendation v2 from '2819441432-5v22s': 1" as by default you get round-robin load-balancing when there is more than one Pod behind a Service

Send several requests to see their responses:

  1. ./scripts/run.sh istio-ingressgateway-istio-system.$(minishift ip).nip.io/customer

The default Kubernetes/OpenShift behavior is to round-robin load-balance across all available pods behind a single Service. Add another replica of recommendation-v2 Deployment.

  1. oc scale --replicas=2 deployment/recommendation-v2 -n tutorial
  2. or
  3. kubectl scale --replicas=2 deployment/recommendation-v2 -n tutorial

Now, you will see two requests into the v2 and one for v1.

  1. customer => preference => recommendation v1 from '2819441432-qsp25': 29
  2. customer => preference => recommendation v2 from '99634814-sf4cl': 37
  3. customer => preference => recommendation v2 from '99634814-sf4cl': 38

Scale back to a single replica of the recommendation-v2 Deployment

  1. oc scale --replicas=1 deployment/recommendation-v2 -n tutorial
  2. or
  3. kubectl scale --replicas=1 deployment/recommendation-v2 -n tutorial

Changing Istio Routings

All users to recommendation:v2

From the main istio-tutorial directory,

  1. kubectl create -f istiofiles/destination-rule-recommendation-v1-v2.yml -n tutorial
  2. kubectl create -f istiofiles/virtual-service-recommendation-v2.yml -n tutorial
  4. ./scripts/run.sh istio-ingressgateway-istio-system.$(minishift ip).nip.io/customer

you should only see v2 being returned

All users to recommendation:v1

Note: "replace" instead of "create" since we are overlaying the previous rule

  1. kubectl replace -f istiofiles/virtual-service-recommendation-v1.yml -n tutorial
  3. kubectl get virtualservice -n tutorial
  5. kubectl get virtualservice -o yaml -n tutorial

All users to recommendation v1 and v2

By simply removing the rule

  1. kubectl delete -f istiofiles/virtual-service-recommendation-v1.yml -n tutorial

and you should see the default behavior of load-balancing between v1 and v2

  1. ./scripts/run.sh istio-ingressgateway-istio-system.$(minishift ip).nip.io/customer

Canary deployment: Split traffic between v1 and v2

Canary Deployment scenario: push v2 into the cluster but slowly send end-user traffic to it, if you continue to see success, continue shifting more traffic over time

  1. $ oc get pods -l app=recommendation -n tutorial
  2. or
  3. $ kubectl get pods -l app=recommendation -n tutorial
  5. NAME                                  READY     STATUS    RESTARTS   AGE
  6. recommendation-v1-3719512284-7mlzw   2/2       Running   6          2h
  7. recommendation-v2-2815683430-vn77w   2/2       Running   0          1h

Create the virtualservice that will send 90% of requests to v1 and 10% to v2

  1. kubectl create -f istiofiles/virtual-service-recommendation-v1_and_v2.yml -n tutorial

and send in several requests:

  1. ./scripts/run.sh istio-ingressgateway-istio-system.$(minishift ip).nip.io/customer

In another terminal, change the mixture to be 75/25

  1. kubectl replace -f istiofiles/virtual-service-recommendation-v1_and_v2_75_25.yml -n tutorial

Clean up

  1. kubectl delete -f istiofiles/virtual-service-recommendation-v1_and_v2_75_25.yml -n tutorial
  2. kubectl delete -f istiofiles/destination-rule-recommendation-v1-v2.yml -n tutorial

or you can run:

  1. ./scripts/clean.sh tutorial