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.

  1. ➜  ~ kubectl get ns|grep meta
  2. meta-dubbo        Active   16m
  3. meta-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:

  1. ➜  ~ aerakictl_app_log client meta-thrift -f --tail 10
  2. Hello Aeraki, response from thrift-sample-server-v2-6d5bcc885-wglpc/172.17.0.93
  3. Hello Aeraki, response from thrift-sample-server-v1-5c8476684-hr8hh/172.17.0.92
  4. Hello Aeraki, response from thrift-sample-server-v2-6d5bcc885-wglpc/172.17.0.93
  5. Hello Aeraki, response from thrift-sample-server-v1-5c8476684-hr8hh/172.17.0.92
  6. Hello Aeraki, response from thrift-sample-server-v2-6d5bcc885-wglpc/172.17.0.93
  7. Hello 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.

  1. kubectl apply -f- <<EOF
  2. apiVersion: metaprotocol.aeraki.io/v1alpha1
  3. kind: MetaRouter
  4. metadata:
  5.   name: test-metaprotocol-thrift-route
  6.   namespace: meta-thrift
  7. spec:
  8.   hosts:
  9.     - thrift-sample-server.meta-thrift.svc.cluster.local
  10.   routes:
  11.     - name: v1
  12.       match:
  13.         attributes:
  14.           method:
  15.             exact: sayHello
  16.       route:
  17.         - destination:
  18.             host: thrift-sample-server.meta-thrift.svc.cluster.local
  19.             subset: v1
  20. EOF

Using the aerakictl command to view the client-side log, you can see that all requests from the client are routed to the v1 version.

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

Traffic splitting

Use MetaRouter routing rules to send client requests to different versions of the service in specified proportions.

  1. kubectl apply -f- <<EOF
  2. apiVersion: metaprotocol.aeraki.io/v1alpha1
  3. kind: MetaRouter
  4. metadata:
  5.   name: test-metaprotocol-thrift-route
  6.   namespace: meta-thrift
  7. spec:
  8.   hosts:
  9.     - thrift-sample-server.meta-thrift.svc.cluster.local
  10.   routes:
  11.     - name: traffic-split
  12.       match:
  13.         attributes:
  14.           method:
  15.             exact: sayHello
  16.       route:
  17.         - destination:
  18.             host: thrift-sample-server.meta-thrift.svc.cluster.local
  19.             subset: v1
  20.           weight: 20
  21.         - destination:
  22.             host: thrift-sample-server.meta-thrift.svc.cluster.local
  23.             subset: v2
  24.           weight: 80
  25. EOF

Using the aerakictl command to view the client-side log, you can see that the client requests were sent to v1 and v2 at the specified weight set in MetaRouter.

  1. ➜  ~ aerakictl_app_log client meta-thrift -f --tail 10
  2. Hello Aeraki, response from thrift-sample-server-v2-6d5bcc885-wglpc/172.17.0.93
  3. Hello Aeraki, response from thrift-sample-server-v2-6d5bcc885-wglpc/172.17.0.93
  4. Hello Aeraki, response from thrift-sample-server-v2-6d5bcc885-wglpc/172.17.0.93
  5. Hello Aeraki, response from thrift-sample-server-v2-6d5bcc885-wglpc/172.17.0.93
  6. Hello Aeraki, response from thrift-sample-server-v2-6d5bcc885-wglpc/172.17.0.93
  7. Hello Aeraki, response from thrift-sample-server-v2-6d5bcc885-wglpc/172.17.0.93
  8. Hello Aeraki, response from thrift-sample-server-v2-6d5bcc885-wglpc/172.17.0.93
  9. Hello Aeraki, response from thrift-sample-server-v2-6d5bcc885-wglpc/172.17.0.93
  10. Hello Aeraki, response from thrift-sample-server-v1-6d5bcc885-wglpc/172.17.0.93
  11. Hello Aeraki, response from thrift-sample-server-v1-5c8476684-hr8hh/172.17.0.92

Understand what happened

In the configuration sent to the Sidecar Proxy, Aeraki sets up the MetaProtocol Proxy in the FilterChain of the Outbound Listener corresponding to the service, and specifies Aeraki as the RDS server in the MetaProtocol Proxy configuration.

Aeraki translates MetaRouter to MetaProtocol route configuration, and then distributes them to the MetaProtocol Proxy through Aeraki’s built-in RDS server.

The configuration of the sidecar proxy can be viewed with the following command:

  1. aerakictl_sidecar_config client meta-thrift |fx

The configuration of the MetaProtocol Proxy in the Outbound Listener of the Thrift service is shown below.

  1. {
  2.  "name": "envoy.filters.network.meta_protocol_proxy",
  3.  "typed_config": {
  4.   "@type": "type.googleapis.com/udpa.type.v1.TypedStruct",
  5.   "type_url": "type.googleapis.com/aeraki.meta_protocol_proxy.v1alpha.MetaProtocolProxy",
  6.   "value": {
  7.    "stat_prefix": "outbound|9090||thrift-sample-server.meta-thrift.svc.cluster.local",
  8.    "application_protocol": "thrift",
  9.    "rds": {
  10.     "config_source": {
  11.      "api_config_source": {
  12.       "api_type": "GRPC",
  13.       "grpc_services": [
  14.        {
  15.         "envoy_grpc": {
  16.          "cluster_name": "aeraki-xds"
  17.         }
  18.        }
  19.       ],
  20.       "transport_api_version": "V3"
  21.      },
  22.      "resource_api_version": "V3"
  23.     },
  24.     "route_config_name": "thrift-sample-server.meta-thrift.svc.cluster.local_9090"
  25.    },
  26.    "codec": {
  27.     "name": "aeraki.meta_protocol.codec.thrift"
  28.    },
  29.    "meta_protocol_filters": [
  30.     {
  31.      "name": "aeraki.meta_protocol.filters.router"
  32.     }
  33.    ]
  34.   }
  35.  }
  36. }

You can also view the RDS routing information that is currently in effect in the Proxy in the exported file, as follows.

  1. {
  2. @type": "type.googleapis.com/aeraki.meta_protocol_proxy.admin.v1alpha.RoutesConfigDump",
  3. dynamic_route_configs": [
  4. {
  5.  "version_info": "1641896797",
  6.  "route_config": {
  7.   "@type": "type.googleapis.com/aeraki.meta_protocol_proxy.config.route.v1alpha.RouteConfiguration",
  8.   "name": "thrift-sample-server.meta-thrift.svc.cluster.local_9090",
  9.   "routes": [
  10.    {
  11.     "name": "traffic-split",
  12.     "match": {
  13.      "metadata": [
  14.       {
  15.        "name": "method",
  16.        "exact_match": "sayHello"
  17.       }
  18.      ]
  19.     },
  20.     "route": {
  21.      "weighted_clusters": {
  22.       "clusters": [
  23.        {
  24.         "name": "outbound|9090|v1|thrift-sample-server.meta-thrift.svc.cluster.local",
  25.         "weight": 20
  26.        },
  27.        {
  28.         "name": "outbound|9090|v2|thrift-sample-server.meta-thrift.svc.cluster.local",
  29.         "weight": 80
  30.        }
  31.       ],
  32.       "total_weight": 100
  33.      }
  34.     }
  35.    }
  36.   ]
  37.  },
  38.  "last_updated": "2022-01-11T10:26:37.357Z"
  39. }

Last modified May 9, 2022: Update routing.md (cede715)