Requirements and Download

Requirements

	Production TIS+
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)
Elasticsearch 6.x, 7.x, or 8.x, or AWS OpenSearch 1.x or 2.x	packaged (v8.14.3)
Identity Provider	✓
Cert-manager v1.7.2 or above	✓

cert-manager usage

cert-manager is used to issue and manage certificate for TIS Plus webhook, TIS Plus internal communications and integration with external CA for Istio control plane.

Production installation note

The size of your Kubernetes clusters is dependent on your platform deployment requirements. A base TIS Plus 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.

Identity Provider

TIS Plus 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. TIS Plus now offers multiple options for identity providers:

Local Identity Provider

TIS Plus 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 TIS Plus, 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, TIS Plus continues to support external identity providers:

LDAP

TIS Plus can integrate with LDAP (Lightweight Directory Access Protocol) servers. To use LDAP:

1. Configure your LDAP queries for authentication and synchronization of users and groups.
2. Set up TIS Plus to use your LDAP server as the identity provider.

For more details on LDAP configuration, see LDAP as Identity Provider.

OIDC-Compliant Identity Providers

TIS Plus supports any OIDC (OpenID Connect) compliant Identity Provider. To use OIDC:

1. Create an OIDC client in your IdP.
2. Enable Authorization Code Flow for login with UI.
3. Enable Device Authorization for login with tctl using device code.

For more information and examples, see how to set up Azure AD as a TIS Plus Identity Provider.

OIDC IdP synchronization

TIS Plus 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 TIS Plus using the sync API. See User Synchronization for more details.

Data and Telemetry Storage

Tetrate Service Bridge (TIS Plus) requires data and telemetry storage. TIS Plus uses PostgreSQL for data storage and Elasticsearch for telemetry storage. The current version of TIS Plus includes embedded PostgreSQL and Elasticsearch options.

Embedded PostgreSQL and Elasticsearch are suitable for various environments, including production scenarios with specific considerations:

• Demo and Development: Ideal for testing, development, and demonstration purposes.
• Production: Can be used in production environments where high availability (HA) and extensive observability are not critical requirements.

Considerations for Embedded Storage in Production

1. Performance and Scalability: Evaluate the performance and scalability needs of your specific use case.
2. Uptime: Uptime guarantees are dependent on the installation environment. Kubernetes has limitations for stateful data/storage management.
3. 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.
4. 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.
5. The Postgres user configured in TIS Plus must have full ownership of the TIS Plus 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 TIS Plus 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 considered:

1. High Availability (HA): If you need strong SLAs, large-scale operations, or HA guarantees, consider moving to external Elasticsearch and/or PostgreSQL.
2. Heavy Observability Usage: Environments with high sampling rates or extensive tracing may benefit from external solutions.
3. Clustered Setups: For scenarios requiring clustered databases or hot standbys.

Production Storage Evaluation

TIS Plus'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 TIS Plus must have full ownership of the TIS Plus 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 TIS Plus schema is still in place before doing any changes on the Management Plane settings.

Certificate Provider

TIS Plus requires a certificate provider to support certificate provisioning for internal TIS Plus components for purposes like webhook certificates and others. This certificate provider must be available in the management plane cluster and all control plane clusters.

TIS Plus 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

Existing cert-manager installation

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 TIS Plus utilize the existing cert-manager installation. The TIS Plus 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.

cert-manager Kube-CSR

TIS Plus 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 TIS Plus managed installations using INTERNAL managed cert-manager, this configuration is already set as part of the installation.

Download

The first step to get TIS Plus up and running is to install our TIS Plus CLI tool tctl. With tctl you can install (or upgrade) TIS Plus. It also allows you to interact with the TIS Plus API's using yaml objects. If having operated Kubernetes deployments, this will be familiar to you. It also makes it easy to integrate TIS Plus with GitOps workflows.

Follow the instruction in the CLI reference pages to download and install tctl.

Sync 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 TIS Plus 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.

Installation

cluster profiles

Operating a multi-cluster TIS Plus 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 installation using Helm chart, please proceed to the helm installation guide.