Istio Patterns: Traffic Splitting in Kubernetes (Header/Cookie Based)

How to split traffic in Kubernetes with Istio based on request headers, tutorial, and examples with source code.

Header Based Traffic Splitting Using Istio

Using Istio it is possible to distribute the traffic load using a request or client header as a switch to decide where to send the traffic. It can be useful in many situations like:

  • Testing a new release: a request that includes a special header is sent to access the new release.
  • Differentiating logged-in users from anonymous:  looking for the presence of a cookie that is set when the user is authenticated can be used to redirect all authenticated users to a different back-end.
  • Trying a new interface: Redirect users to a new interface during beta testing by placing a client cookie.

This tutorial shows how to define the needed Istio resources to distribute traffic based on the presence of a cookie or a header.

Prerequisites

The examples shown in this Istio tutorial can be used in any Kubernetes cluster with Istio installed. If you need to run a full and free Kubernetes cluster on your development environment, please see my previous tutorials:

You will also need the Color web application to follow the example, it is a very small and simple application developed in Go that changes the background color based on the value of an environment variable.

Web browser showing a web page with green background and the content of the request
Using a header to route a request in istio for A/B testing or new releases

See Istio Patterns: Traffic Splitting in Kubernetes (Canary Release) for instructions on how to build the application.

You can download the source code from IT Wonder Lab git repository, build the application, and create your own Docker image, or use a prebuilt image from the IT Wonder Lab Docker public repository.

Istio Definition for Header Traffic Routing

The color-istio-gw-client-header.yaml defines 4 resources to accomplish an Istio Header Traffic Routing Deployment of the Color application:

Nodeport Gateway Virtual Service examining a Header, Destination Rule and Service
Using Istio for traffic routing based on a Header

In order to have a Header Based Routing decision in Istio only a single configuration element needs to be changed, the Istio Virtual Service.

Istio Virtual Service

It is a networking.istio.io/v1alpha3 VirtualService, shown with a yellow background on the above diagram.

The name of the Istio Virtual Service has been changed so that the previous Canary Deployment can still work and is not replaced by this new definition.

The new is color-is-vs-header Istio Virtual Service is defined as:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: color-is-vs-header
spec:
  hosts:
  - "*"
  gateways:
  - color-is-gw
  http:
  - match:
    - uri:
        prefix: /header
      headers:
        want-color:
          exact: green
    route:
    - destination:
        host: color-service #Name of the service
        subset: green-sub
  - match:
    - uri:
        prefix: /header
    route:
    - destination: #Default (if match is false)
        host: color-service #Name of the service
        subset: blue-sub

The “hosts” attribute is used to match traffic with any host header (represented with *).

The “http” attribute defines that this Virtual Service applies to HTTP traffic.

Indentation of match sections and route attributes are used to create an Istio  Routing decision tree, in our header routing example, the match sections have the same indentation, meaning that the first match section will be evaluated, and if all conditions are true, the route will be applied. If any of the conditions fail, the next match section will be evaluated.

Istio decision tree:

The first “match” section will:

  1. Select the traffic whose:
    • URI has a prefix /header AND
    • a header is present with the name “want-color” and the value is exactly “green”
  2. Route the selected traffic to the subset green-sub of the color-service.
  3. End evaluation of Istio Virtual Service

The second “match” section will only be evaluated if the first section is not true, it will:

  1. Select the traffic whose:
    1. URI has a prefix /header AND
  2. Route the selected traffic to the subset blue-sub of the color-service.
  3. End evaluation of Istio Virtual Service

The Istio Gateway, Kubernetes Service color-service, and Istio Destination Rule are the same as the ones defined for the Canary Deployment, shown here as a reference:

  • Istio Gateway (networking.istio.io/v1alpha3 Gateway): uses the existing ingressgateway created when Istio was deployed to accept HTTP traffic at port 80 from any host (*).
  • Istio Destination Rule (networking.istio.io/v1alpha3 DestinationRule): defines subsets of a known service, in our example defines two subsets of the color-service service or host (in Istio, the services are called the host):
    • blue-sub: corresponds to the service color-service with a label color equal to blue.
    • green-sub: corresponds to the service color-service with a label color equal to green.
  • Kubernetes Service color-service:  creates a cluster service named “color-service“, that receives traffic at port 8000 and sends it to port 8080 of the containers (the port exposed by the Docker images of the Color Application).

Create the objects in the Kubernetes Cluster with:

jruiz@XPS13:~/../istio-patterns$ kubectl apply -f color-istio-gw-client-header.yaml

Open a browser and visit the URL http://192.168.50.11:31380/header/

The background of the page will be always blue.

In order to access the green version, a client header needs to be added. If using Google Chrome a header can be added with the extension ModHeader.

Add the header want-color with the value green.

Reload the URL http://192.168.50.11:31380/header/ to see the green version:

Web broser windows showing a green page with the contents of the Request
Istio receiving a header indicating the color to show (application to route to)

Delete the header or change its name or value to go back to the blue version.

Use a Cookie for Istio Routing

In order to have cookie-based Routing decisions in Istio, only a single configuration element needs to be changed, the Istio Virtual Service.

The color-istio-gw-client-cookie.yaml includes all the needed Istio objects.

The name of the Istio Virtual Service has been changed so that the previous Header-Based Deployment can still work and is not replaced by this new definition.

The new color-is-vs-cookie Istio Virtual Service is defined as:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: color-is-vs-cookie
spec:
  hosts:
  - "*"
  gateways:
  - color-is-gw
  http:
  - match:
    - uri:
        prefix: /cookie
      headers:
        cookie:
          regex: ^(.\*?;)?(my-color=green)(;.\*)?$
    route:
    - destination:
        host: color-service #Name of the service
        subset: green-sub
  - match:
    - uri:
        prefix: /cookie
    route:
    - destination: #Default (if match is false)
        host: color-service #Name of the service
        subset: blue-sub

The new Istio decision tree checks for the existence of a cookie. Cookies are not much different than other client headers, the only difference is that a regular expression is needed to find the desired cookie inside the cookie header.

The first “match” section will:

  1. Select the traffic whose:
    • URI has a prefix /header AND
    • a header is present with the name “cookie” and value color=green. A regular expression ^(.\*?;)?(my-color=green)(;.\*)?$ is used to test the condition.
  2. Route the selected traffic to the subset green-sub of the color-service.
  3. End evaluation of Istio Virtual Service

The second “match” section will only be evaluated if the first section is not true, it will:

  1. Select the traffic whose:
    1. URI has a prefix /header AND
  2. Route the selected traffic to the subset blue-sub of the color-service.
  3. End evaluation of Istio Virtual Service

In order to access the green version, a cookie needs to be added. If using Google Chrome a cookie can be added with the extension EditThisCookie.

Add the cookie my-color with the value green and reload the URL http://192.168.50.11:31380/header/ to see the green version.

Webbroser windows showing a green page with the contents of the Request
Two cookies are shown as part of the Request in an Istio service mesh

The screenshot of the Color Applications shows, highlighted in blue, two Cookies, one of the cookies is the my-color=green cookie set by us using the Google Chrome extension EditThisCookie and the other cookie color=green was set by the application and sent to the client.

Kubernetes and Istio Header based Routing
Table of Contents
Primary Item (H2)Sub Item 1 (H3)Sub Item 2 (H4)
Sub Item 3 (H5)
Sub Item 4 (H6)

Related Cloud Tutorials

How to Deploy Applications in Kubernetes using Terraform
How to publish multiple replicas of an Application (from the Docker Registry) and create a NodePort in Kubernetes using Terraform (in 10 seconds)
OSI model
The 7 layers of the OSI model The OSI model is a conceptual framework that is used to describe how a network functions. It identifies seven fundamental networking layers, from the physical hardware up to high-level software applications. Each layer in the model handles a specific networking function. The standard helps administrators to visualize networks, […]
Terraform Cloud Agents in a Kubernetes Cluster
What are the Terraform Cloud Agents? With Terraform Cloud Agents, a company can manage its private infrastructure as code and benefit from all the functionality of Terraform in a SaaS scenario.
LAN, NAT, HOST Only and Tunnel Kubernetes networks
Kubernetes Cluster using Vagrant and Ansible with Containerd (in 3 minutes)
Tutorial and full source code explaining how to create a Kubernetes cluster with Ansible and Vagrant for local development under 3 minutes.
Installing Istio on Kubernetes
How to install Istio in a Kubernetes Cluster to use it as a service mesh for a microservices architecture.
Installing the Kubernetes Dashboard and managing the Cluster using kubectl
How to install the Kubernetes Dashboard and manage the cluster after installation.
Running Postgres in Kubernetes with a Persistent NFS Volume
How to create a Kubernetes persistent volume for Postgres long term storage of data using a NFS Volume
Using a NodePort in a Kubernetes Cluster on top of VirtualBox
Kubernetes tutorial explaining how to use a NodePort to publish applications in a Kubernetes cluster running in VirtualBox with Vagrant and Ansible
Istio - ansible-kubernetes-vagrant-tutorial-Istio-2.png
Istio Patterns: Traffic Splitting in Kubernetes (Canary Release)
Tutorial on how to use Istio on Kubernetes for releasing new versions of software to the Cloud.

Javier Ruiz

IT Wonder Lab tutorials are based on the rich and diverse experience of Javier Ruiz, who founded and bootstrapped a SaaS company in the energy sector. His company, which was later acquired by a NASDAQ traded company, managed over €2 billion per year of electricity for prominent energy producers across Europe and America. Javier has more than 20 years of experience in building and managing IT companies, developing cloud infrastructure, leading cross-functional teams, and transitioning his own company from on-premises, consulting, and custom software development to a successful SaaS model that scaled globally.

One comment on “Istio Patterns: Traffic Splitting in Kubernetes (Header/Cookie Based)”

Leave a Reply

Your email address will not be published. Required fields are marked *


linkedin facebook pinterest youtube rss twitter instagram facebook-blank rss-blank linkedin-blank pinterest youtube twitter instagram