Unified Gateway
This document introduces the concept of a Unified Gateway within the Tetrate Service Bridge (TSB) ecosystem, explaining its significance and providing detailed usage scenarios.
Introduction
Unified Gateway is a critical feature introduced in TSB 1.7.0 that merges the capabilities of Tier1Gateway and IngressGateway under a common resource called Gateway. This unification simplifies the gateway management process and offers a more cohesive experience.
From TSB 1.7.0 onwards, Tier1Gateway and IngressGateway resources will be deprecated, and we strongly recommend using the Gateway resource for all your gateway needs. The former Tier1 Gateway will now be collectively known as Edge Gateway.
The Unified Gateways tab is seamlessly integrated into the TSB UI, allowing easy configuration of any gateway, whether it functions as a Tier 1 or Tier 2 gateway.
Why the Unified Gateway?
Early in our journey, we recognized the distinctive needs of our customers for both cluster-specific (Tier 2) and cross-cloud vendor (Tier1) gateways. As a result, we developed separate gateway solutions to cater to these varying demands. However, as our Gateway API evolved and customer requirements grew more complex, the need to continually enhance the capabilities of our Tier1 gateway became evident.
This evolution brought challenges—ongoing engineering efforts, customer education on when to choose Tier1 or Tier2, and maintaining parallel codebases. We've embarked on a groundbreaking endeavor: Unified Gateway to streamline these complexities and provide a more cohesive experience.
The Unified Gateway Advantage
Unified Gateway isn't just a fusion of Tier 1 and Tier 2 gateways; it's a paradigm shift in gateway management. Here's what you need to know about this game-changing solution:
Comprehensive Capabilities
Unified Gateway combines the robust capabilities of Tier 1 and Tier 2 gateways from TSB version 1.6.X, ensuring you get the best of both worlds. Whether dealing with retries, failover, or any other advanced functionality, Unified Gateway has you covered, regardless of whether it's configured as a Tier 1 or Tier 2 gateway.
Seamless Transition
For our existing customers, we understand the importance of continuity. Fear not, as your Tier 1 and Tier 2 gateways will continue to function as usual with the capabilities provided by version 1.6.X. But we're not stopping there. We're introducing a seamless process to transition your existing gateways to the Unified Gateway model, enhancing Tier 1 functionality such as retries and more.
New API for Unified Gateway
Embracing innovation doesn't mean neglecting the past. While introducing the new Unified Gateway API for fresh opportunities, we're committed to supporting the previous APIs for the subsequent three TSB releases. This ensures you can switch at your own pace and without disruption.
Empowering Direct Mode
Unified Gateway isn't just about gateways—it's about empowerment. Both new and existing customers can harness the full capabilities of the Gateway API via the Direct mode, offering unparalleled control and customization over their mesh infrastructure.
Aligned with Open API Strategy
We believe in the power of open standards. Unified Gateway aligns seamlessly with our Open API strategy, enabling you to configure Unified Gateways using a standardized Open API specification. This approach promotes consistency and simplifies integration with your existing toolchain.
Use Cases
Let's dive into the unified gateway usage scenarios.
Preparing Clusters
The following image shows the deployment architecture we use in this document. We created 3clusters in GKE, deployed TSB in one of them, loaded the other three clusters into TSB, and deployed the bookinfo application in the cluster with the infrastructure shown below.
The following table describes the roles and applications of these clusters:
Cluster | gke-jimmy-us-central1-1 | gke-jimmy-us-west1-1 | gke-jimmy-us-west1-2 | gke-jimmy-us-west2-3 |
---|---|---|---|---|
Region | us-central1 | us-west1 | us-west1 | us-west2 |
TSB Role | Management Plane | Control Plane | Control Plane | Control Plane |
Application | - | bookinfo-frontend | bookinfo-backend | httpbin |
Services | - | productpage | productpage , ratings , reviews , details | httpbin |
Network | tier1 | cp-cluster-1 | cp-cluster-2 | cp-cluster-3 |
This section describes the unified gateway usage scenarios.
Scenario 1: Cluster-Based Routing with HTTP Path and Header Match
In this scenario, we will use the Gateway resource to expose bookinfo.tetrate.io
and httpbin.tetrate.io
. We will leverage cluster-based routing capabilities based on the path prefix on Gateway to route bookinfo frontend services to cp-cluster-1
and other backend services to cp-cluster-2
. Using Gateway, users can expose multiple such hosts with clusterDestination, provided the host:port combination is unique.
Deployment Topology and Traffic Routing
We have set up the following deployment topology:
-
Tier 1 Cluster: This cluster acts as the entry point for external traffic and routes it to the respective backend clusters.
-
Backend Clusters: There are three backend clusters, each hosting different services:
cp-cluster-1
hosts the frontend service of the "Bookinfo" application.cp-cluster-2
hosts the backend services of the "Bookinfo" application.cp-cluster-3
hosts an HTTP service calledhttpbin
.
Configuration
1. Tier 1 Cluster Gateway (edge-gateway):
In the tier1
cluster, we deploy a Gateway named edge-gateway
. This Gateway receives incoming traffic and routes it to the appropriate backend clusters based on the host and path prefix.
Here's a snippet of the configuration for routing requests to the "Bookinfo" frontend and backend services:
apiVersion: gateway.tsb.tetrate.io/v2
kind: Gateway
metadata:
name: edge-gateway
namespace: tier1
annotations:
tsb.tetrate.io/organization: tetrate
tsb.tetrate.io/tenant: tier1
tsb.tetrate.io/workspace: tier1
tsb.tetrate.io/gatewayGroup: edge-gateway-group
spec:
workloadSelector:
namespace: tier1
labels:
app: edge-gateway
http:
- name: bookinfo
hostname: bookinfo.tetrate.io
port: 80
routing:
rules:
- match:
- uri:
prefix: "/productpage"
headers:
X-CLUSTER-SELECTOR:
exact: gke-jimmy-us-west1-1
route:
clusterDestination:
clusters:
- name: gke-jimmy-us-west1-1
weight: 100
- match:
- uri:
prefix: "/productpage"
headers:
X-CLUSTER-SELECTOR:
exact: gke-jimmy-us-west1-2
route:
clusterDestination:
clusters:
- name: gke-jimmy-us-west1-2
weight: 100
- match:
- uri:
prefix: "/productpage"
route:
clusterDestination:
clusters:
- name: gke-jimmy-us-west1-1
weight: 100
- match:
- uri:
prefix: "/api/v1/products"
route:
clusterDestination:
clusters:
- name: gke-jimmy-us-west1-2
weight: 100
- name: httpbin
hostname: httpbin.tetrate.io
port: 80
routing:
rules:
- route:
clusterDestination:
clusters:
- name: gke-jimmy-us-west2-3
weight: 100
These rules ensure that requests to bookinfo.tetrate.io
with different path prefixes are routed to the appropriate backend clusters. Similarly, requests to httpbin.tetrate.io
are directed to the cp-cluster-3
.
2. Ingress Gateways in Backend Clusters
In each backend cluster (cp-cluster-1
, cp-cluster-2
, and cp-cluster-3
), we deploy Ingress Gateways to receive traffic from the tier1
cluster and route it to the respective services.
Here's an example of the Ingress Gateway configuration in cp-cluster-1
:
apiVersion: gateway.tsb.tetrate.io/v2
kind: Gateway
metadata:
name: bookinfo-ingress-gateway
spec:
# ... (metadata and selectors)
http:
- hostname: bookinfo.tetrate.io
name: bookinfo-tetrate
port: 80
routing:
rules:
- route:
serviceDestination:
host: bookinfo-frontend/productpage.bookinfo-frontend.svc.cluster.local
This configuration ensures that traffic received by the Ingress Gateway in cp-cluster-1
for bookinfo.tetrate.io
is routed to the frontend service.
Verification
We can use tools like curl to request the exposed services to verify the setup. For example, to test /productpage
:
export GATEWAY_IP=$(kubectl -n tier1 get service edge-gateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
curl -Ss "http://bookinfo.tetrate.io/productpage" --resolve "bookinfo.tetrate.io:80:$GATEWAY_IP" -v -H "X-B3-Sampled: 1"
Similarly, you can test other routes and services per the defined routing rules.