Installing the Instana backend

To install Self-Hosted Custom Edition (Kubernetes or Red Hat OpenShift Container Platform), see the following instructions:

You need the cluster administrator permission to deploy Custom Edition.

Prerequisites

  1. Understand the Instana Enterprise operator. For more information, see Instana Enterprise operator.

  2. Review the system requirements for Self-Hosted Custom Edition (Kubernetes or Red Hat OpenShift Container Platform) and outbound network access requirements for self-hosted Instana deployments, and ensure that the requirements are met before you install the Instana backend.

  3. For installation in an air-gapped environment, complete the prerequisites in Preparing for air-gapped installation.

  4. Set up and configure required data stores. For more information, see Setting up required data stores.

Installation procedure

  1. Install the kubectl plug-in. For more information, see Installing the kubectl plug-in.

  2. Install and configure the Instana Enterprise operator in your Kubernetes or Red Hat OpenShift cluster.

  3. Install the components of Instana backend.

  4. Set up load balancers and DNS for the Acceptor and Gateway services. For more information, see Setting up load balancers and DNS.

Required resources: Custom Resource Definitions

Custom Resource Definitions (CRDs) are extensions of the Kubernetes API.

The following two CRDs are required during the Instana backend deployment. They must be installed on the same cluster as the Instana backend.

cores.instana.io

A Core represents all components that are shared by an Instana installation. Each Core has a set of associated databases, which are used by the Core itself and all tenants with their respective tenant units that are created as members of the Core.

For more information, see API Reference.

units.instana.io

Units represent individual data pools in Instana. Internally, Instana has tenants, which are merely a logical construct. Each tenant in turn has at least one or multiple tenant units. As far as the configuration is concerned, you always configure tenant units by using the Unit CRD. A tenant might stand for a department (such as SRE, Dev, QA), or any other logical grouping. Within a tenant, you can create individual Units as required. Data from one Unit is not visible by any other Unit.

For example, there are two departments, ecommerce and intranet.

ecommerce has three environments: dev, preprod, prod. intranet has two environments: dev and prod. In this case, you can create a tenant ecommerce with the tenant units dev, preprod, and prod, and a tenant intranet with the tenant units dev and prod.

Tenant units are separated, and receive data only from agents that are associated with them.

For more information, see API Reference.

Tips

Tip 1

You can also see the API reference by running the command kubectl explain.

Run the command kubectl explain --help for details on how to use it.

See the following example:

kubectl explain core.spec.serviceProviderConfig
KIND:     Core
VERSION:  instana.io/v1beta2

RESOURCE: serviceProviderConfig <Object>

DESCRIPTION:
     Service provider configuration for SAML or OIDC.

FIELDS:
   basePath	<string> -required-
     Base URL (defaults to "/auth").

   maxAuthenticationLifetimeSeconds	<integer> -required-
     The maximum authentication lifetime (defaults to 604.800).

   maxIDPMetadataSizeInBytes	<integer> -required-
     The maximum IDP metadata size (defaults to 200.000).

Tip 2

A good editor, such as VS Code with the Kubernetes extension provides command completion when the CRDs are installed on the cluster.

See the following example:

VS Code