What is it?

Istio is a kubernetes focused service mesh capable of adding many additional features to Kubernetes request routing by adding envoy proxy based sidecars to all the pods within the mesh. Requests in or out of these pods then can follow additional routing rules specified by things like Virtual Services, Destination Rules, and Service Entries, among others. This document assumes you have at least some knowledge of Istio and how it functions. I suggest you give their getting started page a quick shot and see what you can do!

With that out of the way, let me describe specifically what Consistent Hash Routing is used for with an example. Let's say you've got a few services in your cluster. Following the typical API patterns, we've got the following:

  • An Ingress into the cluster
  • A Frontend Webserver running multiple pods
  • An API the Webserver calls, also running multiple pods

Now, let's imagine our ingress sends traffic direct to our webserver pods, they typically render the page and in doing so, have to call down to the API for information. The API does whatever it needs to get the answer back, be it DB queries, DynamoDB calls, etc.

The Setup

The YAML

  • Virtual Service
 apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: egress
spec:
  gateways:
  - mesh
  hosts:
  - pds.forrent.com
  http:
  - route:
    - destination:
        host: echoer.echoer-one.svc.cluster.local
  • Destination Rule
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: pds-egress
spec:
  exportTo:
  - "*"
  host: echoer.echoer-one.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      consistentHash:
        httpHeaderName: request-hash
  • Service Entry
  • Headless Service
  • StatefulSet