Managing Request-Level Load Balancing, Routing, and Traffic Splitting with Aeraki Mesh MetaRouter

Aeraki Mesh, a CNCF sandbox project, enables seven‑layer traffic management for any protocol within a service mesh. This tutorial walks through installing the Aeraki demo applications, which provide Dubbo and Thrift services in separate namespaces.

After installation, the namespaces meta-dubbo and meta-thrift become active, each containing a sample application built on MetaProtocol.

➜  ~ kubectl get ns|grep meta
meta-dubbo        Active   16m
meta-thrift       Active   16m

Istio’s TCP proxy forwards all requests from a single client TCP connection to the same server, which can cause imbalance when long‑lived connections are used. Aeraki’s MetaRouter provides request‑level (seven‑layer) load balancing, automatically distributing requests across server versions without additional configuration.

➜  ~ aerakictl_app_log client meta-thrift -f --tail 10
Hello Aeraki, response from thrift-sample-server-v2-6d5bcc885-wglpc/172.17.0.93
Hello Aeraki, response from thrift-sample-server-v1-5c8476684-hr8hh/172.17.0.92
...

MetaProtocol allows flexible routing based on any attribute extracted from the protocol payload. A MetaRouter rule can route all requests matching a specific method to a designated version:

kubectl apply -f- <<EOF
apiVersion: metaprotocol.aeraki.io/v1alpha1
kind: MetaRouter
metadata:
  name: test-metaprotocol-thrift-route
  namespace: meta-thrift
spec:
  hosts:
    - thrift-sample-server.meta-thrift.svc.cluster.local
  routes:
    - name: v1
      match:
        attributes:
          method:
            exact: sayHello
      route:
        - destination:
            host: thrift-sample-server.meta-thrift.svc.cluster.local
            subset: v1
EOF

After applying the rule, all client requests are routed to the v1 subset:

➜  ~ aerakictl_app_log client meta-thrift -f --tail 10
Hello Aeraki, response from thrift-sample-server-v1-5c8476684-hr8hh/172.17.0.92
...

Traffic splitting can be achieved by defining weighted clusters in a MetaRouter rule:

kubectl apply -f- <<EOF
apiVersion: metaprotocol.aeraki.io/v1alpha1
kind: MetaRouter
metadata:
  name: test-metaprotocol-thrift-route
  namespace: meta-thrift
spec:
  hosts:
    - thrift-sample-server.meta-thrift.svc.cluster.local
  routes:
    - name: traffic-split
      match:
        attributes:
          method:
            exact: sayHello
      route:
        - destination:
            host: thrift-sample-server.meta-thrift.svc.cluster.local
            subset: v1
          weight: 20
        - destination:
            host: thrift-sample-server.meta-thrift.svc.cluster.local
            subset: v2
          weight: 80
EOF

Client logs show requests distributed according to the defined 20/80 split:

➜  ~ aerakictl_app_log client meta-thrift -f --tail 10
Hello Aeraki, response from thrift-sample-server-v2-6d5bcc885-wglpc/172.17.0.93
Hello Aeraki, response from thrift-sample-server-v1-5c8476684-hr8hh/172.17.0.92
...

Under the hood, Aeraki injects a MetaProtocol Proxy listener into the sidecar, configuring it via an internal RDS server. The proxy translates MetaRouter rules into MetaProtocol Proxy routing rules, which can be inspected with:

aerakictl_sidecar_config client meta-thrift | fx

The exported configuration reveals the weighted route configuration, including the match on the method attribute and the weight distribution between v1 and v2 clusters.

Overall, the tutorial provides step‑by‑step commands, YAML definitions, and insight into how Aeraki enables fine‑grained traffic control for non‑HTTP protocols within a Kubernetes‑based service mesh.