Autoscaling and Linux

Last updated: October 21, 2026

Sisense Cloud-Native Linux deployments support autoscaling on AWS deployments using AWS autoscale groups and on managed Kubernetes services whose node pools scale automatically, such as GKE (see Deploying Sisense on Google GKE) and AKS (see Deploying Sisense on Azure Kubernetes Service). Autoscaling allows you to grow or reduce the size of your deployment as your usage changes.

In Sisense, a minimum clustered deployment is comprised of three nodes. A typical deployment would have two app/query nodes, and one build node, with the infrastructure services replicated across all of them. You can configure as many additional nodes as you need, to handle the typical system load.

When your usage peaks, you can use autoscaling to add or remove nodes from your deployment automatically.

For example, your system may have peak loads at the beginning of the month, when many reports are due. To support the need for many more queries, you may choose to add additional query nodes. Using the Sisense autoscale capabilities, query nodes are added when you need them and removed when they are no longer needed. Another example includes shopping days during the holiday season where you may experience peak usage times. You may need to add additional app nodes and/or query nodes to handle more users accessing Sisense.

The Sisense autoscale capabilities work together with an AWS auto-scale node-group. There are two mechanisms that work together: the cluster auto-scaler that runs on the Kubernetes level and the node group auto-scale that works at the level of AWS and checks the available resources to increase the number of node instances.

Using this mechanism the cluster autoscale can request additional nodes when needed.

For example, you can configure the node group to add additional nodes when the average CPU utilization exceeds a specified threshold. This can be relevant for any of the nodes, but especially the build and query nodes that are CPU heavy.

For the app nodes, you can configure the addition of more nodes, when the application load balancer request count exceeds a specific threshold. This could be a relevant parameter to detect for websites that have peaks user loads. Both the CPU usage and the application load balancer values are defined on the node group auto-scale settings.

Additionally, on the Kubernetes level, the cluster-auto-scaler retrieves additional nodes from the node-group when there are not enough resources to deploy additional pods.

Both of these mechanisms will also remove nodes when they are no longer needed based on the defined parameters.

The additional nodes are added to the default data group, or to the label of the data group, and are automatically used by the data group.

Preparing your Environment for Autoscaling

If you want to dynamically add worker nodes to your Sisense deployment, you need to apply the following node labeling strategy so Sisense can use your nodes. As these nodes are created dynamically by your cloud-based Kubernetes, Sisense requires a specific label format to identify and use them.

The Sisense Helm chart schedules its pods only on nodes that carry the label node-[NAMESPACE]-Application=true, where [NAMESPACE] is your internal Namespace name for Sisense (for example, node-sisense-Application=true). Every node that should run the Sisense platform pods must have this label. The label key is case-sensitive, and the value is the string true. In addition, label nodes with their Sisense roles:

Node 1 - node-[NAMESPACE]-Application=true, node-[NAMESPACE]-Query=true
Node 2 - node-[NAMESPACE]-Application=true, node-[NAMESPACE]-Query=true
Node 3 - node-[NAMESPACE]-Build=true

Apply the labels at the node group or node pool level. Nodes that the autoscaler adds are created from the node group or node pool definition, so they receive only the labels defined there. Labels that you or the sisense.sh installer apply to individual nodes with kubectl label node are lost when a node is replaced. Define the labels in your EKS node group, AKS node pool, or GKE node pool, and set skip_labeling: true in installer/extra_values/installer/installer-values.yaml so that the installer does not relabel the nodes. (By default, the installer removes the Sisense labels from all nodes and applies them only to the nodes listed in k8s_nodes.) On AKS, labels defined on a node pool cannot be changed with kubectl; if skip_labeling is false, the installer logs an error and continues with the existing labels.

To label an existing node manually (for example, for a test), use:

kubectl label node NODE_NAME node-NAMESPACE-Application=true --overwrite
kubectl label node NODE_NAME node-NAMESPACE-Query=true --overwrite
kubectl label node NODE_NAME node-NAMESPACE-Build=true --overwrite

Enabling Autoscaling

When deploying Sisense in your Kubernetes environment, in the Configuration YAML file, the cloud_auto_scaler parameter must be set to true:

• Amazon EKS: The installer installs the Kubernetes Cluster Autoscaler, which adds nodes to your node groups as needed, so if a node fails or your load is higher than normal, additional nodes can be added.

• AKS and GKE: The installer does not install a cluster autoscaler. Enable the autoscaler built into your node pools. Setting cloud_auto_scaler to true lets the Sisense logging components run on any node labeled for Sisense instead of being pinned to the first node.

Autoscaling Demonstration

To learn about autoscaling and to see it in action, see the webinar below.

In this webinar, Sisense provides a demonstration of the Sisense autoscale capabilities on a very large deployment including 1000 dashboards, 1000 ElastiCubes, shared with 10,000 users associated with 1000 user groups.

As part of this webinar, Sisense has provided scripts you can use and run to set up your own EKS with Fsx deployment. The scripts are located in an archive that you can download here:
https://data.sisense.com/linux/scripts/webinar.tgz

From this archive, you can run the following source script: script_full_eks_fsx.sh

The demonstration starts with six nodes (two app nodes, two query nodes and two build nodes). Each of the nodes has eight cores and 32GB RAM.

The system was defined so that ElastiCubes had an idle timeout, and would shut-down when they were not in-use. 6 nodes were enough for idle time. Building the ElastiCubes utilized additional CPU and RAM causing additional nodes to be utilized increasing the size of the deployment and adding an additional four query nodes, an additional two build nodes, increasing the number of nodes to twelve. The additional query and build nodes are terminated when they are no longer needed.

Extending Timeouts

When scaling new nodes for builds, if you do not have enough resources to support a new pod, the build pod may become stuck in a pending state and is then killed before a new pod is loaded. You can change the default timeout of 90 seconds to 360 seconds to allow enough time for a new pod to be started with the following command:

si config set -key management.TimeToWaitBeforeCheckIfCubeStartedSeconds -new-value 360

To access the Sisense CLI, see Using Sisense CLI Commands.