How to configure traffic routing

Installing the demo program

If you haven’t installed the demo program yet, Please refer to Quick Start to install Aeraki, Istio, and the demo.

After installation, you can see that the following two NSs have been added to the cluster, and the Dubbo and Thrift demo applications are installed in these two NSs. You can choose either of them to test.

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

Request-level load balancing

Istio uses TCP proxy to proxy non-HTTP client requests, and all requests from the same client TCP connection are sent to a single server instance. This leads to some problems: when clients use long connections, multiple server instances do not receive a balanced number of requests. Furthermore, when the server side is overloaded, the incoming requests that come into the existing connections can’t be redistributed to new server instances even though more instances are added to the pool of the server cluster to share the load.

Aeraki supports layer-7(request level) load balancing for any protocols developed based on MetaProtocol, so the client-side sidecar proxy sends requests evenly to these two server instances, enven though the client is using a single long TCP connection to connect to the server.

Let’s use the aerakictl command to view the client-side log, you’ll see that client requests are sent to two server pods in turn, v1 and v2, like the following:

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

Routes requests to a specified version based on arbitrary properties

MetaProtocol supports very flexible route matching conditions, any property that can be exacted from the protocol packet at decodding phase can be used for route matching conditions.

Note: Aeraki will create Listeners according to the VIP of the service, and each service will have its own Listener, which avoids the routing table expansion problem caused by multiple services on the same port of the HTTP protocol, and the routing table only contains the routing information related to this service, thus greatly improving the route matching efficiency.

Create a MetaRouter routing rule that routes the request to v1.

``` kubectl apply -f- Last modified May 9, 2022: Update routing.md (cede715)