Now we will clone our repo containing our Istio resources.

git clone https://github.com/boxboat/istio-blog-resources.git

Change to the cloned directory:

cd istio-blog-resources

Istio runs the envoy-proxy as a sidecar to every pod it manages. This allows Istio to intercept network communication and make informed routing decisions based on the rules passed to envoy.

Istio can automatically handle injecting its sidecar in to a deployment, but for our demonstration we have not enabled that functionality. Instead, we will be manually injecting the Istio sidecar using istioctl kube-inject. This command outputs a modified YAML with the components needed for Istio.

You can see the output of the injection by running:

istioctl kube-inject -f ./traffic-weighting/deployment.yaml

This injection adds an init container running the image docker.io/istio/proxy_init to each deployment. It also adds a sidecar container which runs the docker.io/istio/proxyv2 image as well as the configuration these two images need to run.

To actually run this modified deployment do the following:

istioctl kube-inject -f ./traffic-weighting/deployment.yaml | kubectl apply -f -

We must also deploy the services used for our applications. These services will be require for the proxies to have a healthy response from their healthcheck:

kubectl apply -f ./traffic-weighting/services.yaml

Running:

kubectl get pods

Should now show us 5 pods: 3 versions of our colors application, a logger backend and a logger frontend. Each of these pods will run 2 containers - one for our application and another for Istio's proxy.

Our applications are up and running but they still need to be wired up to the ingress.

First we will create our gateway. This will act as an ingress for our traffic. For this sample our gateway will respond to any host as denoted by the *:

Take a look at the gateway YAML:

cat ./traffic-weighting/gateway.yaml

Apply the gateway YAML:

kubectl apply -f ./traffic-weighting/gateway.yaml

We will then create our virtual service. A virtual service binds to a gateway, and defines routes to the hosts in kubernetes. Our virtual service defines the routes that will be used for our applications.

Take a look at the virtual-service YAML:

cat ./traffic-weighting/virtualservice.yaml

Apply the virtual-service YAML:

kubectl apply -f ./traffic-weighting/virtualservice.yaml

Once these components have been created, we can view our application.

Reload the page on the sample app a couple of times, you should see each color roughly 1/3 of the time.

Sample app: https://[[HOST_SUBDOMAIN]]-80-[[KATACODA_HOST]].environments.katacoda.com/colors

We also have a logger frontend. Each application logs out with the color it displays whenever it is accessed. The logger frontend displays how many times each color has been seen.

Logger frontend: https://[[HOST_SUBDOMAIN]]-80-[[KATACODA_HOST]].environments.katacoda.com/

Before continuing, click the "Delete Logs" button on the logger frontend to clear the logged requests.

By default Istio will just round-robin those requests, which is no more powerful than what could be accomplished easily through Kubernetes primitives. But whereas with Kubernetes you would need to have at least 10 replicas of your application to do a 10% - 30% - 60% traffic split, Istio can do this with only the 3 application pods we have created

For this we are now going to create Istio destination rules. Destination rules allow us to define subsets. These subsets filter endpoints based on labels. For this example we are defining 3 subsets, one for each version of our application. The subsets use the version label that were added to our deployments to determine the appropriate application version to route to.

We also update our virtual service definition for colors to make use of these subsets. By adding multiple destination rules to our virtual service and providing weight values to them we can control the flow of traffic to these services.

Take a look at the destination rule YAML:

cat ./traffic-weighting/destinationrule.yaml

Apply the destination rule YAML:

kubectl apply -f ./traffic-weighting/destinationrule.yaml

Again reload the page on the sample app many times, you should see each "crimson" at roughly 10% of traffic, "lightseagreen" at roughly 30% of traffic and "indigo" at roughly 60% of traffic. Note that Istio makes use of weighted randomness so the traffic will approaches the percentages defined but will never be spot on.

Sample app: https://[[HOST_SUBDOMAIN]]-80-[[KATACODA_HOST]].environments.katacoda.com/colors

After many reloads, view the logger: Logger frontend: https://[[HOST_SUBDOMAIN]]-80-[[KATACODA_HOST]].environments.katacoda.com/

Through this walkthrough we have successfully deployed a minimal Istio installation which uses only the pilot and the ingress gateway. We have shown how Istio can be used for managing traffic to multiple backends based on defined percentages, but this is just scratching the surface. Weighting rules can be combined with other routing rules to such as sticky sessions to allow for more advanced used cases. Using the basics of traffic weighting alongside other routing features, A/B testing or canary deployments can be achieved quickly.

Beyond the routing rules, Istio also provides features for observability and security making it a wholistic approach to traffic management and inspection. Check out the Istio Tag on the Blog, for more items in this series.