Tetrate Application Gateway - Topology

Tetrate Application Gateway supports a two-tier topology of Edge (Tier1) and App (Tier2) gateways, with intermediate Transit gateways used as needed to bridge between disconnected networks:

It's uncommon to expose an application or app-level load balancer directly to end clients. For medium and large-scale deployments, there are security and management benefits to placing an additional load-balancing tier in front of the app-level load balancers:

• Reduced, easier-to-secure perimeter
• Decouple entrypoints (edge load balancers) from infrastructure (app load balancers), allowing for easier infrastructure reconfigurations
• Improved uptime in the event of an application cluster failure

Most cloud deployments place a cloud-specific load-balancer (e.g. AWS ELB/ALB) in front of kubernetes clusters and internal load balancers, for this purpose. The Tetrate solution takes a similar approach, but in a cloud-neutral manner that provides additional control, and which supports hybrid deployments (multi-cloud and on-prem) seamlessly.

Edge Gateways

Tetrate's Edge Gateway is a front-end proxy that is deployed to manage traffic and distribute it across multiple back-end workload clusters. It scales to very large numbers of clusters, regions and levels of traffic.

The Edge Gateway deployment pattern:

• Supports both public and private IP addresses, bridging from public to private if necessary. An Edge Gateway deployment can reduce the number of public IP endpoints, which in turn reduces the attack surface and potentially the cost
• Consolidates the functionality of the workload cluster's App Gateway, bringing it forward and closer to the client. Performing simple tasks such as rate limiting or authorization at the Edge reduces the load and configuration complexity on the App clusters
• Secures the entire data-path, from the very first Edge Gateway to the App cluster, using Tetrate's mTLS and tunneling capabilities
• Reduces failover time and eliminates unnecessary hops in a failover scenario

The Edge Gateway pattern is a two-tier pattern, where the Edge Gateways provide a first tier of load-balancing in front of a tier of App Gateways in Workload clusters.The Edge Gateways manage failover in the App clusters, supporting locality-based affinity and priority-group failover. Health Status is collected using Envoy's sophisticated 'outlier detection' and is propagated to the Tetrate Management Plane so that downstream gateways can be quickly reconfigured.

App Gateways

App Gateways (also known as 'Tier2' or 'Ingress' gateways) are deployed in each Application cluster. They provide local load-balancing to the services (and ServiceEndpoints) in that cluster, and expose these services to the Tetrate mTLS mesh that connects Edge and App gateways.

The App Gateway pattern:

• Provides local load-balancing, supporting both shared and dedicated gateways for services in the cluster. Shared gateways reduce resource usage (such as cluster IP addresses), but may incur noisy-neighbour effects
• Provides a location to perform application-specific operations such as OpenAPI Spec validation (API Firewall), taking bursty load away from the shared Edge gateways

You can onboard and expose multiple different application types:

• A local service can be annotated with a request to publish it

The TAG controller watches for services that are annotated, and then generates the necessary configuration to expose the service from the local App cluster, and then publish it through the Edge gateways.

• An application endpoint can be registered with App-Gateway's Service Registry.

The Service Discovery automatically populates the registry with local apps; you can use automation tools or manual steps to add other apps to the registry.

Once an application endpoint is added to the Service Registry, you can then refer to the endpoint in the App Gateway configurations that you author. This allows you to expose the app from a local App Gateway.

• An existing load balancer, proxy or application can be onboarded directly to an Edge Gateway

This approach is most commonly used to onboard existing load balancers and proxies. The load balancer is onboarded alongside the App Gateways, and Edge Gateways talk directly to the load balancer using HTTP or TLS-passthrough.

Global Load Balancing

Global Load Balancing, typically performed by controlling responses to DNS requests, is used to direct clients to the most appropriate and available Edge Gateways. The implementation is straightforward, with several choices that may impact the simplicity and responsiveness of the deployment:

• Health Checking:
  • Loosely-integrated GSLB solutions check the health and availability of services using synthetic health checks - essentially, test requests to a service to verify that it is responding correctly. These health checks are typically performed every 5-60 seconds, depending on the volume and load they incur
  • Tightly-integrated GSLB solutions take their health information from the application platform itself. The Tetrate GLB solution uses health and status information from the edge gateways to determine if they are available, and what services they can reach
• DNS architecture:
  • Individual FQDNs: The GSLB solution checks each service individually and explicitly, resulting in a highly-accurate view of which services are available, but at a very high load when large numbers of services are active
  • Shared CNAMEs: Each service FQDN is a CNAME for a shared FQDN name, such as 'gslb.example.com'. The shared name is checked for availability, and it's assumed that if the shared name is available, then the services that use it are also available (or completely down). Tetrate GLB allows you to split your services between multiple shared names, so you can control routing and affinity
• Service Location:
  • Public IP addresses: the GSLB service can route traffic to and check the availability of public IP addresses. This is typically a requirement for solutions that rely on synthetic transactions to check the availability of a service
  • Private IP addresses: the GSLB service can run in the private IP space of the target services (or takes health information from the application platform itself). This allows the solution to manage traffic for internal, private Edge load gateways; for example, if the gateways are deployed behind an edge service such as Azure APIm

You can use third-party global load balancing solutions (Akamai, Route53, NS1, etc) to manage Global Load Balancing. Tetrate also provide a GLB service that is tightly integrated to the TAG platform and supports internal IP addresses and direct (tightly-integrated) health checks.

As an alternative, it is common to 'roll your own' edge DNS solution using external-dns to synchronize the DNS zones with the active configuration of your Edge gateway.