Traffic Route

This policy allows us to configure routing rules for L4 traffic running in our Mesh. This policy provides support for weighted routing and can be used to implement versioning across our services as well as deployment strategies like blue/green and canary.

TrafficRoute must select the data plane proxies to route the connection between them.

Kuma also supports locality aware load balancing.

Default TrafficRoute

The control plane creates a default TrafficRoute every time the new Mesh is created. The default TrafficRoute enables the traffic between all the services in the mesh.

  1. apiVersion: kuma.io/v1alpha1
  2. kind: TrafficRoute
  3. mesh: default
  4. metadata:
  5.   name: route-all-default
  6. spec:
  7.   sources:
  8.     - match:
  9.         kuma.io/service: '*'
  10.   destinations:
  11.     - match:
  12.         kuma.io/service: '*'
  13.   conf:
  14.     loadBalancer:
  15.       roundRobin: {}
  16.     split:
  17.       - weight: 100
  18.         destination:
  19.           kuma.io/service: '*'
  1. type: TrafficRoute
  2. name: route-all-default
  3. mesh: default
  4. sources:
  5.   - match:
  6.       kuma.io/service: '*'
  7. destinations:
  8.   - match:
  9.       kuma.io/service: '*'
  10. conf:
  11.   loadBalancer:
  12.     roundRobin: {}
  13.   split:
  14.     - weight: 100
  15.       destination:
  16.         kuma.io/service: '*'

Usage

By default when a service makes a request to another service, Kuma will round robin the request across every data plane proxy belogning to the destination service. It is possible to change this behavior by using this policy, for example:

  1. apiVersion: kuma.io/v1alpha1
  2. kind: TrafficRoute
  3. mesh: default
  4. metadata:
  5.   name: route-example
  6. spec:
  7.   sources:
  8.     - match:
  9.         kuma.io/service: backend_default_svc_80
  10.   destinations:
  11.     - match:
  12.         kuma.io/service: redis_default_svc_6379
  13.   conf:
  14.     split:
  15.       - weight: 90
  16.         destination:
  17.           kuma.io/service: redis_default_svc_6379
  18.           version: '1.0'
  19.       - weight: 10
  20.         destination:
  21.           kuma.io/service: redis_default_svc_6379
  22.           version: '2.0'

We will apply the configuration with kubectl apply -f [..].

  1. type: TrafficRoute
  2. name: route-example
  3. mesh: default
  4. sources:
  5.   - match:
  6.       kuma.io/service: backend
  7. destinations:
  8.   - match:
  9.       kuma.io/service: redis
  10. conf:
  11.   split:
  12.     - weight: 90
  13.       destination:
  14.         kuma.io/service: redis
  15.         version: '1.0'
  16.     - weight: 10
  17.       destination:
  18.         kuma.io/service: redis
  19.         version: '2.0'

We will apply the configuration with kumactl apply -f [..] or via the HTTP API.

In this example the TrafficRoute policy assigns a positive weight of 90 to the version 1.0 of the redis service and a positive weight of 10 to the version 2.0 of the redis service.

Note that routing can be applied not just on the automatically provisioned service Kuma tag, but on any other tag that we may want to add to our data plane proxies (like version in the example above).

Kuma utilizes positive weights in the TrafficRoute policy and not percentages, therefore Kuma does not check if the total adds up to 100. If we want to stop sending traffic to a destination service we change the weight for that service to 0.

Load balancer types

There are different load balancing algorithms that can be used to determine how traffic is routed to the destinations. By default TrafficRoute uses the roundRobin load balancer, but more options are available:

  • roundRobin is a simple algorithm in which each available upstream host is selected in round robin order.

    Example:

    1. loadBalancer:
    2.   roundRobin: {}

  • leastRequest uses different algorithms depending on whether the hosts have the same or different weights. It has a single configuration field choiceCount, which denotes the number of random healthy hosts from which the host with the fewer active requests will be chosen.

    Example:

    1. loadBalancer:
    2.   leastRequest:
    3.     choiceCount: 8

  • ringHash implements consistent hashing to the upstream hosts. It has the following fields:

    • hashFunction the hash function used to hash the hosts onto the ketama ring. Can be XX_HASH or MURMUR_HASH_2.
    • minRingSize minimum hash ring size.
    • maxRingSize maximum hash ring size.

    Example:

    1. loadBalancer:
    2.   ringHash:
    3.     hashFunction: "MURMUR_HASH_2"
    4.     minRingSize: 64
    5.     maxRingSize: 1024

  • random selects a random available host.

    Example:

    1. loadBalancer:
    2.   random: {}

  • maglev implements consistent hashing to upstream hosts

    Example:

    1. loadBalancer:
    2.   maglev: {}