Self-hosted on Kubernetes

Over the past years, Kubernetes becomes the defacto standard for orchestrating containers. Instana is designed to run well on Kubernetes. In fact, Instana is run on Kubernetes on our SaaS platform.

Minimum supported Kubernetes version: 1.16.

Kubernetes operator

A Kubernetes operator is built, which manages the whole Instana platform and makes it easy for you to run it on Kubernetes. It automates the deployment of all components and takes care of required database migrations.

The operator is a controller that runs on the cluster. It uses a set of custom resources that describe the Instana setup in a declarative manner. It watches for changes on these resources and reconciles them as necessary.

Custom Resource Definitions

Custom Resource Definitions (CRDs) are extensions of the Kubernetes API. The following two CRDs must be installed on the cluster.

See API Reference for details.

Tip 1:

The API reference is also available by using kubectl explain. See kubectl explain --help for details on how to use it.

See the following example:

$ kubectl explain core.spec.serviceProviderConfig
KIND:     Core

RESOURCE: serviceProviderConfig <Object>

     Service provider configuration for SAML or OIDC.

   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

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.

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 via the Unit CRD. A tenant might stand for a department (such as SRE, Dev, QA), or any other logical grouping. Within a tenant, you would 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.

In this case, you would 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 only receive data from agents that are associated with them.

kubectl plug-in

A kubectl plug-in is available that helps install the operator, and also enables you to trigger administrative actions that the operator performs.

Supported Kubernetes versions

The operator runs on any vanilla Kubernetes distribution. The minimum required version is 1.16.

Support for Red Hat OpenShift is planned.