Multi-cluster Traffic

In the previous guides, we federated multiple meshes and established a shared root CA for a shared identity domain. Now that we have a logical VirtualMesh, we need a way to establish traffic policies across the multiple meshes, without treating each of them individually. Gloo Mesh helps by establishing a single, unified API that understands the logical VirtualMesh construct.

Before you begin

To illustrate these concepts, we will assume that:

Be sure to review the assumptions and satisfy the pre-requisites from the Guides top-level document.

Controlling cross-cluster traffic

We will now perform a multi-cluster traffic split, splitting traffic from the productpage service in the mgmt-cluster cluster between reviews-v1, reviews-v2, and reviews-v3 running in the remote-cluster cluster.


apiVersion: networking.mesh.gloo.solo.io/v1alpha2
kind: TrafficPolicy
metadata:
  namespace: gloo-mesh
  name: simple
spec:
  destinationSelector:
  - kubeServiceRefs:
      services:
        - clusterName: mgmt-cluster
          name: reviews
          namespace: bookinfo
  trafficShift:
    destinations:
      - kubeService:
          clusterName: remote-cluster
          name: reviews
          namespace: bookinfo
        weight: 75
      - kubeService:
          clusterName: mgmt-cluster
          name: reviews
          namespace: bookinfo
          subset:
            version: v1
        weight: 15
      - kubeService:
          clusterName: mgmt-cluster
          name: reviews
          namespace: bookinfo
          subset:
            version: v2
        weight: 10

kubectl apply --context $MGMT_CONTEXT -f - << EOF
apiVersion: networking.mesh.gloo.solo.io/v1alpha2
kind: TrafficPolicy
metadata:
  namespace: gloo-mesh
  name: simple
spec:
  destinationSelector:
  - kubeServiceRefs:
      services:
        - clusterName: mgmt-cluster
          name: reviews
          namespace: bookinfo
  trafficShift:
    destinations:
      - kubeService:
          clusterName: remote-cluster
          name: reviews
          namespace: bookinfo
        weight: 75
      - kubeService:
          clusterName: mgmt-cluster
          name: reviews
          namespace: bookinfo
          subset:
            version: v1
        weight: 15
      - kubeService:
          clusterName: mgmt-cluster
          name: reviews
          namespace: bookinfo
          subset:
            version: v2
        weight: 10
EOF

Once you apply this resource to the mgmt-cluster cluster, you should occasionally see traffic being routed to the reviews-v3 service, which will produce red-colored stars on the product page.

To go into slightly more detail here: The above TrafficPolicy says that:

We have successfully set up multi-cluster traffic across our application! Note that this has been done transparently to the application. The application can continue talking to what it believes is the local instance of the service. Behind the scenes we have instead routed that traffic to an entirely different cluster.

Note that this is interesting in its own right, that we have easily achieved multi-cluster communication, but also in other scenarios like in fast disaster recovery: We can quickly route traffic to healthy instances of a service in an entirely different data center.

See it in action

Check out “Part Four” of the “Dive into Gloo Mesh” video series (note that the video content reflects Gloo Mesh v0.6.1):