KX Insights Platform Configuration
KX Insights Platform requires a minimal amount of configuration to launch the application within a cluster. This provides image repositories, secrets, licenses and ingress configuration. The KX Insights Platform CLI installer provides a wizard to quickly build a configuration with
kxi install setup. Full details here. As well as the configurations stated below, advanced configurations cane be provided to customize features such as certifications/authorities to use for external access points, metrics, resource allocation, default users, affinities....
Global configuration is defined under the
.Values.global object as shown in the example yaml below under the
global map. Configuration related to specific services will have their own
.Values parent object; highlighted by the
keycloak configuration in the example below.
global: image: repository: registry.dl.kx.com imagePullSecrets: - name: kx-insights-nexus license: secretName: kx-license-info caIssuer: name: kxi-certificate secretName: kxi-certificate ingress: host: "dev.kxinsights.domain.com" issuer: name: "letsencrypt" keycloak: auth: existingSecret: kxi-keycloak postgresql: existingSecret: kxi-postgresql
In this case we are providing/overriding default values for globals
- The image repository
- A secret for our repository
- A valid KX License stored in a secret
- Certificate Authority secret
- Ingress configuration
In addition, we are providing service level configuration for the Keycloak chart with the necessary secrets to allow it to communicate for both the administrative login and the backend database.
To apply this configuration to the KX Insights Platform the file is provided as an argument to the install command.
kxi install run --filepath insights-config.yaml
This section covers these available configurations in detail and each sub-page highlights examples of each configuration, the default values, what each value represents and how to use them.
Available Global configurations
The available global configurations can be split into a number of specific areas which help customize certain parts of the insights install.
|License||KX License values|
|Image||Component Image values|
|Discovery||Service Discovery values|
|Ingress||Ingress Resource values|
|Metrics||Metrics and Service Monitor values|
|Logging||Logging configuration values|
|RT log archival||RT log archival values|
|Security Context||Pod and Container Security Context values|
|Additional||Additional Global variable that may be applied|
Currently available service configuration includes
|Client Controller||Configuration for RT ingestion based clients|
|Keycloak||Configuration for Keycloak auth service|
|Discovery||Service Configuration for Discovery|
|Information Service||Configuration for the Information Service|
|KXI Controller||Configuration for the KXI Controller|
Service Affinity Configuration
Kubernetes provides applications the ability to have control over which nodes the running pods of a service are deployed. Node affinity allows the ability to define which nodes are acceptable for a service and which are not. It also allows a service to add protection against node or zone failure using anti-affinity which can ensure all pods of a statefulset/deployment run on unique nodes.
By default the KX Insights Platform uses anti-affinity property to provide node level resilience for all services. This is achieved by providing a
affinity configuration which uniquely selects labels within the service and ensures that additional pods launched with that uniquely identifiable selector will be allocated different nodes.
For example a service by default when deployed would have an
affinity section similar to
... affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - topologyKey: "kubernetes.io/hostname" labelSelector: matchExpressions: - key: "insights.kx.com/serviceName" operator: In values: - insights-main-api-gateway ...
The KX Insights Platform allows the affinity to be configured on a per service level should you want a different affinity configuration. There are two default affinity presets -
soft while still allowing advanced users the ability to customize the affinity settings as Kubernetes allows.
hard affinity setting is the default setting for all services initially deployed with a requiredDuringSchedulingIgnoredDuringExecution setting, ensuring that pods will only launch on nodes which do not already have an instance of that pod running on them.
soft affinity setting can be configured for any service within the install configuration file. This will deploy the service with a preferredDuringSchedulingIgnoredDuringExecution. An example of how to apply this for a service is shown below for the
For services launched by the KXI Operator, the same affinity presets of
soft are available. Services, by default, will be launched with a
hard affinity based on the uniquely identifiable labels for a service. A
soft affinity can be applied for services launched by the KXI Operator through the
install-config.yaml provided at install time for the KX Insights Platform as shown in example below for the
dap service under the
... client-controller: affinity: soft replicaCount: 5 kxi-operator: config: dap: affinity: soft ...
Service Resource Configuration
All services offer the ability to tune the available resources each service will offer. These resources are aligned with Kubernetes resource configuration. You can define the
limit values for CPU, memory and ephemeral storage depending on the expected load and access to the application. Setting these helps Kubernetes manage pod selection when launching and scaling the cluster.
The Services within the main KX Insights Platform charts, are defined within the
insights-config.yaml provided when installing the KX Insights Platform. Each service has a default setup and allows you to configure this further. The structure of the
resources section is highlighted below. Refer to the Service Configuration for each chart for a working example
resources: limits: cpu: 100m memory: 3072Mi requests: cpu: 100m memory: 1024Mi