When you forward requests to a Kubernetes service, virtual destination, or external service, you can configure additional settings in your route table. Review the following sections to set a default destination, route to an application subset, or assign weights to app instances.

Set a default destination

Set a default destination in a route table so that multiple routes can be easily assigned to that destination.

For example, you might want to designate multiple routes for one destination, for the purpose of assigning certain policies to certain routes. Instead of typing out the same destination definition in each of the routes, you can instead define the destination as the default, and leave the forwardTo directive in each route empty. Note that any routes in the route table that do not specify a destination will forward traffic to the default destination.

In this example route table, the information for the ratings destination is defined in the spec.defaultDestination field, rather than repeated in each http route. This way, the two routes can automatically reference the ratings definition.

  apiVersion: networking.gloo.solo.io/v2
kind: RouteTable
metadata:
  name: example
  namespace: bookinfo
spec:
  defaultDestination:
    port:
      number: 9080
    ref:
      name: ratings
      namespace: bookinfo
      cluster: ${REMOTE_CLUSTER1}
  hosts:
  - 'ratings.bookinfo.svc.cluster.local'
  http:
  - forwardTo: {}
    labels:
      "no": auth
    matchers:
    - headers:
      - name: noauth
        value: "true"
    name: ratings-no-auth
  - forwardTo: {}
    labels:
      route: ratings
    name: ratings

Weighted routing to an application subset

If you are testing multiple versions of your app within your mesh, you can route to each version by using the version numbers. Additionally, you can optionally assign weights to each version of the app to determine the load or requests that each version receives.

Review the following examples:

  • HTTP example for a weighted subsets that send traffic to two versions.
  • TCP example for splitting TCP traffic to different httpbin and hello world apps on the same host.

HTTP example

Say that your app deployment for each version contains the app: myapp label, and labels such as version: v1 and version: v2. In the route table, you add references to the both versions of the app, and specify the version labels in the subset field of each reference section.

Additionally, this example route table specifies an optional weight for each version of the app. 75% of traffic requests to the /myapp are directed to v1, and 25% of traffic requests are directed to v2. Weighted routing can be useful in scenarios such as controlled rollouts to slowly move traffic from an older to a newer version of your app.

  apiVersion: networking.gloo.solo.io/v2
kind: RouteTable
metadata:
  name: myapp-routes
  namespace: global
spec:
  hosts:
    - 'myapp.global.svc.cluster.local'
  http:
    # Route for the myapp service
    - name: myapp
      # Prefix matching
      matchers:
      - uri:
          prefix: /myapp
      # Forwarding directive
      forwardTo:
        destinations:
          # Reference to the virtual destination that selects v1 of the myapp service
          - ref:
              name: myapp
            kind: VIRTUAL_DESTINATION
            subset:
              version: v1
            # 75% of request traffic to /myapp
            weight: 75
          # Reference to the virtual destination that selects v2 of the myapp service
          - ref:
              name: myapp
            kind: VIRTUAL_DESTINATION
            subset:
              version: v2
            # 25% of request traffic to /myapp
            weight: 25

TCP weighted example

Use the following steps to set up weighted routing for TCP routes to your hello world app.

Before you begin, complete the prerequisite steps in the Routing guide.

  1. Create a virtual destination resource for your destination app that receives TCP requests from the initiator app. The following virtual destination listens for requests on the helloworld.vd host on TCP port 9000. Then, the virtual destination forwards requests to any app with the label app: helloworld on the tcp port. Note that because virtual destinations are dynamic, the east-west gateway that handles the request routes it to the closest healthy app instance.

      kubectl --context ${REMOTE_CONTEXT1} apply -f - <<EOF
apiVersion: networking.gloo.solo.io/v2
kind: VirtualDestination
metadata:
  annotations:
    cluster.solo.io/cluster: ""
  name: helloworld-global
  namespace: helloworld
spec:
  hosts:
  - helloworld.vd
  ports:
  - number: 9000
    protocol: TCP
    targetPort:
      name: tcp
  services:
  - labels:
      app: helloworld
EOF

  2. Route requests initiated from your initiator app to your destination app by using the virtual destination hostname. The following route table listens for requests from any app with the label app: productpage on the httpbin.httpbin.svc.cluster.local host. Then, it forwards the request to the helloworld-global virtual destination that you created in the previous step. By using weighted subsets, the route table splits the traffic evenly between the v1 app on cluster 1 and v3 app on cluster 3.

      kubectl --context ${REMOTE_CONTEXT1} apply -f - <<EOF
apiVersion: networking.gloo.solo.io/v2
kind: RouteTable
metadata:
  annotations:
    cluster.solo.io/cluster: ""
  name: bookinfo
  namespace: bookinfo
spec:
  hosts:
  - httpbin.httpbin.svc.cluster.local
  tcp:
  - forwardTo:
      destinations:
      - kind: VIRTUAL_DESTINATION
        port:
          number: 9000
        ref:
          name: helloworld-global
          namespace: helloworld
        subset:
          version: v1
        weight: 50
      - kind: VIRTUAL_DESTINATION
        port:
          number: 9000
        ref:
          name: helloworld-global
          namespace: helloworld
        subset:
          version: v3
        weight: 50
    matchers:
    - port: 9000
  workloadSelectors:
  - selector:
      labels:
        app: productpage
EOF

  3. Test the TCP routes from the initiator app to your destination app.

    1. Log into the product page app.
        kubectl -n bookinfo exec -it deploy/productpage-v1 -c netcat --context $REMOTE_CONTEXT1 -- sh
    2. Use the netcat command to test the connection to the hello world app along the TCP route on port 9000.
        echo "Hello" | nc -v httpbin.httpbin.svc.cluster.local 9000
    3. In the response, check that the connection request succeeds and you get a message from either hello-v1 in cluster 1 or hello-v3 in cluster 2.
        Connection to httpbin.httpbin.svc.cluster.local 9000 port [tcp/*] succeeded!
hello-v1 Hello
    4. Close the connection by entering control+c and repeat the previous command a couple times until you see a response from the other hello app.
        Connection to httpbin.httpbin.svc.cluster.local 9000 port [tcp/*] succeeded!
hello-v3 Hello
    5. To log out of the pod, close the connection by entering control+c and then enter exit.

  4. Optional: Clean up the resources that you created.

      kubectl delete -n helloworld vd helloworld-global --context $REMOTE_CONTEXT1
kubectl delete -n bookinfo rt bookinfo --context $REMOTE_CONTEXT1