Home Explore Blog CI



kubernetes

4th chunk of `content/en/blog/_posts/2017-10-00-Request-Routing-And-Policy-Management.md`
392b6c4861a28c644a54b529547fa02180baf3a93774a1f50000000100000888
           version: v2

       weight: 10

   - labels:

           version: v1

       weight: 90
  ```

A better approach for early testing of a service version is to instead restrict access to it much more specifically. To demonstrate, we’ll set a rule to only make reviews:v2 visible to a specific test user. We do this by setting a second, higher priority rule that will only be applied if the request matches a specific condition:




 ```  
cat \<\<EOF | istioctl create -f -

apiVersion: config.istio.io/v1alpha2

kind: RouteRule

metadata:

 name: reviews-test-v2

spec:

 destination:

     name: reviews

 precedence: 2

 match:

     request:

         headers:

             cookie:

                 regex: "^(.\*?;)?(user=jason)(;.\*)?$"

 route:

 - labels:

         version: v2

     weight: 100

EOF
  ```

Here we’re specifying that the request headers need to include a user cookie with value “tester” as the condition. If this rule is not matched, we fall back to the default routing rule for v1.  

If we login to the Bookinfo UI with the user name “tester” (no password needed), we will now see version v2 of the application (each review includes 1-5 black rating stars). Every other user is unaffected by this change.  



 ![](https://lh5.googleusercontent.com/WLvX01Oja8R_cMb_AD91jIiF0bHW0nSJTRJ6Vt3Xz75MLzivZ5-ghHEZkdTJryhNXyTCUemF4OwxYn_96ntimOwyjABuZjaH3O2RsJyYQbqWoQgvSQktQd98t3T3Qe3KZSd20Cam)  

Once the v2 version has been thoroughly tested, we can use Istio to proceed with a canary test using the rule shown previously, or we can simply migrate all of the traffic from v1 to v2, optionally in a gradual fashion by using a sequence of rules with weights less than 100 (for example: 10, 20, 30, ... 100). This traffic control is independent of the number of pods implementing each version. If, for example, we had auto scaling in place, and high traffic volumes, we would likely see a corresponding scale up of v2 and scale down of v1 pods happening independently at the same time. For more about version routing with autoscaling, check out ["Canary Deployments using Istio"](https://istio.io/blog/canary-deployments-using-istio.html).  

Title: Restricting Access to Reviews:v2 and Canary Testing
Summary
This section describes how to restrict access to 'reviews:v2' to a specific test user by setting a higher priority Istio route rule that checks for a user cookie with the value "tester" in the request headers. If the cookie condition is met, the traffic is routed to 'reviews:v2', otherwise, it falls back to the default 'reviews:v1' routing. It also touches on canary testing using weighted route rules to gradually migrate traffic from v1 to v2 after thorough testing, noting that traffic control is independent of the number of pods implementing each version, and suggesting further reading on canary deployments with autoscaling.