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....
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: 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
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 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 -
soft-az 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 be scheduled on nodes which do not already have a pod of that Deployment/StatefulSet 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 client-controller service.
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.
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
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
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
... 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
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
"sharedfiles", this is further discussed here.