Requirements
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.
Tetrate Service Bridge (TSB) now offers a FIPS-validated build, designed to meet U.S. federal government cryptographic standards. This build enhances security posture for organizations requiring strict compliance. For implementation details and best practices, see our TSB FIPS Guide.
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: See Supported Kubernetes versions | ✓ | ✓ |
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.12) | packaged (v14.12) |
Elasticsearch 6.x, 7.x, or 8.x, or AWS OpenSearch 1.x or 2.x | packaged (v8.14.3) | packaged (v8.14.3) |
Redis 6.2 or above | ✓ | packaged (v7.0.15) |
Identity Provider | ✓ | Local IdP |
Cert-manager v1.7.2 or above | ✓ | packaged (cert-manager v1.14.6) |
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
Tetrate Service Bridge (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 now offers multiple options for identity providers:
Local Identity Provider
TSB now supports a local identity provider, which can be used for environments where external identity providers are not required or not available. This option is particularly useful for:
- Small-scale deployments
- Development and testing environments
- Scenarios where external identity management is not necessary
The local identity provider allows you to manage users and groups directly within TSB, simplifying the setup process and reducing external dependencies. For more information on setting up the local identity provider, see Local Identity Provider.
External Identity Providers
For environments that require integration with existing identity management systems, TSB continues to support external identity providers:
LDAP
TSB can integrate with LDAP (Lightweight Directory Access Protocol) servers. To use LDAP:
- Configure your LDAP queries for authentication and synchronization of users and groups.
- Set up TSB to use your LDAP server as the identity provider.
For more details on LDAP configuration, see LDAP as Identity Provider.
OIDC-Compliant Identity Providers
TSB supports any OIDC (OpenID Connect) compliant Identity Provider. To use OIDC:
- Create an OIDC client in your IdP.
- Enable Authorization Code Flow for login with UI.
- Enable 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 need to create a sync job that will get users and teams from your IdP and sync them into TSB using the sync API. See User Synchronization for more details.
Data and Telemetry Storage
Tetrate Service Bridge (TSB) requires data and telemetry storage. TSB uses PostgreSQL for data storage and Elasticsearch for telemetry storage. The current version of TSB includes optional embedded PostgreSQL and Elasticsearch deployments.
Embedded PostgreSQL and Elasticsearch are suitable for various environments:
- Demo and Development: Ideal for testing, development, and demonstration purposes.
- Production: May be used with care in production environments where high availability (HA) and extensive observability are not critical requirements.
Considerations for Embedded Storage in Production
It can be very difficult to fully restore a Tetrate Management Plane that suffers a database failure, and Kubernetes-hosted PostgreSQL may not provide the same degree of reliability, high availability and scalability that an external instance should do.
- Performance and Scalability: Evaluate the performance and scalability needs of your specific use case.
- Uptime: Uptime guarantees are dependent on the installation environment. Kubernetes has limitations for stateful data/storage management.
- Data Management:
- PostgreSQL:
- Scheduled backups are supported.
- Best-effort support for repair and restoration.
- Elasticsearch:
- Used for observability data on a best-effort basis.
- In case of problems, purging towards a clean install may be necessary.
- Observability data retention is limited to a maximum of 7 days.
- PostgreSQL:
- Storage Sizing:
- Proper sizing of Persistent Volume Claims (PVCs) is crucial.
- Data growth rates vary per installation.
- If storage overflows, options include purging data, increasing PVC size, or reducing the retention period.
- The Postgres user configured in TSB must have full ownership of the TSB schema. This is automatically configured on the first installation when the schema is created. If the user or permissions need to be changed afterward, care must be taken to make sure full ownership of the TSB schema is still in place before doing any changes on the Management Plane settings.
External Storage for Production
For production environments with specific requirements, external storage solutions should be preferred:
- High Availability (HA): If you need strong SLAs, large-scale operations, or HA guarantees, consider moving to external Elasticsearch and/or PostgreSQL.
- Heavy Observability Usage: Environments with high sampling rates or extensive tracing may benefit from external solutions.
- Clustered Setups: For scenarios requiring clustered databases or hot standbys.
TSB's operator-managed storage provides lifecycle management for the databases. However, you should still evaluate the performance and scalability of the storage solution for your specific production environment.
While embedded storage can be suitable for many production use cases, you need to carefully evaluate whether it meets your specific requirements, especially regarding:
- High availability needs
- Observability data volume and retention
- Performance under your expected load
- Backup and recovery processes
If your use case involves critical HA requirements or heavy observability usage (particularly with high sampling rates for tracing), consider externalizing these tools for optimal performance and reliability.
The Postgres user configured in TSB must have full ownership of the TSB schema. This is automatically configured on the first installation when the schema is created. If the user or permissions need to be changed afterward, care must be taken to make sure full ownership of the TSB schema is still in place before doing any changes on the Management Plane settings.
Certificate Provider
TSB 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.
Acquire the Tetrate Tools and Images
Now that you have installed the required prerequisites, the next step is to acquire the Tetrate CLI tool (tctl) and to use it to synchronize the Tetrate software images.