Skip to content

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 can be provided to customize features such as certifications/authorities to use for external access points, metrics, resource allocation, default users, affinities....

Some configurations are considered global and utilized by all services within the system and some would be specific to a single service.

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.

insights-config.yaml

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"

    service:
      useInternalLBAnnotations: true

keycloak:
    auth:
        existingSecret: kxi-keycloak
    postgresql:
        auth:
            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
  • Service LoadBalancer annotations

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.

global configuration area
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
Service Annotations Internal LoadBalancer Annotations
Additional Additional Global variable that may be applied

Service Configuration

Currently available service configuration includes

service configuration area
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 to provide node level resilience for all services. This is achieved by providing an 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 four default affinity presets - hard, soft, hard-az and soft-az while still allowing advanced users the ability to customize the affinity settings as Kubernetes allows.

A hard affinity setting is the default setting for all services initially deployed with a requiredDuringSchedulingIgnoredDuringExecution setting, ensuring that pods will only be scheduled on nodes which do not already have a pod of that Deployment/StatefulSet running on them.

A 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 client-controller service.

A hard-az affinity setting can be configured for any service within the install configuration file. This will deploy the service with a requiredDuringSchedulingIgnoredDuringExecution setting, ensuring that pods will only be scheduled within availability zones which do not already have a pod of that Deployment/StatefulSet running.

A soft-az affinity setting can be configured for any service within the install configuration file. This will deploy the service with a preferredDuringSchedulingIgnoredDuringExecution setting. This will firstly attempt to scheduled a pod within availability zones which do not already have a pod of that Deployment/StatefulSet running. If this cannot be satisfied it will then attempt to schedule the pod on a node where a pod of that Deployment/StatefulSet is not already running. As this is a preferredDuringSchedulingIgnoredDuringExecution anti-affinity term, if all terms can not be satisfied, a pod will be scheduled on a node along side an existing pod of that Deployment/StatefulSet.

Hard Anti Affinity

Where hard or hard-az has been set, if the affinity terms cannot be satisfied, one or more replicas may not be scheduled.

hard may cause a node pool auto scale, where this is permitted within your node pool configuration.

For services launched by the KXI Operator, the same affinity presets of hard, soft, hard-az and soft-az are available. Services, by default, will be launched with a hard affinity based on the uniquely identifiable labels for a service. An alternative affinity may be applied for each service launched by the KXI Operator through the install-config.yaml provided at install time for the KX Insights Platform as shown in the example below for the dap service under the kxi-operator

install-config.yaml

...
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 request and 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

Packaging Storage Configuration

Configuration used for defining the PVC used for the storage of packages is defined within the insights-config.yaml provided when installing the KX Insights Platform. The structure of this configuration is highlighted below:

packages:
  storage: 20Gi
  storageClassName: "sharedfiles"

Within this configuration the "sharedfiles" storageClassName is defined within the Terraform scripts provided for version 1.2.0+ and any deployment of the KX Insights Platform which makes use of these. This is an NFS backed storage solution for GCP/AWS or Azure. Use of this requires a user to have provisioned a CSI driver and have available a custom configured storageClassName named "sharedfiles", this is further discussed here.