Traffic Splitting:

The pattern

How it works

The traffic splitting is handled by two Istio Object:

• VirtualService: A VirtualService defines a set of traffic routing rules to apply when a host is addressed.

• DestinationRule: A DestinationRule defines policies that apply to traffic intended for a service after routing has occurred.

We create a VirtualService that list the different variation with their the weight:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: service-a
spec:
  hosts:
    - service-a
  http:
    - route:
        - destination:
            host: service-a
            subset: v1
          weight: 80
        - destination:
            host: service-a
            subset: v2
          weight: 20

Then the DestinationRule is responsible for defining the destination of the traffic and the traffic policy:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: property-business-service
spec:
  host: property-business-service
  subsets:
    - name: v1
      labels:
        version: "1.0"
    - name: v2
      labels:
        version: "1.1"

Traffic Splitting in practice

Let’s assume the we have new version of the frontend service where the advertise banner is in the top:

1. The Deploy the new version:

   kubectl apply -f <(istioctl kube-inject -f $WORKSHOP_HOME/istio-workshop-labs/frontend-0.1.3.yaml)
   

2. Extend the VirtualService of frontend service the destination:

   http:
   - match:
   - uri:
     prefix: /
   route:
   - destination:
     host: frontend
     port:
       number: 80
     subset: v1
   weight: 80
   - destination:
     host: frontend
     port:
       number: 80
     subset: v2
   weight: 20
   

Apply the VirtualService:

kubectl apply -f $WORKSHOP_HOME/istio-workshop-labs/frontend-virtualservice.yaml

1. Create a DestinationRule to specify the traffic destination:

   apiVersion: networking.istio.io/v1alpha3
   kind: DestinationRule
   metadata:
   name: frontend-destination-rule
   spec:
   host: frontend
   subsets:
   - name: v1
     labels:
       version: "v0.1.2"
   - name: v2
     labels:
       version: "v0.1.3"
   

Apply the DestinationRule:

kubectl apply -f $WORKSHOP_HOME/istio-workshop-labs/frontend-destinationrule.yaml

Wait a few seconds so the configuration will be pushed to envoy sidecars then refresh your browser: You have to get version 1 four times before getting version 2 of the frontend service rendered.

Check traffic on Kiali:

As mentioned earlier, Kiali provides a great real time view of what is going on the cluster:

1. Launch Kiali dashboard:

   istioctl dashboard kiali
   

2. Select hipster-app namespace Graph on the left menu then select Versioned App Graph, Request Percentage as Options:

1. On the Display menu, check Traffic Animation:

Graph will show the real traffic percentage between the different versions: