The setup that is right for you depends on several factors, such as your business requirements, the Service Level Agreements that you have with your customers, or how you want to manage your API Gateway, especially as your environment and the number of clusters grow.

Simple Kubernetes ingress

You can use Gloo Mesh Gateway to configure an ingress gateway proxy as your Kubernetes ingress controller. In this setup, you usually have a single cluster in a single region or availability zone where your apps are running. You use an API Gateway to manage incoming traffic, route requests, and control access to your apps.

Figure: Gloo Mesh Gateway as a simple Kubernetes ingress.
Figure: Gloo Mesh Gateway as a simple Kubernetes ingress.

This setup is a great way to get started with an API Gateway and to explore ways to manage and secure incoming traffic for the apps in your cluster. Because the API Gateway is deployed as a single instance in the same cluster as your workloads, you cannot configure a failover to a different API Gateway or cluster in the case of an outage.

Multiple gateways in the same cluster

To make a single cluster API Gateway setup more resilient, you can deploy multiple API Gateways to the same cluster. If one API Gateway is not available, you can fail over to the other API Gateway. You can also dedicate one API Gateway to manage traffic for a specific app or a subset of your apps.

Figure: Multiple Gloo Mesh Gateway instances in the same cluster.
Figure: Multiple Gloo Mesh Gateway instances in the same cluster.

With this setup, you can account for local API Gateway failures and optimize the routing and load balancing for apps in your cluster. However, because the API Gateways and workloads share the same cluster, you cannot protect your apps from a regional outage or a failure in your availability zone. Adding more API Gateways to the cluster also increases the management overhead and the risk of configuration drift.

Replicate the single cluster setup across regions or availability zones

To account for regional failures or network outages in your availability zone, you can replicate your single cluster setup across other regions and availability zones, and add the IP addresses of your API Gateways to the same DNS entry. This setup lets you configure both an active-active or active-passive high availability approach.

With an active-active approach, both clusters and API Gateways are actively serving incoming network traffic and requests are load balanced between clusters. If one API Gateway or availability zone experiences a failure, the other API Gateway and zone take over the load. In an active-passive approach, one API Gateway manages the entire incoming traffic while the other cluster is in a standby mode. Only when the active cluster or API Gateway fails, the other API Gateway and cluster are activated, and start serving incoming traffic.

Figure: Replicate the single cluster setup across regions or availability zones.
Figure: Replicate the single cluster setup across regions or availability zones.

While you can account for regional failures or network outages in an availability zone, this setup increases complexity, cost, and the management overhead for the resources in your cluster. For example, if you run a database, replicating this database across regions or availability zones might lead to challenges in keeping data in sync or meeting legal requirements. As you add API Gateways across clusters, you must make sure that you have a process in place to apply the same gateway configuration across clusters to avoid configuration drift.

Centrally manage gateway proxies across clusters

In this setup, you have multiple API Gateways and clusters in the same availability zone that each serve incoming traffic for a specific app or a subset of your apps. Instead of manually configuring each API Gateway, you use the Gloo management and data plane architecture and Gloo workspaces to apply the same configuration across clusters.

Figure: Centrally manage gateway proxies across clusters with Gloo Mesh Gateway.
Figure: Centrally manage gateway proxies across clusters with Gloo Mesh Gateway.

This setup significantly reduces the complexity of managing multiple API Gateways and the risk of configuration drift. Note that this setup improves availability in one availability zone, as you can fail over to the other cluster in case one cluster becomes unavailable. However, this setup does not protect you from an availability zone outage. To account for that, you must replicate the setup across availability zones or regions.

Global ingress, multicluster setup with central gateway management

Adding multiple API Gateways to serve traffic for different apps is a good way of making your apps and the API Gateway more resilient. However, you might not want to expose all API Gateways publicly and introduce multiple endpoints to external users. In this setup, you use a separate cluster to deploy a global API Gateway that all external users send requests to. The global API Gateway then forwards the request to the API Gateway that is serving traffic for the target app. To reduce the management overhead and the risk of configuration drift, you use the Gloo management and data plane architecture, and Gloo workspaces to apply the same configuration across clusters.

Figure: Global ingress, multicluster setup with central gateway management with Gloo Mesh Gateway.
Figure: Global ingress, multicluster setup with central gateway management with Gloo Mesh Gateway.

With this setup, you not only reduce the management overhead for your API Gateway, but you also reduce the surface for external attacks. A global API Gateway allows you to apply security controls that meet your business requirements and ensure compliance for an entire availability zone. In addition, you add an extra security layer in front of your apps to protect them from malicious activity. Note that this setup does not protect you from an availability zone outage. To account for that, you must replicate the setup across availability zones or regions.