Skip to content

Latest commit

 

History

History
101 lines (64 loc) · 4.57 KB

sc02-tc09.md

File metadata and controls

101 lines (64 loc) · 4.57 KB
Raw

SC02-TC09: CaaS control plane shall provide support for canary releases - app with 2 versions

Prerequisites

  • DevOps Engineer console and user credentials

  • TSM enabled Kubernetes Cluster

    1. Install TSM extension in TMC. From the TMC portal click on Administration in the left menu and then select the Integrations tab on the main window pane. If not already enabled click to ENABLE Tanzu Service Mesh.

    2. From TMC, install TSM in a cluster and onboard it.

Test Procedure

With Istio, traffic routing and replica deployment are two completely independent functions. The number of pods implementing services are free to scale up and down based on traffic load, completely orthogonal to the control of version traffic routing. This makes managing a canary version in the presence of autoscaling a much simpler problem. Autoscalers may, in fact, respond to load variations resulting from traffic routing changes, but they are nevertheless functioning independently and no differently than when loads change for other reasons.

Istio’s routing rules also provide other important advantages; you can easily control fine-grained traffic percentages (e.g., route 1% of traffic without requiring 100 pods) and you can control traffic using other criteria (e.g., route traffic for specific users to the canary version). To illustrate, let’s look at deploying the helloworld service and see how simple the problem becomes.

This sample includes two versions of a simple helloworld service that returns its version and instance (hostname) when called.It can be used as a test service when experimenting with version routing.

  1. Change context to the kubernetes cluster where Istio Service Mesh(TSM) is installed

    kubectl vsphere login --server=${SC_API_VIP} --vsphere-username ${SC_USER_NAME} --insecure-skip-tls-verify --tanzu-kubernetes-cluster-namespace ${TKC_NAMESPACE} --tanzu-kubernetes-cluster-name ${TKC_NAME}

    Change kubernetes context

    kubectl config use-context ${TKC_NAME}
kubectl config set-context --current --namespace=default

  2. We begin by defining the helloworld Service, just like any other Kubernetes service, To run different versions of the helloworld service, use the following command:

    kubectl apply -f scenarios/devops/helloworld.yaml

    Alternatively, you can run just one version at a time by first defining the service:

    kubectl apply -f scenarios/devops/helloworld.yaml -l app=helloworld

    and then deploying version v1, v2, or both:

    kubectl apply -f scenarios/devops/helloworld.yaml -l version=v1
kubectl apply -f scenarios/devops/helloworld.yaml -l version=v2

    Note that this is exactly the same way we would do a canary deployment using plain Kubernetes, but in that case we would need to adjust the number of replicas of each Deployment to control the distribution of traffic. For example, to send 10% of the traffic to the canary version (v2), the replicas for v1 and v2 could be set to 9 and 1, respectively.

  3. Define traffic routing - since we are going to deploy the service in an Istio enabled cluster, all we need to do is set a routing rule to control the traffic distribution. For example if we want to send 10% of the traffic to the canary, we could use kubectl to set a routing rule using virtual service and destination rule-

    kubectl apply -f scenarios/devops/virtualservice-90-10.yaml

After setting this rule, Istio will ensure that only one tenth of the requests will be sent to the canary version, regardless of how many replicas of each version are running.

  1. Export LOADBALANCER_EXTERNAL_IP by setting istio-ingressgateway LoadBalancer external IP

    export LOADBALANCER_EXTERNAL_IP=`kubectl get svc istio-ingressgateway -n istio-system  | awk 'NR == 2 {print $4}'`

  2. Invoke service multiple times and verify traffic routing

    curl  -H "Host: helloworld.avi-ns1.poc6349.wwtatc.lab" http://$LOADBALANCER_EXTERNAL_IP/hello

  3. Change the routing rule to send 50% of the traffic to v2.

    kubectl apply -f scenarios/devops/virtualservice-50-50.yaml

  4. Invoke service multiple times and verify traffic routing

    curl  -H "Host: helloworld.avi-ns1.poc6349.wwtatc.lab" http://$LOADBALANCER_EXTERNAL_IP/hello

  5. cleanup

    kubectl delete -f scenarios/devops/helloworld.yaml
kubectl delete -f scenarios/devops/virtualservice-90-10.yaml

Status Pass/Fail

  • [ ] Pass
  • [ ] Fail