The following content is displayed on the same screen for your experiment so that you can make any necessary reference in experiment. Start your experiment now!

1. Step 1: Understand the applications used in the experiment(Duration: 2 mins)
   

   

   The whole application is transformed based on a Bookinfo application provided by Istio official to display book information. This part of the pink dotted-line frame is the original Bookinfo application architecture, which contains four separate services:

   - productpage: The productpage microservice calls details and reviews microservices to fill the page.
   - details: The details microservice provides book information.
   - reviews: The reviews microservice provides book review information. And calls ratings microservice.
   - ratings: The ratings microservice provides specific ratings for books.

   There are three versions of the reviews service. We can see the difference among the three versions visually, i.e. the scoring information of the books is shown differently: no star for V1 version, black star for V2 version and red star for V3 version.
   The rightmost regions service is the host service exposed by zCEE. In the fifth step of the experiment, we will access the regions service to the Istio service grid. The regions service provides an information on which country and region the book review comes from, which includes two versions. V1 version only provides information on country (such as China), and V2 version provides information on country and city (such as Beijing, China)

2. Step 2(Duration: 4 mins)
   

   In the Firefox browser opened by default, check if the bookinfo application can be called normally. There are no routing rules defined at present, so you can see that three versions of the reviews service will be randomly accessed by refreshing the page repeatedly.
   In addition, you can also execute the following command in the Terminal window to view the operation of pods corresponding to each service in Bookinfo application:
   Execution:

   kubectl get pods

   

   You can see that there are two containers running in each pods, one of which is the application itself and the other is the network proxy isio- proxy, which is used for intercepting the traffic in and out of the service and perform traffic control in the service grid.

3. Step 3(Duration: 3 mins)
   

   Define a routing rule for the reviews service and route all the traffics to the V2 version of the reviews service.
   Execute in the terminal window:

   kubectl apply -f lab/virtual-service-reviews-v2.yaml
   Note: If you are not in the user directory currently, you can execute cd ~
   to enter the user directory. User1 will be displayed as the screenshot below. It may be user1~user5 depending on your specific environment.

   You can view the VirtualService definition that just took effect by executing the following command:
   Execute:

   kubectl describe vs reviews

   

   Switch to the Firefox browser and refresh the page several times, then you may find that you always access the reviews service of V2 version (black star rating).

   

4. Step 4(Duration: 4 mins)
   

   Define a new routing rule for the reviews service. When a user logs in as Jason, it can access the v3 version of reviews. When it does not log in or logs in as another ID, it still accesses the v2 version of reviews. 
   Execute under the user directory:

   kubectl apply -f lab/virtual-service-reviews-jason-v3.yaml

   

   You can view the VirtualService definition that just took effect by executing the following command: 
   Execute:

   kubectl describe vs reviews
   

   Switch back to the browser, click the "sign in" button in the upper right corner of the page to log in, fill in the user name Jason, and the password can be arbitrary characters. After logging in, you can see that you are accessing the V3 version of the reviews service (red star rating). Then click the sign out in the upper right corner of the page to see that the accessed reviews service is V2 version. 
   The following is the example figure after signing in as Jason:

   
5. Step 5(Duration: 5 mins)
   

   Introduce the host service regions into the service grid through Istio's ServiceEntry resource. 
   Execute under the user directory:
   kubectl apply -f lab/zcee-se-2.yaml (Introducing the services of regions v1 and v2)
   kubectl apply -f lab/zcee-dr.yaml (define a service subset for the regions service)

   

   In the Firefox browser, you can see which country and region the book review information comes from. Because no routing rule for regions service has not been defined, the regions service of both versions can be randomly accessed by refreshing the page several times. 
   Note: Regions V1 version only displays country information (eg: CHINA)
   Regions V2 version will display the information of region + country (eg: BEIJING,CHINA)

   

   

6. Step 6(Duration: 5 mins)
   

   Define a routing rule for the host service regions so as to achieve the weight-based diversion. 
   Execute under the user directory:
   kubectl apply -f lab/zcee-vs-80-20.yaml
   

   

   You can view the VirtualService definition that just took effect by executing the following command: 
   Execute:

   kubectl describe vs regions

   

   In the Firefox browser, when the page is refreshed several times, it can be observed that the two versions of regions service are diverted according to the proportion of 4:1 for V1 version vs V2 version.

7. Step 7(Duration: 4 mins)
   

   Define a routing rule for the host service regions and route all the traffics to the v1 version of the regions service. 
   Execute under the user directory:
   kubectl apply -f lab/zcee-vs-regions-v1.yaml
   

   

   You can view the VirtualService definition that just took effect by executing the following command: 
   Execute:

   kubectl describe vs regions

   

   In the Firefox browser, after the page is refreshed several times, you can see that all traffics of regions service is routed to V1 version (regions V1 version only displays information of country).

8. Step 8(Duration: 5 mins)
   

   In this step, we will extend Istio by using Envoyfilter to achieve more complex and personalized traffic control requirements. In step 4, we simulate the scenario of diversion for specific ID login, and show Istio's ability of diversion based on HTTP header field. In reality, what shall we do when we want to achieve the scenario of diverting the host services based on message content? We can achieve it by making use of Envoyfilter extension mechanism provided by Istio. Next, we deploy an Envoyfilter, in which a lua filter is used to determine the value of a field in the HTTP body. If the condition is met, the request for regions service will be routed to V2 version. If the condition is not met, it will still be routed to V1 version. 
   Execute under the user directory:
   kubectl apply -f lab/envoyfilter_parsehttpbody.yaml
   

   

   If you want to view the definition of the envoyfilter, you can execute it in the user directory:
   cat lab/envoyfilter_parsehttpbody.yaml
   Next, let's test: 
   Since we can't customize the message (i.e. HTTP body) for accessing the host service regions through the browser, we would like to test it through the curl command: 
   Execution:

   kubectl exec -it busybox -ntest - curl -XGET -H "Content-Type:application/json" -d'{"membership":"vip"}' reviews.default.svc.cluster.local:9080/ reviews/0
   (As this command is too long to type manually, you can copy the command from cat lab/note.txt under the user directory and execute it)
   

   

   You can see that when the membership field in HTTP body is vip, the access to the regions service will be routed to V2 version. 
   You can try to change the vip to a different value, or access from the browser (no membership field is available in the HTTP body when the browser is accessed). You can observe that access to the regions service will be routed to the V1 version.
   

   

9. Step 9(Duration: 8 mins)
   

   In this step, we continue to extend Istio by using Envoyfilter in order to perform transaction side recording (traffic interception) for the access to the host service regions. Next, we deploy an Envoyfilter to perform side recording for the traffic accessing host service regions, i.e. grab transaction messages and send them asynchronously to platforms such as fluentd, kafka, etc. (we take fluent as an example during the experiment). 
   Execute the following command under the user directory and deploy fluentd:
   kubectl apply -f lab/fluentd.yaml
   And execute the following command to check the start status of the fluent pod and confirm it to be in the running state:
   kubectl get pods fluentd -ntest
   

   

   Execute the following command under the user directory and deploy Envoyfilter:
   kubectl apply -f lab/envoyfilter_logservice.yaml

   

   If you want to view the definition of the envoyfilter, you can execute it in the user directory:
   cat lab/envoyfilter_logservice.yaml
   Next, let's test: 
   Switch to the Firefox browser and refresh the page to simulate the access request. 
   View if there is any HTTP body message intercepted in fluentd: 
   Execute the following command to enter fluent:
   kubectl exec -it fluentd -ntest sh
   

   

   Execute the following command to enter the path of storing the side-recording message file:
   cd /tmp/fluent-logs/httprequest.log/

   

   ls

   

   Read the file with the tail as .log by cat command:
   cat buffer*.log

   

   Refresh it several times in the Firefox browser, and then you will find that more requests are intercepted in the cat log file:

   

   At this point, we have achieved a simple transaction side recording scenario. In practical application, you can dock with more complex platform architectures, such as fluent and then elasticsearch etc. 
   We hope that, through the experiment, you can get a visual feeling that the access of the host service to the service network is a quite simple and convenient thing. Meanwhile, we can make use of powerful traffic control ability and service governing ability provided by the service gird to achieve all kinds of simple or complicated traffic control scenarios. Thank you for your attending!

Start Your Experiment