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. Service Mesh Hub 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 management-plane-context cluster between reviews-v1, reviews-v2, and reviews-v3 running in the remote-cluster-context cluster.


apiVersion: networking.zephyr.solo.io/v1alpha1
kind: TrafficPolicy
metadata:
  namespace: service-mesh-hub
  name: simple
spec:
  destinationSelector:
    serviceRefs:
      services:
        - cluster: management-plane
          name: reviews
          namespace: default
  trafficShift:
    destinations:
      - destination:
          cluster: new-remote-cluster
          name: reviews
          namespace: default
        weight: 75
      - destination:
          cluster: management-plane
          name: reviews
          namespace: default
        weight: 15
        subset:
          version: v1
      - destination:
          cluster: management-plane
          name: reviews
          namespace: default
        weight: 10
        subset:
          version: v2

kubectl apply --context management-plane-context -f - << EOF
apiVersion: networking.zephyr.solo.io/v1alpha1
kind: TrafficPolicy
metadata:
  namespace: service-mesh-hub
  name: simple
spec:
  destinationSelector:
    serviceRefs:
      services:
        - cluster: management-plane
          name: reviews
          namespace: default
  trafficShift:
    destinations:
      - destination:
          cluster: new-remote-cluster
          name: reviews
          namespace: default
        weight: 75
      - destination:
          cluster: management-plane
          name: reviews
          namespace: default
        weight: 15
        subset:
          version: v1
      - destination:
          cluster: management-plane
          name: reviews
          namespace: default
        weight: 10
        subset:
          version: v2
EOF

Once you apply this resource to the management-plane-context 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, but, 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 Service Mesh Hub” video series: