Webinar Recap – Multi-Cluster API Gateway Patterns

Designing, building and operating applications for cloud-native infrastructure that are resilient, scalable, secure, and meet compliance and IT objectives gets complicated. Another wrinkle for the organizations with which we work is the fact they need to run across a hybrid deployment footprint, not just Kubernetes. Add to that the need to shape, manage, and secure the traffic coming into the environment across these different workloads and clusters.

In these past few webinars, we’ve spent time focusing on addressing different aspects of multi-cluster deployments with and without service mesh, how to deploy and operate them, and how to configure and manage the application networks across them. You can watch the replays and review the Q&A from the talks here.

In this webinar, Christian Posta discussed deployment patterns, configurations, global traffic routing policies and more for scalable, highly available, and resilient application environments.  He compared the tradeoffs between the different patterns for consideration and guidance for implementation and operations. 

Watch the replay here

Highlights from the Q&A

Can Gloo Federation be used for a failover scenario due to a non-deployment of a service irrespective of the health of the service that the traffic is being failed over to?

When you configure the global routing rules, you can specify an order of primary and secondary services. In a later release you’ll be able to leverage locality more to set routing rules by cluster. For example, set a route order as cluster 1, then cluster 2 and if the service does not exist in cluster 1 then it automatically routes to cluster 2.

What is the recommended deployment for Gloo Federation? Can I run the Gloo Federation control plane on the same cluster as a Gloo instance or should it be in its own VM or..? 

For production environments, the preferred approach is to run Gloo Federation in its own cluster to improve your fault tolerance but you can deploy it co-located on the same cluster with a Gloo instance and your applications. In case the cluster goes down for any reason, you don’t want that to also take down the Gloo-Fed management plane. 

What are the sizing recommendations for the Gloo Federation cluster?

When considering sizing for the API gateway environment, you’ll want to consider the following variables for the data plane and control planes. For the data plane you want to consider are the capabilities needed for the proxy as that can consume a lot of CPU cycles. For the control plane you want to consider the number of clusters and the amount of configuration you have as the control plane is more memory intensive to perform the calculations of the different configurations and what get deployed to which clusters.

Is Gloo Federation available in open source or enterprise?

Gloo Federation is part of the enterprise version of Gloo. You can try Gloo enterprise with federation with an evaluation license, request one here. 

Is WebAssembly ready to run in a production environment?

WebAssembly has been around since 2015 and recently the Envoy community has been working to integrate WebAssembly support into the proxy. Currently this work is happening in a separate build as the community continues to stabilize it before it is merged into the upstream open source. Istio includes the envoy-wasm version of the proxy for their sidecars proxies so while it is not officially GA by Envoy, the functionality is field testing time through the use of Istio. You can also get a great developer experience for WebAssembly with Envoy with WebAssembly Hub and wasme CLI.

Download the presentation

Learn more

• About Gloo and Gloo Federation
• Try Gloo in an online tutorial or request a trial
• Register for an upcoming event
• Questions? Join the community