Traffic Splitting:

The pattern

Istio traffic splitting

How it works

The traffic splitting is handled by two Istio Object:

ObjectAPIVersion
VirtualServicenetworking.istio.iov1alpha3
DestinationRulenetworking.istio.iov1alpha3
  • VirtualService: A VirtualService define a set of traffic routing rules to apply when a host is addressed.

  • DestinationRule: A DestinationRule define 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:

Frontend service versions

  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: 50
    

Apply the DestinationRule:

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
  1. Wait a few second so the configuration will be pushed to envoy sidecars the refresh you browser: You have to get version 1 four time 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:

Kiali Traffic Splitting

Kiali Traffic Splitting

  1. On the Display menu, check Display menu:

Kiali Traffic Splitting

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

Kiali Traffic Splitting