Tetrate Service BridgeVersion: 1.6.xRequirements and Download
This page will give you an overview of everything that you need to get started with both Tetrate Service Bridge (TSB) installation.
Operating a TSB service mesh requires a good understanding of working with Kubernetes and Docker repositories. For additional guidance, we recommend reading their supporting documentation.
Requirements
You can install TSB for production use, or you can install the demo profile for get a quick feel of TSB. Please check the requirements for each in the following table:
| Production TSB | Demo/Quickstart TSB | |
|---|---|---|
| Kubernetes cluster: EKS 1.22 - 1.26[1] GKE 1.22 - 1.26[1] AKS 1.22 - 1.26[1] (including Azure Stack HCI) OpenShift 4.7 - 4.12[1] Mirantis Kubernetes Engine 3.5.9 and above. Mirantis Container Runtime 20.10.14 and above | ✓ | ✓ |
| Private Docker registry (HTTPS) | ✓ | ✓ |
| Tetrate repository Account and API Key (if you don't have this yet, please contact Tetrate) | ✓ | ✓ |
| Docker Engine 18.03.01 or above, with push access to your private Docker registry | ✓ | ✓ |
| PostgreSQL 11.1 or above | ✓ | packaged (v14.2) |
| Elasticsearch 6.x, 7.x or 8.x | ✓ | packaged (v7.8.1) |
| Redis 6.2 or above | ✓ | packaged (v7.0.5) |
| LDAP server or OIDC Provider | ✓ | packaged (OpenLDAP v2.5) |
| Cert-manager: cert-manager v1.7.2 or above | ✓ | packaged (cert-manager v1.10.0) |
[1] Kubernetes 1.25 and 1.26 or Openshift 4.11 and 1.12 are supported in TSB >= 1.6.1.
cert-manager is used to issue and manage certificate for TSB webhook, TSB internal communications and integration with external CA for Istio control plane.
cert-manager 1.4.0 is the minimum version required for use with TSB 1.5. It has the feature flag to sign K8S CSR requests which supports Kubernetes 1.16-1.21. Go to cert-manager Supported Releases to get more information on supported Kubernetes and OpenShift versions.
The size of your Kubernetes clusters is dependent on your platform deployment requirements. A base TSB install does not consume many additional resources. The sizing of storage is greatly dependent on the size of your application clusters, amount of workloads (and their request rate), and observability configuration (sampling rate, data retention period, etc.). For more information see our capacity planning guide.
When running self-managed, your organization might impose additional (security) restrictions, availability, and disaster recovery requirements on top of the above mentioned environments and applications. For detailed information on how to adjust the TSB installation and configuration please refer to the operator reference guides as well as the how to section of our documentation where you can find descriptions of the configuration options, common deployment scenarios and solutions.
Identity Provider
TSB requires an Identity Provider (IdP) as the source of users. This identity provider is used for user authentication and to periodically synchronize the information of existing users and groups into the platform. TSB can integrate with LDAP or any OIDC compliant Identity Providers.
To use LDAP, you have to figure out how to query your LDAP so TSB can use it for authentication and synchronization of users and groups. See LDAP as Identity Provider for more details on LDAP configuration.
To use OIDC, create an OIDC client in your IdP. Enable Authorization Code Flow for login with UI and Device Authorization for login with tctl using device code. For more information and examples see how to set up Azure AD as a TSB Identity Provider.
TSB supports Azure AD for synchronization of users and groups. If you use another IdP you have to create a sync job that will get users and teams from your IdP and sync them into TSB using sync API. See User Synchronization for more details.
Data and Telemetry Storage
TSB requires external data and telemetry storage. TSB uses PostgreSQL as data storage and Elasticsearch as telemetry storage.
Demo installation will deploy PostgreSQL, Elasticsearch and LDAP server as Identity Provider populated with mock users and teams. Demo storage is not intended for production usage. Please make sure to provision proper PostgreSQL, Elasticsearch and Identity Provider for your production environment.
Certificate Provider
TSB 1.5 requires a certificate provider to support certificate provisioning for internal TSB components for purposes like webhook certificates and others. This certificate provider must be available in the management plane cluster and all control plane clusters.
TSB supports cert-manager as one
of the supported providers. It can manage the lifecycle of cert-manager installation for you.
To configure the installation of cert-manager in your cluster, add the following section as part of
the ManagementPlane or ControlPlane CR:
components:
internalCertProvider:
certManager:
managed: INTERNAL
You can also use any certificate provider which supports the kube-CSR API. To use custom providers,
please refer to the following section Internal Cert Provider
If you are already using cert-manager as part of your cluster, you can set the managed field
in ManagementPlane or ControlPlane CR to EXTERNAL. This will let TSB utilize the existing
cert-manager installation. The TSB operator will fail if it finds an already installed cert-manager
when the managed field is set to INTERNAL to ensure that it does not override
the existing cert-manager installation.
TSB uses the kubernetes CSR resource to provision certificates for various webhooks. If your configuration
uses an EXTERNAL cert-manager installation, please ensure cert-manager can sign Kubernetes CSR requests. For example,
in cert-manager 1.7.2, this is enabled by setting this feature gate flag ExperimentalCertificateSigningRequestControllers=true.
For TSB managed installations using INTERNAL managed cert-manager, this configuration
is already set as part of the installation.
Download
The first step to get TSB up and running is to install our TSB CLI tool tctl.
With tctl you can install (or upgrade) TSB. It also allows you to interact
with the TSB API's using yaml objects. If having operated Kubernetes
deployments, this will be familiar to you. It also makes it easy to integrate
TSB with GitOps workflows.
Follow the instruction in the CLI reference pages to download and install tctl.
Sync Tetrate Service Bridge images
Now that you have tctl installed, you can download the needed container images
and push them into your private Docker repository. The tctl tool makes this
easy by providing the image-sync command, which will download the image versions
matching the current version of tctl from Tetrate repository and push it
into your private Docker repository. The username and
apikey arguments must hold the Tetrate repository account details provided to you by
Tetrate to enable the download of the container images. The registry argument
must point to your private Docker registry.
tctl install image-sync --username <user-name> \
--apikey <api-key> --registry <registry-location>
The first time you run this command you will be presented with a EULA which
needs to be accepted. If you run the TSB installation from CI/CD or other
environment where you will not have an interactive terminal at your disposal,
you can add the --accept-eula flag to the above command.
Demo installations on a Kind cluster
If you are installing the demo profile in a local kind cluster,
you can directly load the images in the kind node as follows:
# Loging to the Docker repository using our `username` and `apikey`
docker login containers.dl.tetrate.io
# Pull all the docker images
for i in `tctl install image-sync --just-print --raw` ; do docker pull $i ; done
# Load the images to the kind node
for i in `tctl install image-sync --just-print --raw` ; do kind load docker-image $i ; done
Installation
Operating a multi-cluster TSB environment typically involves communicating with
multiple Kubernetes clusters. In the documentation we do not make explicit use
of kubectl config context and tctl config
profiles as they are specific to your environment. Make sure that you have
selected the right kubectl context and tctl profile as default or use
explicit arguments to select the correct clusters when executing commands with
these tools.
For the full installation procedure, please proceed to the self-managed installation guide.
For the demo installation procedure, please proceed to the demo installation guide.
For installation using Helm chart, please proceed to the helm installation guide.