Skip to content

Latest commit

 

History

History
232 lines (164 loc) · 7.73 KB

4simple-routerules.adoc

File metadata and controls

232 lines (164 loc) · 7.73 KB
Raw

Simple Route Rules

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

Create recommendation:v2

We can experiment with Istio controlling traffic by making a change to RecommendationVerticle.java like the following and creating a "v2" docker image.

private static final String RESPONSE_STRING_FORMAT = "recommendation v2 from '%s': %d\n";

The "v2" tag during the Docker build is significant.

There is also a second deployment.yml file to label things correctly

Docker build (if you have access to Docker daemon)

cd recommendation/java/quarkus
mvn clean package -DskipTests

docker build -t example/recommendation:v2 .

docker images | grep recommendation
example/recommendation                  v2                  c31e399a9628        5 seconds ago       438MB
example/recommendation                  v1                  f072978d9cf6        8 minutes ago      438MB
Important
 We have a 2nd Deployment to manage the v2 version of recommendation. 
oc apply -f <(istioctl kube-inject -f ../../kubernetes/Deployment-v2.yml) -n tutorial
oc get pods -w -n tutorial

or

kubectl apply -f <(istioctl kube-inject -f ../../kubernetes/Deployment-v2.yml) -n tutorial
kubectl get pods -w -n tutorial

Back to the main istio-tutorial directory

cd ../../..

Wait for v2 to be deployed

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

oc get pods -w -n tutorial{namespace-suffix}
NAME                                  READY     STATUS    RESTARTS   AGE
customer-3600192384-fpljb             2/2       Running   0          17m
preference-243057078-8c5hz           2/2       Running   0          15m
recommendation-v1-60483540-9snd9     2/2       Running   0          12m
recommendation-v2-2815683430-vpx4p   2/2       Running   0         15s

and test the customer endpoint

curl http://customer-tutorial{namespace-suffix}.{appdomain}

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.

curl http://customer-tutorial{namespace-suffix}.{appdomain}

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:

./scripts/run.sh http://customer-tutorial{namespace-suffix}.{appdomain}

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.

oc scale --replicas=2 deployment/recommendation-v2 -n tutorial{namespace-suffix}
or
kubectl scale --replicas=2 deployment/recommendation-v2 -n tutorial{namespace-suffix}

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

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

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

oc scale --replicas=1 deployment/recommendation-v2 -n tutorial{namespace-suffix}
or
kubectl scale --replicas=1 deployment/recommendation-v2 -n tutorial{namespace-suffix}

Changing Istio Routings

All users to recommendation:v2

From the main istio-tutorial directory,

kubectl create -f istiofiles/destination-rule-recommendation-v1-v2.yml -n tutorial{namespace-suffix}
kubectl create -f istiofiles/virtual-service-recommendation-v2.yml -n tutorial{namespace-suffix}

./scripts/run.sh http://customer-tutorial{namespace-suffix}.{appdomain}

you should only see v2 being returned

All users to recommendation:v1

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

kubectl replace -f istiofiles/virtual-service-recommendation-v1.yml -n tutorial{namespace-suffix}

kubectl get virtualservice -n tutorial{namespace-suffix}

kubectl get virtualservice -o yaml -n tutorial{namespace-suffix}

All users to recommendation v1 and v2

By simply removing the rule

kubectl delete -f istiofiles/virtual-service-recommendation-v1.yml -n tutorial{namespace-suffix}

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

./scripts/run.sh http://customer-tutorial{namespace-suffix}.{appdomain}

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

$ oc get pods -l app=recommendation -n tutorial{namespace-suffix}
or
$ kubectl get pods -l app=recommendation -n tutorial{namespace-suffix}

NAME                                  READY     STATUS    RESTARTS   AGE
recommendation-v1-3719512284-7mlzw   2/2       Running   6          2h
recommendation-v2-2815683430-vn77w   2/2       Running   0          1h

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

kubectl create -f istiofiles/virtual-service-recommendation-v1_and_v2.yml -n tutorial{namespace-suffix}

and send in several requests:

./scripts/run.sh http://customer-tutorial{namespace-suffix}.{appdomain}

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

kubectl replace -f istiofiles/virtual-service-recommendation-v1_and_v2_75_25.yml -n tutorial{namespace-suffix}

Clean up

kubectl delete -f istiofiles/virtual-service-recommendation-v1_and_v2_75_25.yml -n tutorial{namespace-suffix}
kubectl delete -f istiofiles/destination-rule-recommendation-v1-v2.yml -n tutorial{namespace-suffix}

or you can run:

./scripts/clean.sh tutorial{namespace-suffix}