Tetrate Application Gateway - Architecture

Overview

Tetrate Application Gateway consists of a set of loosely-coupled (so highly-reliable) components:

• Management Plane - The Tetrate Management Plane is the central point of control for your distributed application delivery topology. In TAG, the Management Plane is hosted as-a-Service on a Tetrate-managed platform.
• Control Plane - You install the control plane component onto each of your Kubernetes clusters. The Control Plane shares state to the central Management Plane, and it configures the gateways on the local cluster.
• Data Plane - The data plane consists of Tetrate-managed gateways that are installed on your Kubernetes clusters. Gateways can function as one of:
  • Edge / Tier1 Gateway - An Edge Gateway is used to publish your services to external clients. A small number of Edge Gateways gives you a well-defined, easy-to-manage perimeter.
  • App / Tier2 Gateway - The App Gateways are installed on each of your workload clusters and are used to expose services from that cluster. App Gateways also function as intermediate gateways to expose adjacent services (VMs, bare metal servers etc).
  • Transit Gateway - where necessary, Transit Gateways can be deployed to bridge disconnected networks so that Edge Gateways can reach the App Gateways.

These components are used to reliably deliver applications and services to internal and external clients:

All currently-supported kubernetes or openshift cluster versions are supported by Tetrate Application Gateway.

In more detail...

Interfaces

Users and services (e.g. CI/CD pipelines) interact with the Tetrate platform in a variety of ways:

• Management / Configuration - Users interact with the Tetrate Management plane using the embedded UI or API. Users can also interact with the API through a GitOps interface, where they publish configuration to an authorized namespace on one of the Kubernetes clusters
• Application Configuration - Users expose and publish an application by annotating the Service resource for that application. Tetrate Application Gateway then interprets the annotations to determine the desired configuration
• Application State - The Tetrate platform continually monitors the presence and health of applications, services and gateways, using Kubernetes and Envoy Gateway sources. This information informs the gateway configuration and failover operations

Service Registry

The Tetrate solution maintains an accurate internal service registry, identifying each to-be-published service and the locations it is available in. The solution dynamically controls the gateway configurations to expose the service from App clusters and publish it from the appropriate Edge Gateways.

Internal mTLS network

All internal traffic, from Edge Gateway to App Gateway, is secured using a managed mTLS mesh. Mesh traffic typically operates over port 15443, and is authenticated using internally-issued identities.

Transit Gateways

In some cases, Edge Gateways might not be able to reach the App Gateways directly. For example, you may wish to publish services hosted in one cloud or in on-prem infrastructure through an Edge Gateway that is located in a different cloud.

In this case, you can deploy Transit Gateway instances at the perimeter of the origin cloud or on-prem location, and you can further define reachability rules to control which sets of gateways are permitted to reach other sets of gateways. The Tetrate platform will calculate and use the shortest available path (minimal hops) from Edge to App Gateway.

Observability

The platform gathers observability data (metrics, logs and traces) from every gateway in the data path. This observability data is forwarded asynchronously to the Tetrate Management Plane where it is stored locally in a time-limited database.

The Tetrate Management Plane can then query the observability database for the purposes of generating metrics (charts), drawing the active topology (graph), visualizing traces and displaying gateway logs. You can select the time window for the data you wish to inspect.

Observability data can also be made available to external collectors, using OTel and Prometheus interfaces.

Supported Roles and Tasks to be Done

The Tetrate platform supports two primary roles - the Platform Owner, and the Application Owner.

Platform Owner role

The Platform Owner creates the environment and user experience that the Application Owner then uses to publish their applications.

• Onboard users to the Tetrate Management Plane
• Deploy and configure infrastructure (kubernetes clusters, which are onboarded to TAG)
• Control the publishing of services through Edge gateways
• Manage external-facing parameters, such as TLS certificates
• Onboard internal services to the Edge clusters, such as third-party load balancers
• Define internal HA parameters, such as locality, failover, edge-to-app retries

Application Owner role

In the simple use case, there is no defined 'App Owner' role in the TAG product. Application Owners interact with TAG indirectly, through annotations they apply to the services they publish to an Application Cluster.

A platform owner may wish to define a specific 'App Owner' role in the TAG user interface, allowing application owners to view metrics and troubleshoot services.

An Application Owner's responsibilities include:

• Onboard services to app clusters:
• Local services, i.e. deployed on the app cluster
• External services, i.e. onboarded as a Service (ExternalName or named Endpoints)
• Expose services from app cluster using TAG annotations
• Configure local traffic management (API GW, circuit breakers, etc) using TAG annotations