Overriding Helm values during the installation

[OlegV]

Overriding Helm values during the installation

There is a frequent question of how to keep the changes made on resource limits, number of replicas, etc. during an upgrade, or deploy customized Sisense configuration on multiple environments.

You can override any values within Sisense Helm Charts by using the Extra-Values Feature.
Select a target Helm Chart and create your own override-values file for each of the following supported Helm Charts:

• installer-values
• Sisense
• Prometheus-operator
• cluster-metrics
• logging
• nginx
• alb-controller
• cluster-autoscaler
• nfs-client
• nfs-server
• aws-ebs-csi
• descheduler

The first values file (“installer-values”) sets the additional installation values that are described here: https://docs.sisense.com/main/SisenseLinux/configuring-additional-installation-values.htm

The “Sisense” refers to the Sisense application helm chart installed by the Helm Provisioner.

Other files are intended for the settings for extra helm-charts, which may be installed (or not) according to your particular configuration of the main values.yaml and installer-values.yaml

This feature is mentioned here, but let’s discover it in more detail.

That’s the example of a file that:

1. sets the specific resource limits for the build pod
2. sets the specific resource limits for the Galaxy pod
3. sets the number of replicas for the Galaxy pod to 3
4. because the existing anti-affinity rules won’t allow running 3 Galaxy pods on default 2 application nodes, we need to override the affinity section. It sets the podAntiAffinity to null and keeps the nodeAffinity

galaxy:
  resources:
    limits:
      cpu: 1600m
      memory: 8600Mi
  replicaCount: 3
  affinity:
    podAntiAffinity: null
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: "node-sisense-Application"
            operator: In
            values:
            - "true"
build:
  resources:
    limits:
      cpu: 2
      memory: 1600Mi

Assuming that the file name is ‘sisense-override.yaml’ you will need to run the installation this way:

helm upgrade prov-sisense https://data.sisense.com/linux/helm/charts/incubator/provisioner-L2023.5.0.148.tgz -f values.yaml --namespace=sisense --install --set-file sisense=sisense-override.yaml

It can also be embedded in the values.yaml file this way:

[...]
persistence:
  efsAwsRegion: ""
  efsFileSystemId: ""
  enabled: true
  fsxDnsName: fs-0697481ffdsds463.fsx.us-east-2.amazonaws.com
  fsxMountName: dccsdbmv/
  mongodbDiskSize: 20
  nfsPath: ""
  nfsServer: ""
  rwoScName: ""
  rwxScName: ""
  sisenseDiskSize: 70
  storageType: fsx
  zookeeperDiskSize: 2

sisense: |
  galaxy:
    resources:
      limits:
        cpu: 1600m
        memory: 8600Mi
    replicaCount: 3
    affinity:
      podAntiAffinity: null
      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: "node-sisense-Application"
              operator: In
              values:
              - "true"
  build:
    resources:
      limits:
        cpu: 2
        memory: 1600Mi
        
timeZone: UTC
tlsSecretName: ""
uninstall:
  clusterResources: false
  namespacedResources: false
  removeUserData: false

Here is another example:

When cloud.autoScaler option is set to false, the installer assumes that Sisense is deployed on permanent hosts and uses the first node for storing logs. Thus, it sets NodeSelector for fluentd service and logrotate job to the first node. If cloud.autoScaler option is set to true, and the installer sets Affinity rules for fluentd and logrotate, keeping them on the same application node, which can be replaced because of an autoscaler. It also deploys a cluster-autoscaler on AWS, which comes with the installer.

Suppose you don’t want to install the cluster-autoscaler that comes with Sisense (e.g. you have your autoscaler deployed) but still expect that nodes can be replaced. In that case, you can override settings for the logging component only.

The configuration below sets Affinity rules for the fluentd service instead of NodeSelector. It’s the content of ‘logging’ values.

## Sisense Logging chart extra value
global:
  clusterAutoScaler:
    enabled: true

How does it work? This solution comes from logging-monitoring/templates/fluentd/deployment-fluentd.yaml. We override the global.clusterAutoScaler.enabled to use the Affinity rules instead of a NodeSelector.

[...]
      {{- if .Values.affinity }}
      affinity: {{- include "logging-monitoring.tplValue" (dict "value" .Values.affinity "context" $) | nindent 8 }}
      {{- else if .Values.global.clusterAutoScaler.enabled }}
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: "node-{{.Release.Namespace}}-Application"
                operator: In
                values:
                - "true"
      {{- end }}
      {{- if .Values.nodeSelector }}
      nodeSelector: {{- include "logging-monitoring.tplValue" (dict "value" .Values.nodeSelector "context" $) | nindent 8 }}
      {{- else if not .Values.global.clusterAutoScaler.enabled }}
      nodeSelector:
        kubernetes.io/hostname: {{.Values.global.k8s_node_1}}
      {{- end }}
[...]

You can either use it as a separate file

helm upgrade prov-sisense https://data.sisense.com/linux/helm/charts/incubator/provisioner-L2023.5.0.148.tgz -f values.yaml --namespace=sisense --install --set-file logging=logging-override.yaml

or as a section of values.yaml

[...]
  build:
    resources:
      limits:
        cpu: 2
        memory: 1600Mi

logging:
  global:
    clusterAutoScaler:
      enabled: true
        
timeZone: UTC
tlsSecretName: ""
uninstall:
  clusterResources: false
  namespacedResources: false
  removeUserData: false

Using the examples and explanation above, you can define your own custom settings for Sisense and its components that should help you deploy unified configurations for multiple instances or keep your changes during upgrades.