Configuration Setup

This page explains the base configuration setup for a kdb Insights Enterprise deployment. This enables you to customize configuration around image registries, ingress certs, and licenses.

Image repository

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

Variable	Type	Global	Example	Default
`image.pullPolicy`	`string`	Y	`"Always"`	`"IfNotPresent"`
`imagePullSecrets`	`list`	Y	`[]`	`["kxi-image-pull-secret"]`

Existing users can use the KX Nexus repository to get the pull secret instead, until Nexus is remove in the future. To use KX Nexus, replace the imagePullSecrets value ["kxi-image-pull-secret"], in the table above, with the value ["kxi-nexus-pull-secret"].

Configure the image repository and pull policy at the global level with the default being the KX Downloads Portal. If you need to self-host the images, the CLI install commands support customizing this default repository and setting the global.image.repositoryaccordingly.

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

global:
  image:
    repository: "portal.dl.kx.com"
  imagePullSecrets:
  - name: "kxi-image-pull-secret"

The following is the KX Nexus equivalent of the above command:

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

Data entitlements

Data Entitlements is turned off by default. To enable this feature, refer to entitlements.

Encryption in transit

Everything required for data encryption in transit is installed by default when you install or upgrade kdb Insights Enterprise.

For new installs of kdb Insights Enterprise, encryption in transit is enabled by default.

You can see whether encryption in transit is enabled by looking at the information menu item in the ribbon icon menu of the kdb Insights Enterprise web interface.

Query Environment(s)

Query Environment(s) (QE) act as sandboxes, providing non-production query paths for ad-hoc data exploration and analysis. This avoids using the main query path, thereby preventing any negative impact on mission-critical production workloads.

The following scenarios are supported.

QE Status	Query APIs	SQL	qSQL	Note
QE disabled	✔️	✔️	❌	Query APIs (getData, getMeta) and SQL (sql, sql2) use the main query path. This is the default for new installations.
QE enabled	✔️	✔️	✔️	Query APIs use the main query path. SQL and qSQL use Query Environment(s). Refer to enable query environment(s) for details. Also note that when upgrading from versions earlier than 1.13 QEs remain enabled by default but can be disabled.
QE disabled but SQL and qSQL explicitly enabled	✔️	✔️	✔️	Query APIs, SQL and qSQL use the main query path. Refer to Enable qSQL when QE disabled for details.

Refer to Query Interface for details about the query methods mentioned above. Refer to Query using q and Setup a a data source for Views for details on querying using the web interface.

Resources

When enabled, Query Environment(s) have the same number of resources as the main query path. Therefore you must ensure your cluster has sufficient resources available to handle this. Refer to query resource configuration for details.

New installations

For new installations of kdb Insights Enterprise, Query Environment(s) are disabled by default to reduce the base size of a kdb Insights Enterprise deployment.

When Query Environment(s) are disabled:

SQL is enabled, and runs on the main query path.
qSQL is disabled

Enable Query Environment(s)

If you wish to enable Query Environment(s) to protect your main query path from ad-hoc data exploration, merge the following to your values.yaml file, as described here:

global:
  queryEnvironments: true

When set, Query Environment(s) are enabled ad-hoc queries are routed to them, avoiding impact on production DAPs.

Upgrades

When upgrading from a version of kdb Insights Enterprise prior to 1.13, Query Environment(s) remains enabled by default to ensure the upgrade does not change the configuration unexpectedly.

If you wish to disable Query Environment(s), merge the following to your values.yaml file, as described here:

global:
  queryEnvironments: false

Enable qSQL when QE disabled

When Query Environment(s) are disabled, by default SQL is enabled on the main query path and qSQL is disabled completely.

Enabling qSQL on the main query path

Enabling qSQL for use on the main querying path is not recommended.

It must not be enabled when row level entitlements are being enforced.

However, if you do want to enable both SQL and qSQL, on your main query path, update your values.yamlfile, as described here, before install or upgrade:

global:
  env: KXI_ALLOWED_SBX_APIS 
  - value: .kxi.sql, .kxi.sql2, .kxi.qsql

Ingress certificates

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, for example, 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
existing secret
Ingress default certificate

CLI secret

In this mode, you provide the certificate and private key to the CLI during the installation and these are used 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 CLI secret mode, except you use an existing secret rather than the CLI create a new 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 explains the configuration of your KX license.

The self-service licensing model previously in use for KX products has been deprecated. Contact your sales representative if you have questions about this, and wish to discuss moving to the new model.

Trial license

global:
  license:
    secretName: "kxi-license"
    type : kc

kxi-acc-svc:
  enabled: false

Commercial license

global:
  license:
    secretName: "kxi-license"
    type : k4

kxi-acc-svc:
  enabled: false

global.license

secretName

The secretName field is required and should point to a secret containing a valid kdb+ license file. kdb Insights Enterprise mounts 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.

Variable	Type	Example
`secretName`	`string`	`"license-secret"`

type

The type field configures which type of license is used by the system. Permitted values are kx, kc and k4. It is intended to replace the license.onDemand field, however, the latter has precedence to ensure backward compatibility. Setting license.type: kc replicates the behavior of license.onDemand: true.

If using the kc or k4 type, then kxi-acc-svc.enabled should be set to false.

Variable	Type	Example
`type`	`string`	`k4`