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:
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.
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.localapiVersion: 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