Multicluster routing
Route incoming requests to services across multiple clusters.
You can easily set up intelligent multicluster routing for active-active and active-passive workloads in your environment by using virtual destinations. With virtual destinations, you can define unique internal hostnames for apps that are spread across multiple clusters, and route to these apps via these hostnames.
For more information, see the following resources:
- Multicluster routing with virtual destinations concept doc
- Gloo Mesh Gateway API docs for virtual destinations
When Gloo Mesh Gateway routes requests across clusters through the east-west gateway, the communication to the east-west gateway is secured with mTLS. However, when your app is deployed without Istio sidecars, the east-west gateway uses plaintext to route the request to your app. To secure communications to your apps with mTLS instead, consider using Gloo Mesh Enterprise alongside Gloo Mesh Gateway to set up an Istio service mesh for your workloads. You can additionally use Gloo Mesh Enterprise to route from service-to-service within your cluster environment by using mTLS.
Before you begin
This guide assumes that you use the same names for components like clusters, workspaces, and namespaces as in the getting started. If you have different names, make sure to update the sample configuration files in this guide.
- Set up Gloo Mesh Gateway in a single cluster.
- Follow the other guides in this routing section to plan your routing table setup. For example, you might check out the path matching guide to decide how to match the incoming requests to your service paths, the redirect guide to set up any path or host rewrites, or the sub-table delegation guide to nest and sort multiple route tables. Note: Be sure that each route for one host is unique, such as by using prefix matching to determine which requests to the host should be forwarded to which destinations.
Set up multicluster routing for north-south traffic
To route incoming requests from your ingress gateway to an app that is spread across clusters based on locality, you create a virtual destination for your multicluster app, and a route table that forwards traffic to that virtual destination.
When you apply the Gloo custom resources in this guide to your cluster, Gloo Mesh Gateway automatically checks the configuration against validation rules and value constraints. You can also run a pre-admission validation check by using the meshctl x validate resources
command. For more information, see the resource validation overview and the CLI command reference.
If you have not already, create a virtual gateway in the cluster where you deployed an instance of your global app. This virtual gateway selects the default Istio ingress gateway, which routes incoming traffic (north-south) to your service mesh. For more information about setting up virtual gateways, see the gateway listener guides.
kubectl apply -f- <<EOF apiVersion: networking.gloo.solo.io/v2 kind: VirtualGateway metadata: name: istio-ingressgateway namespace: gloo-mesh spec: workloads: # Matches on 'spec.selector' labels for the ingress gateway service - selector: labels: istio: ingressgateway listeners: # The port the ingress gateway listens on for incoming requests to route - port: number: 80 http: {} EOF
In each cluster where you deployed an instance of your global app, ensure that the app is exposed by a Kubernetes service. Make sure that you use the same label for your services as this label serves as the selector to later identify all the services across your clusters that make up your global app. In this example, the label
app: global-app
is used. The service listens on port 3456 and forwards requests to port 9080.apiVersion: v1 kind: Service metadata: labels: app: global-app name: global-app namespace: global spec: ports: - name: http port: 3456 protocol: TCP targetPort: 9080 type: ClusterIP
Create a virtual destination resource and define a unique hostname that the virtual gateway can use to send requests to. This virtual destination is configured to listen for incoming traffic on the internal-only, arbitrary hostname
app.internal.com:8080
. Incoming requests can then be routed to any service instances with the labelapp: global-app
on port 9080. Note that because virtual destinations are dynamic, the ingress gateway load balances the request across healthy app instance.kubectl apply -n global -f- <<EOF apiVersion: networking.gloo.solo.io/v2 kind: VirtualDestination metadata: name: global-app-vd namespace: global spec: hosts: # Arbitrary, internal-only hostname assigned to the endpoint - app.internal.com ports: - number: 8080 protocol: HTTP targetPort: number: 9080 services: - labels: app: global-app EOF
Create a route table to route requests to your services. A route table allows you to define how requests to endpoints should be routed. In this example route table, all requests to the
/global-app
path are routed to theglobal-app
virtual destination.kubectl apply -n global -f- <<EOF apiVersion: networking.gloo.solo.io/v2 kind: RouteTable metadata: name: global-app-routes namespace: global spec: # Applies to any host; can indicate a specific domain, like example.com hosts: - '*' # Selects the virtual gateway you previously created virtualGateways: - name: istio-ingressgateway namespace: bookinfo cluster: ${CLUSTER_NAME} http: # Route for the global-app service - name: global-app # Prefix matching matchers: - uri: prefix: /global-app # Forwarding directive forwardTo: destinations: # Reference to the virtual destination for the global-app svcs - ref: name: global-app-vd kind: VIRTUAL_DESTINATION port: number: 8080 EOF
Get the external address of your ingress gateway.
export INGRESS_GW_ADDRESS=$(kubectl get svc -n gloo-mesh-gateways istio-ingressgateway -o jsonpath="{.status.loadBalancer.ingress[0]['hostname','ip']}") echo $INGRESS_GW_ADDRESS
Test the route to your app by curling the ingress gateway address and app path. For example, the following command appends
/global-app
for the sample app.curl http://$INGRESS_GW_ADDRESS/global-app
Next steps
Now that you have basic routes set up, you can explore more advanced networking scenarios.
- Other routing actions: For HTTP routes, you can set up other actions besides forwarding requests. For example, you might check out the prefix matching guide to decide how to match the incoming requests to your service paths, the redirect guide to set up any path or prefix rewrites, or the sub-table delegation guide to nest and sort multiple route tables.
- Additional route settings: Configure additional route settings, such as weighted routing to version subsets or adding and removing headers.
- Policies: For more control over traffic behavior, apply traffic management, security, or resiliency policies to your service or route, such as for outlier detection, failover, fault injection, or keep alive connections.