Skip to main content
New to Testkube? Unleash the power of cloud native testing in Kubernetes with Testkube. Get Started >

Helm configuration

The Testkube Helm Chart lets you set up a customized Testkube tailored to your environment. The Chart will deploy a control plane and agent. You can learn more about the deployment architectures here.

Components

Testkube On-Prem consists of the following components:

Prerequisites

Before you proceed with the installation, please ensure that you have the following prerequisites in place:

  • Kubernetes cluster (version 1.21+)
  • Helm (version 3+)
  • (RECOMMENDED) cert-manager (version 1.11+) - Used for TLS certificate management.
  • (RECOMMENDED) NGINX Controller (version v1.8+) - Used for Ingress configuration.
  • (OPTIONAL) Prometheus Operator (version 0.49+) - used for metrics collection
  • Own a public/private domain for creating Ingress rules.
  • License Key and/or License File, if offline access is required.

Installing

  1. Add the Testkube Helm repository:
helm repo add testkubeenterprise https://kubeshop.github.io/testkube-cloud-charts
  1. Create and configure your values.yaml:
helm show values testkubeenterprise/testkube-enterprise > values.yaml

Alternatively, export one of our profiles:

testkube init <profile> --export > values.yaml

Currently available profiles are: demo.

  1. Install the Testkube Helm Chart:
helm upgrade --install \
--create-namespace \
--namespace testkube \
-f values.yaml \
testkube testkubeenterprise/testkube-enterprise

General Settings

License

You will have to set a license key to get started with Testkube. You can also opt to use a shared secret for your license. You can request a free license, no up-front credit card required.

global:
enterpriseLicenseKey: XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX-V3

Domain

You should enable ingress and configure your domain to access Testkube services:

global:
ingress:
enabled: true
domain: "example.com"

By default, the following services will be exposed. You can also choose to override the subdomain for each service.

ServiceDefaultOverride
Dashboarddashboard.$domainglobal.uiSubdomain
REST APIapi.$domainglobal.restApiSubdomain
Dexapi.$domain/idpglobal.restApiSubdomain
gRPC APIagent.$domainglobal.grpcApiSubdomain
WebSockets APIwebsockets.$domainglobal.websocketsApiSubdomain
Storage APIstorage.$domainglobal.storageApiSubdomain

TLS can either be handled through cert-manager or a manually defined secret. While custom TLS certificates are possible, we strongly recommend using cert-manager for simplified certificate manager.

info

TLS should be terminated at the application-level instead of the ingress-level as it will drastically enhance the performance of the gRPC and Websocket protocols. Be mindful that NGINX defaults to a downgrade from HTTP2 to HTTP1.1 when the backend service is using an insecure port.

Auth

You will have to configure how your users can access Testkube. Testkube uses Dex which supports the most popular identity providers. You can find a OIDC example for Google below:

dex:
envVars:
- name: GOOGLE_CLIENT_ID
valueFrom:
secretKeyRef:
name: <oidc-credentials-secret-name>
key: <client-id-key>
- name: GOOGLE_CLIENT_SECRET
valueFrom:
secretKeyRef:
name: <oidc-credentials-secret-name>
key: <client-secret-key>
configTemplate:
additionalConfig: |
connectors:
- type: oidc
id: google
name: Google
config:
issuer: https://accounts.google.com
clientID: $GOOGLE_CLIENT_ID
clientSecret: $GOOGLE_CLIENT_SECRET
redirectURI: <dex endpoint>/callback

Alternatively, you can use a local database with static users which acts as a virtual identity provider for evaluations.

Once authenticated, users will also need to be invited to org. By default, new users will automatically join the default organization. You can change this behaviour by changing the bootstrap and invitation configuration.

Telemetry

Testkube exposes Prometheus metrics on the /metrics endpoint and uses a ServiceMonitor resource to expose them to Prometheus. In order for this to work, you need to have Prometheus Operator installed in your cluster so that the ServiceMonitor resource can be created.

Use the following configuration to enable metrics:

testkube-cloud-api:
prometheus:
enabled: true

Shared Secrets

Testkube requires a variety of secrets to operate. Any required secret that is not provided manually will be automatically generated. You can optionally choose to specify your own secrets. For shared secrets without additional info, it’s recommended to use auto generation.

Testkube License

Enter your license key which can be either an offline or online license. Replace «license» with your license.

For an online license, the format is XXXXXX-XXXXXX-XXXXXX-XXXXXX-XXXXXX-V3.

kubectl create secret generic testkube-license --from-literal=LICENSE_KEY=«license»

For an offline license, the format is a long string prefixed with key/. You will also need a license file which starts with -----BEGIN LICENSE FILE-----.

kubectl create secret generic testkube-license --from-file=LICENSE_KEY=«license key» --from-file=license.lic=license file»

This secret is referenced by the global.enterpriseLicenseRef setting. For offline licences, you will also have to set global.enterpriseOfflineAccess: true.

Advanced Settings

Check out this article to learn more about our advanced settings. You can learn about organization management, custom ingress controllers, production environments and more.