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:
- Gloo Mesh is installed and running on the
mgmt-cluster
- Istio is installed on both the
mgmt-cluster
andremote-cluster
clusters - Both
mgmt-cluster
andremote-cluster
clusters are registered with Gloo Mesh - The
bookinfo
app is installed into the two clusters
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/v1
kind: TrafficPolicy
metadata:
namespace: gloo-mesh
name: simple
spec:
destinationSelector:
- kubeServiceRefs:
services:
- clusterName: mgmt-cluster
name: reviews
namespace: bookinfo
policy:
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/v1
kind: TrafficPolicy
metadata:
namespace: gloo-mesh
name: simple
spec:
destinationSelector:
- kubeServiceRefs:
services:
- clusterName: mgmt-cluster
name: reviews
namespace: bookinfo
policy:
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:
- Any traffic destined for the reviews service in the management plane cluster should be split across several different destinations
- 25% of traffic gets split between the v1 and v2 instances of the reviews service in the management plane cluster
- 75% of traffic gets sent to the v3 instance of the reviews service on the remote cluster
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):