Multicluster 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.

Also ensure you have the correct context names set in your environment:

REMOTE_CONTEXT1=cluster_1's_context_here

Controlling cross-cluster traffic

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



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

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

Once you apply this resource to cluster-1, 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):