Base configuration
This page explains the base configuration for a kdb Insights Enterprise deployment. This enables you to customize configuration around image registries, ingress certs, and licenses.
KX Nexus
The KX Nexus repository will be sunsetted in the future. Nexus links on this page are provided as a temporary alternative to the KX Downloads Portal for existing users. The KX Downloads Portal is the preferred repository for all use cases and KX Nexus links will be removed once the KX Nexus repository is decommissioned.
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.repository
accordingly.
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.
Data Entitlements
Data Entitlements is turned off by default. To turn this feature on, follow the steps shown here.
Encryption in transit
Everything that is required for data encryption in transit is installed by default either 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 UI.
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, 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.
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
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.
type
variable | type | example |
---|---|---|
type |
string |
k4 |
This field configures which type of license will be 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
will replicate the behaviour of license.onDemand: true
.
If using the kc
or k4
type, then kxi-acc-svc.enabled
should be set to false
.