Introducing Tetrate Service Bridge

Tetrate Service Bridge (TSB) is a service mesh platform for large multi-cluster, multi-tenant deployments. It is used by platform owners to securely network clusters together, to manage traffic across these clusters, to maintain availability, and to define access and organizational policies for users and services.

What do I need to know about TSB?

How it Works

When your application is deployed to a TSB-managed Kubernetes cluster, the following happens:

• An Envoy Proxy-based sidecar is deployed alongside your application. This proxy manages all of the incoming and outgoing connections to your application. With the proxy, TSB can apply mTLS, security policies, traffic management policies, and can extract observability information for your application
• Your application's presence is updated in the TSB service registry. TSB then updates the mesh routing to make your application accessible from other clusters, according to your organization's security policy. In the event of a failure, TSB can re-route traffic internally to another instance of your application

Your application is exposed using a TSB 'Gateway' resource:

• The Gateway resource exposes your application using a selected host and path, through a local TSB gateway. This provides a method for downstream clients (such as load balancers or remote clients) to access your application using a defined host and path.
• The local TSB gateway is referred to as a 'Tier2' or 'Ingress' gateway. The location of the gateway and the services it exposes are also stored in the TSB service registry

Your application may be made available through several layers of Tetrate-managed Gateways:

• Incoming traffic first hits a 'Tier1' (aka. 'Edge') gateway. This gateway handles traffic for many services, and provides a single point-of-entry and control. Only traffic for known services is accepted; all other requests are refused
• The Tier1 gateway is programmed from the TSB service registry, and knows where target services are located. In most cases, it will forward the request to the most suitable Tier2 gateway, deep within your infrastructure. Traffic is carried over a secure mTLS network
• More sophisticated architectures are possible, with Tetrate Transit Gateways to span disconnected networks, or third-party load balancers to apply additional security policies.

TSB gateways may apply additional traffic management and security policies. This means your application code does not need to perform these tasks. Tasks may include:

• Header manipulation, for CORS or Cache-control
• Circuit-breaker controls, such as timeouts and retries
• Rate-limiting to prevent abuse or overload
• JWT authentication to validate JWT claims in requests
• Acting as a OpenID Connect (OIDC) Relying Party

For more details, you can refer to the Tetrate Service Bridge documentation.

How is TSB Configuration Applied?

TSB and Istio Configuration

TSB uses Istio internally to configure the Envoy sidecar proxies on each application, but users do not interact directly with this Istio configuration. Instead, TSB has a multi-user, multi-cluster API that is used to define configuration for your application. RBAC controls what configuration each user can view and manage.

In most cases, the TSB configuration is automatically generated by the pipeline that deploys your application. As an Application Owner, you don't manage this configuration yourself, and you may have limited control over the configuration applied to your application.

Where you do apply TSB configuration, you will likely do so using:

• GitOps - using tsb.tetrate.io/v2 resources applied to the Kubernetes cluster
• tctl - a simple command-line tool which manages TSB configuration in a similar fashion to how kubectl manages Kubernetes configuration
• Automation using TSB's REST or gRPC APIs

How is TSB Configuration Structured?

It is useful to understand how TSB configuration is structured:

• At the core of TSB configuration is the construct of a Workspace. A Workspace is a set of Kubernetes namespaces on one or more Kubernetes clusters. For example, if your application is deployed across three namespaces on two clusters, your administrator may define a TSB Workspace that spans these namespaces.
• Workspaces are the core unit of RBAC (role-based access control). You can view resources in a Workspace, but not resources outside that Workspace
• Workspaces are the core unit of Observability. You can view metrics, logs and traces for services within the Workspace, but not beyond
• Workspaces are the core unit of Security Policies. Your administrator will define which Workspaces can see and communicate with other Workspaces

In addition to Workspaces, you may encounter 'Groups' - Security Groups, Traffic Groups and Gateway Groups. These are simply containers for configuration (of the named type) within the Workspace (or part of the Workspace).

These concepts - Workspaces and Groups - are significant, as they are the units of configuration that you will see in the TSB UI. Take note of how these map to clusters-and-namespaces on your platform infrastructure.

Summary

You now understand the following concepts:

• TSB creates and manages a service mesh that spans multiple Kubernetes clusters
• It adds Envoy Proxy sidecars to each service that is deployed; these proxies manage incoming and outgoing connections
• Your services (applications) are exposed from a cluster using a TSB Tier2 / Ingress Gateway, configured using a TSB Gateway resource
• Typically, a cluster is then exposed externally through a front-end Tier1 / Edge Gateway
• Gateways can add functionality, such as authentication, security and traffic management
• TSB configuration is constrained by RBAC (Role-based Access Control)
• The fundamental container for configuration is a WorkSpace, which spans a set of namespaces across one or more Kubernetes clusters
• Workspaces contain Groups, which are used to organize and distribute the configuration (Security, Traffic Management, and Gateway) within the Workspace
• Your application pipeline may manage Tetrate configuration using GitOps to provision tsb.tetrate.io/v2 configuration resources to a cluster