Lab 5: Traffic Management with Istio

Managing Service Mesh Traffic with Istio

Istio is now actively monitoring the traffic within the service mesh. With the help of the Ingress gateway and the Envoy proxy, traffic flow within the mesh can be managed very easily.

Managing CSS with Istio Ingress

If you go the webpage of the planespotter frontend page ( ingress_URL/index.html), you will notice you do see the application, but the application does not have any styling, this is because the virtual service we created does not allow any traffic through the service mesh except the below matches:

• match:
  • uri: exact: /index.html
  • uri: exact: /registry.html
  • uri: exact: /details.html
  • uri: exact: /health.html
  • uri: exact: /contact.html

The application is architected to have all styling /static files for the website to be in the /style folder on the frontend service. To allow incoming traffic to use CSS, we need to explicitly allow the traffic into the service mesh. We can do so by creating a virtual service that will allow the traffic my matching the prefix to /static folder

• uri: prefix: /static

• Enable CSS for the planespotter to be allowed access

kubectl apply -f https://raw.githubusercontent.com/Boskey/planespotter/master/kubernetes/planespotter-virtualservice-css.yaml -n planespotter

Now, refresh your web browser a couple of times to the frontend page, you will start seeing the CSS associated with the frontend.

A/B Testing

Let's say we want to update the frontend app and change the 'Contacts' page to 'Feedback' to conduct an A/B test. With the help of Istio Ingress gateway, Envoy Proxy, and Kubernetes Services we can quickly deploy version 2 To do so, a couple of things to be kept in mind:

1. Ensure that the Kubernetes deployment yaml for version 2 has the same 'app' labels as version 1. This way Istio will route traffic to the same Kubernetes Service (frontend) and Kubernetes will forward the traffic to all the pods whether or not they are on version 1 or version 2 based on the 'app' label.

for e.g:

 matchLabels:
      app: planespotter-frontend
  template:
    metadata:
      labels:
        app: planespotter-frontend
        tier: frontend
        version: v2

2. When version 2 of the frontend gets deployed, ensure that the pods have sidecar proxy deployed

Let's begin by deploying version 2 of the frontend

kubectl apply -f https://raw.githubusercontent.com/Boskey/planespotter/master/kubernetes/frontend-deployment-v2.yaml -n planespotter

Ensure you see both version one and version in the cluster

kubectl get pods -n planespotter

Now refresh your browser to the application URL (ingress_URL/contact.html) a couple of times, after a couple of tries, you should start seeing 'Feedback' page as part of the version 2 update. Refresh the page once more and you will see the 'Contacts' page as well.