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:
- sets the specific resource limits for the build pod
- sets the specific resource limits for the Galaxy pod
- sets the number of replicas for the Galaxy pod to 3
- 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.
