The Ops Community ⚙️

Cover image for Traffic shaping with Istio and Kubernetes
Daniele Polencic
Daniele Polencic

Posted on

Traffic shaping with Istio and Kubernetes

You can roll out an app only to a subset of your users in Kubernetes using canary releases with Istio, Kiali and the Gateway API.

Let's start by looking at an example.

The current cluster has three apps:

  1. A backend that exposes an API at version v1.
  2. Another app on version v2.
  3. A frontend component that consumes the API.

Two apps deployed in a Kubernetes cluster

Ideally, the frontend should consume 80% of requests from v1 and only 20% from v2.

But how?

You can use a Service Mesh for that.

Splitting traffic with a Service mesh

As soon as you install the service mesh, each pod in the cluster gains an extra container.

The container proxies all the outgoing and incoming requests.

An Envoy proxies intercepting all outgoing and incoming requests

The proxy is automatically injected using a mutating webhook.

Before the pod is stored in etcd, the YAML definition is modified, and the proxy is injected.

A mutating webhook automatically injects the proxy in the pod

A service mesh is helpful because you can:

  • Monitor metrics.
  • Trace dependencies between components.
  • Decide traffic splits.

Why you might want to use use a service mesh

I generated some traffic to test it and used Kiali to trace it.

It automatically mapped all the components and the direction of the traffic.

All without any hints from my side!

What about the canary release though?

Mapping microservices with Kiali

You can use a service mesh to fine-tune how much traffic each app consumes.

To test it, I created an 80-20 split between the two backends.

In this example, I'm using an HTTPRoute:

HTTPRoute Custom Resource Definition

HTTPRoute is an object part of the Gateway API that lets you gradually increase and decrease the traffic and which you can use to transition from an 80-20 split to 0-100.

Demo of splitting traffic in Kubernetes

Service meshes can also:

  1. Help you roll out shadow releases.
  2. Encrypt intrapod traffic.
  3. Mirror traffic between cluster.
  4. Inspect and rewrite traffic.
  5. Enforce policies.
  6. Inject faults to test the resilience.

And more!

Which one should you use?

At Learnk8s we've put together a spreadsheet to compare them.

And finally, if you've enjoyed this thread, you might also like:

Latest comments (0)