VirtualService connects a Kubernetes service to the Istio gateway. It can do many things. We will look at this in detail as we go through the following code and explain the different traffic management capabilities:

1. Let's look at the 01-create-virtual-service.yaml script:

# Script : 01-create-virtual-service.yaml

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: bookinfo
spec:
  hosts:
  - "*"
  gateways:
  - mygateway
  http:
  - match:
    - uri:
        exact: /productpage
    - uri:
        prefix: /static
    - uri:
        exact: /login
    - uri:
        exact: /logout
    - uri:
        prefix: /api/v1/products
    route:
    - destination:
        host: productpage.istio-lab.cluster.svc.local
        port:
          number: 9080

The traffic for booksinfo.istio.io, which resolves to IP address 192.168.142.249, arrives at the Istio Ingress gateway. The virtual service as per the preceding definition routes the traffic for the /productpage, /static, /login, /logout, and /api/v1/products URLs to the productpage.istio-lab.svc.cluster.local microservice at port 9080. 

2. Let's create  VirtualService:

$ kubectl -n istio-system apply -f 01-create-virtual-service.yaml
virtualservice.networking.istio.io/bookinfo created

The virtual service that we've created will accept traffic from all hosts coming through mygateway, which will look for a URI pattern called productpage and route the traffic to the Kubernetes productpage.istio-lab.svc.cluster.local service to port number 9080.

3. Test the return http code using the virtual service we created in the previous step to make sure that the routing from the Istio Ingress gateway to the Istio virtual service is happening properly:

$ curl -o /dev/null -s -w "%{http_code}
" http://$INGRESS_HOST/productpage
200

An output of 200 marks the page has loaded successfully. 

Let's test http://192.168.142.249/productpage using a browser within the VM.

4. Refresh the page several times. Under the reviews section, you will notice that the reviewer's ratings change to either no stars, black stars, or red stars. This is due to the fact that we have three versions of the reviews microservice, as shown by the output of the following command:

$ kubectl -n istio-lab get ep | grep reviews
NAME          ENDPOINTS                         AGE
reviews       10.142.230.236:9080,              82m
              10.142.230.238:9080,
              10.143.230.242:9080

5. Notice that the reviews microservice, which is called from productpage, contains three endpoints that are connected to different versions of the reviews pod. The three IP addresses belong to different reviews pods:

$ kubectl -n istio-lab get pods -o=custom-columns=NAME:.metadata.name,POD_IP:.status.podIP
NAME                              POD_IP
details-v1-68955b8bdc-5bw67       10.142.230.244
productpage-v1-74dfdd8b47-xmdpn   10.142.230.241
ratings-v1-79b6d99979-k2j7t       10.142.230.239
reviews-v1-69b9dddccf-bsfps       10.142.230.238
reviews-v2-84c46bf56d-48ks9       10.142.230.236
reviews-v3-64ff5788c7-5xzbk       10.142.230.242

Note that the IP addresses of the pods can be different in your case. 

When we refresh the productpage, routing is done in a round-robin fashion where all of the reviews microservices will show either black stars, red stars, or no stars. 

6. Check the gateway and virtual service:

$ kubectl -n istio-system get gateway
NAME               AGE
mygateway          15m

$ kubectl -n istio-system get vs
NAME       GATEWAYS             HOSTS   AGE
bookinfo   [mygateway]          [*]     15m

Within the Kubernetes cluster, the sample productpage microservice of bookinfo can be called either by using the pod's IP address or the Kubernetes services that ties its IP address to the pod. The automatic coupling between the Kubernetes service and the pod makes distributed computing easy.