Skip to content

Base configuration

This page will explain the base configuration for a kdb Insights Enterprise deployment. This will enable you to customize configuration around image registries, ingress certs, and licenses.

Image repository

In order run the application you must configure the image repository. The parameters and their descriptions are described below:

Variable Type Global Example Default
image.repository string Y "registry.example.com" "registry.dl.kx.com/"
image.pullPolicy string Y "Always" "IfNotPresent"
imagePullSecrets list Y ["kxi-nexus-pull-secret"] []

You should configure the image repository and pull policy at the global level with the default being the KX Nexus. If you need to self-host the images, the CLI install commands support customizing this default repository and setting the global.image.repository accordingly.

When using a private image registry such as the KX Nexus, login credentials will be required to pull images. The CLI assists creating this secret at the point of deployment.

global:
  image:
    repository: "registry.example.com"
  imagePullSecrets:
  - name: "kxi-nexus-pull-secret"

More information on the pull policy and pull secrets are available in the Kubernetes docs.

Image pull policy

Image pull secrets

Ingress certificates

The kdb Insights Enterprise uses Ingress to route external client requests into the application. TLS certificates are used to secure this communication, and must be provisioned for the application. There are two supported modes to do this as part of the installation.

Renewals

Ingress certificates may require rotation for various reasons, including security concerns and expiration. For self-managed certificates, manual renewal is required. This can be accomplished by updating the Kubernetes secret with the most updated certificate and key. Cert-manager, on the other hand, will automatically handle the renewal of its own certificates.

kubectl delete secret <SECRET_NAME>
kubectl create secret <SECRET_NAME> --cert=<CA_CRT_PATH> --key=<CA_KEY_PATH>

Certmanager

By default kdb Insights Enterprise uses cert-manager to issue certificates.

Using this mode produces the configuration below.

global:
  ingress:
    host: "insights.example.com"

Self-managed

Alternatively you may decide to self-manage certificates, especially if you use a cert authority not supported by cert-manager, e.g. DigiCert. The certificates must be provisioned outside the application, generating a certificate and private key, and then uploaded to the cluster. Within this mode there are three available options.

CLI secret

In this mode, you provide the certificate and private key to the CLI during the installation and it will use them to create a Kubernetes secret.

kxi install setup --ingress-cert <CA_CRT_PATH> --ingress-key <CA_KEY_PATH>

This produces the following values.

global:
  ingress:
    certmanager: false
    host: "insights.example.com"
    tlsSecret: "kxi-ingress-cert"

Existing secret

This is similar to the previous mode except you use an existing secret rather than having the CLI create one.

kxi install setup --ingress-cert-secret kxi-ingress-custom

This produces the following values.

global:
  ingress:
    certmanager: false
    host: "insights.example.com"
    tlsSecret: "kxi-ingress-custom"

Ingress default certificate

In some cases your Kubernetes ingress controller may be configured with a TLS certificate. If so you can configure your deployment without an ingress certificate and allow it to use the ingress default. To do this, pass the --ingress-certmanager-disabled flag to the CLI. This disables cert manager and does not configure any certificate for the application ingress.

kxi install setup --ingress-certmanager-disabled

This produces the following values.

global:
  ingress:
    certmanager: false
    host: "insights.example.com"

Ingress class

kdb Insights Enterprise defaults to using the nginx ingress class. This is used to configure the specific ingress controller to use. This can be customized if you want to use another ingress controller.

global:
  ingress:
    host: "insights.example.com"
    class: "nginx-inc"

nginx default

If your cluster does not have an ngnix ingress class, you must set this value to your deployed ingress class name.

Licensing

This section deals with the configuration of your KX license and the collection of usage logs if you're on a consumption-based license agreement.

global:
  license:
    secretName: "kxi-license"
    onDemand: false

kxi-acc-svc:
  enabled: true
  accounting:
    serviceAccountSecret: ""
    provider: ""
    region: ""

global.license

secretName

variable type example
secretName string "license-secret"

The secretName field is required and should point to a secret containing a valid kdb+ license file. kdb Insights Enterprise will mount this as a file into each pod at /opt/kx/lic. The license secret can be automatically created as part of the CLI install process.

onDemand

variable type example
onDemand boolean false

Indicates the type of license being used. The default is false and indicates a kx.lic is stored in license.secretName

To use an on-demand (kc.lic) license, this can be flipped to true. If running with this license mode kxi-acc-svc.enabled should be set to false.

kxi-acc-svc

Use these values to configure the kxi-acc-svc workload. Enable kxi-acc-svc when using the kdb Insights Enterprise kx.lic so that it automatically collects usage data for the application. You can configure kxi-acc-svc to automatically upload this usage data into object storage for consumption by KX.

Note

For more information on usage data collection and shipping, see the kdb Insights Enterprise license docs.

enabled

variable type example
enabled boolean true

Determines whether to deploy the license accounting service. This is enabled by default. Use it in conjunction with a kx.lic. If using an on-demand kc.lic it should be disabled.

serviceAccountSecret

variable type example
serviceAccountSecret string "kxi-license"

This parameter relates to the automatic shipping of kdb Insights Enterprise usage data back to KX. It is optional and not set by default. If populated, it should point at a k8s secret name with a klic-serviceaccount-token field. The content of this field should be a klic service account token of the form "Bearer ..".

For more information see the self-service licensing docs.

provider

variable type example
provider string ""

This parameter configures which cloud provider the usage data is written to. Valid values are: aws, azure or gcp [default]. If empty, it uses the default.

region

variable type example
region string ""

This parameter configures the cloud provider region the usage data is written to. Valid values are: US [default], GB, EU, AU. If empty, it uses the default.