Deploying Sisense on Azure Kubernetes Service

Last updated: October 21, 2026

Tier Deployment
Enterprise On-Prem

Sisense can be provisioned on Azure Kubernetes Service (AKS).

Tip: Already have a Kubernetes cluster? You can install Sisense with Helm directly, without sisense.sh, a Linux install host, an SSH key, or sudo. See Installing Sisense with Helm on an Existing Cluster (Multinode/Cloud) and Choosing an Installation Method.

To provision Sisense, you must download and extract the Sisense Linux archive. This archive includes a configuration YAML file, which contains all the configuration settings required to deploy a single-node or multi-node cluster on the Azure Kubernetes Service.

You can customize your installation by setting various parameters in the cloud configuration YAML file. Once the parameters have been defined, you run the script to deploy Sisense, and then retrieve the URL to access the Sisense application online.

You run sisense.sh from a Linux machine that has kubectl access to your AKS cluster. The installer works only through the Kubernetes API: it does not connect to, or run anything on, the AKS nodes.

Prerequisites

  • az shell or Azure CLI.

  • A Linux machine to run the installer (the installation machine), running one of the operating systems that the installer accepts: Red Hat Enterprise Linux 8, 9, or 10; Ubuntu 22.04, 23.04, 24.04, or 26.04; CentOS 8 or 9; Rocky Linux; Oracle Linux; or Amazon Linux 2 or 2023.

  • On the installation machine, a regular (non-root) Linux user that can run sudo without a password (NOPASSWD) for the duration of the installation. You can remove the NOPASSWD rule after the installation. No privileges are required on the AKS nodes. The same user needs kubectl access to the cluster with cluster-admin rights (a working ~/.kube/config, for example after az aks get-credentials). For details, see Privileges and Permissions for Self-Deployment.

  • Each node listed in k8s_nodes must report a pod capacity of at least 58. The installer checks this and stops if a node has a lower capacity. To check a node, run:

    kubectl get node <node-name> -o jsonpath='{.status.capacity.pods}'
  • Sisense node labels applied to your AKS node pools. See Labeling AKS Node Pools below.

Labeling AKS Node Pools

The Sisense Helm chart schedules its pods only on nodes that carry the label node-<namespace>-Application=true, where <namespace> is the value of namespace_name (for example, node-sisense-Application=true). The label key is case-sensitive, and the value is the string true. The installer also applies node-<namespace>-Query=true and node-<namespace>-Build=true according to the roles you assign in k8s_nodes.

By default, the installer applies these labels with kubectl. On AKS, apply the labels to the node pools instead (for example, with az aks nodepool update --labels, or when you create the node pool), so that nodes added or replaced by AKS inherit them, and then set skip_labeling: true in installer/extra_values/installer/installer-values.yaml:

  • Labels that AKS manages at the node-pool level cannot be removed or changed with kubectl. If the node pools carry Sisense labels and skip_labeling is false, the installer logs an error that relabeling is not supported and continues with the labels that already exist on the nodes.

  • Labels applied with kubectl are lost when AKS replaces or adds a node (for example, during scaling or a node image upgrade).

For more information, see Autoscaling and Linux.

Note:

  • If you are uninstalling/reinstalling Sisense on AKS/GKE in order to migrate to the new nfs-csi controller in Sisense version L2025.2 or newer, you must manually remove the nfs-client storage class. To do that:

    • Run kubectl delete sc nfs-client

    • Delete the helm chart: helm delete -n default nfs-client-provisioner

      • If nfs-client-provisioner is installed on a different utils_namespace, run the following command:
        helm delete -n ${utils_namespace} nfs-client-provisioner

    Otherwise the new installation will still use nfs-client-provisioner.

Storage on AKS

Set storage_type to one of the following:

  • nfs: Uses an existing NFS server (for example, Azure NetApp Files or Azure Files over NFS) that you specify in nfs_server and nfs_path. The installer installs the NFS CSI driver and creates the nfs-csi StorageClass (unless an nfs-client StorageClass already exists).

  • azurefile: Uses Azure Files Premium over SMB. The installer creates the StorageClass sisense-azurefile-premium (in-tree kubernetes.io/azure-file provisioner). If you set azure_csi.enabled: true in installer/extra_values/installer/installer-values.yaml, it creates sisense-azurefile-csi-premium (file.csi.azure.com) instead. See Deploying Sisense on AKS with Azure Files Premium.

MongoDB and ZooKeeper use the AKS StorageClass named default for their ReadWriteOnce volumes.

Size of the shared volume on AKS: On AKS, the shared ReadWriteMany volume requests the larger of sisense_disk_size and azure_default_disk_size. azure_default_disk_size is set in installer/extra_values/installer/installer-values.yaml and defaults to 1200 GB, because the performance of an Azure Files Premium share scales with its provisioned size. When you install with Helm directly, the equivalent value is sisense-utils.azureDefaultDiskSize (default 1200). Reduce it only if you have confirmed that a smaller share performs well enough for your workload.

For the storage requirements of all installation methods, see Storage Requirements for Self-Deployment.

SSL and the Load Balancer on AKS

When is_ssl is true, the installer deploys NGINX Gateway Fabric to terminate TLS and removes any earlier nginx-ingress release. On AKS, NGINX Gateway Fabric is exposed through a LoadBalancer Service whose Azure health probe uses the path /healthz. NGINX Gateway Fabric requires Kubernetes 1.32 or later; the installer stops with an error on an older cluster.

Deploying Sisense on Azure Kubernetes Service

  1. Configure the local kubectl.

    az aks get-credentials --resource-group myResourceGroup --name myAKSCluster
  2. Download a Sisense version package. Contact your Sisense Customer Success Manager for a link to the latest version.

    wget $sisense_url
  3. Extract the Sisense package.

    tar zxf $package_name
  4. Navigate to the directory where you extracted the tar.gz file.

    cd sisense-$sisense_version
  5. Access the config.yaml file.

    vim cloud_config.yaml
  6. Edit the following values in the cloud_config.yaml file.

    Parameters Value
    k8s_nodes:
    									- { node: node1, roles: "application, query" }
    									- { node: node2, roles: "application, query" }
    								- { node: node3, roles: "build" }

    The K8S node/nodes are the set of machines that will be used to run Sisense.

    node: Enter the name of your nodes to be included in the cluster. You can retrieve their values with the command:

    kubectl get nodes

    role: Define the role of the node with one of the following values: application, query, and build.

    Note:

    Node names may not include uppercase letters. Node names can only include lowercase letters, digits and hyphens. Hyphens cannot be the last character in the node name.

    The installation machine is used only during installation to run the installation scripts. The Installation machine can be one of the K8S nodes, but it can also be a different machine (remote installation).

    deployment_size: "small"

    Set to large to increase pod resource limits allocated for the application.

    cluster_visibility: true
    For security restrictions that revoke cluster role permissions, set to false to disable the following Sisense workflows.
    • Watching Sisense Nodes that exist or are added to the cluster (E.g. for the data-groups feature). In this case, a customer should use manual labeling method
    • Updating the logging system with the customer registered owner ID.
    offline_installer: false
    Set to true when you are using an offline installer.
    #docker_registry: ""

    (Optional) Only required if you are using an offline installer (

    offline_installer = true
    ).

    Enter your server's address.

    #pull_secrets_name: ""

    (Optional) Only required if you have entered a value for the

    docker_registry
    parameter.

    Enter the docker secret name if your registry is private.

    update: false

    Enter true If you are upgrading Sisense.

    Otherwise, use false as the default value.

    notify_on_upgrade: true

    If set to true, the Sisense application will not be accessible during upgrades. Instead, a system maintenance notification will appear.

    is_kubernetes_cloud: true

    Enter true if you already have a Kubernetes cluster.

    kubernetes_cluster_name: ""

    Enter your Kubernetes cluster name.

    kubernetes_cluster_location: ""

    Enter your Kubernetes cluster location. For AKS, enter the resource group of the cluster.

    								kubernetes_cloud_provider: ""

    Enter azure.

    cloud_load_balancer: false

    Enter true if you have defined a load balancer.

    For more information see, Setting Up a Load Balancer for more information.

    cloud_auto_scaler: false

    Enter true if your node pools use autoscaling.

    On AKS, the installer does not install a cluster autoscaler; use the autoscaler built into AKS node pools. With true, the Sisense logging components can run on any node labeled for Sisense instead of being pinned to the first node.

    high_availability: true

    Enter false if your system does not support redundancy between the nodes.

    application_dns_name: ""

    Enter the DNS name.

    • If no DNS name is entered, the default value is the external IP of the first node in the cluster.
    • If the is_ssl parameter is set to true, enter the Common Name for this parameter.
    • If an external load balancer is used for the Common Name, add the http:// or https:// prefix to the entry.

    Note:: You can only define this parameter when installing or upgrading Sisense. After defining this value, you can view this value under General Settings in the Sisense Admin page.

    linux_user: ""

    Enter the name of the Linux user that runs sisense.sh on the installation machine.

    Use a regular (non-root) user that can run sudo without a password (NOPASSWD) for the duration of the installation; you can remove the NOPASSWD rule afterwards. This is needed only on the installation machine. No privileges are required on the AKS nodes: the installer does not connect to or run anything on them. The same user needs kubectl access to the cluster with cluster-admin rights.

    ssh_key: ""

    SSH is not used when you install on an existing AKS cluster. However, if ssh_key is empty, the installer still prompts for the password of the Linux user defined in linux_user.

    To skip the prompt (for example, for an unattended installation with -y), set ssh_key to the path of any existing key file. The installer checks only that the file exists and sets its permissions to 400.

    storage_type: ""

    Enter one of the following:

    nfs
    azurefile

    If the value is nfs, define the nfs_server and nfs_path values.

    See Storage on AKS.

    nfs_server: ""

    Enter your NFS server's address (IP or DNS).

    nfs_path: ""

    Enter your NFS server's location.

    The mounting point for each logical disk (Sisense app, MongoDB, and Zookeeper) is created under this path.

    mongodb_disk_size: 20

    Enter the amount of disk space allocated for the Sisense application database.

    This value should be multiplied by the number of nodes used in your deployment.

    It is recommended to leave the default of 20GB. If only metadata is stored in MongoDB, there is no need to increase the size.

    zookeeper_disk_size: 2

    Enter the amount of disk space allocated for the ZooKeeper service. This value should be multiplied by the number of nodes in your deployment. It is recommended to leave the default of 2GB. If only metadata is stored in the Zookeeper service, there is no need to increase the size.

    timezone: "UTC"

    Enter the system time zone. Applicable to the time zone of the relative date-time filters. Format: TZ database name (i.e., UTC, US/Central, Asia Tokyo, Etc/GMC+6).

    namespace_name: sisense

    Enter the name of the Kubernetes namespace. By default, the namespace is Sisense.

    If you have multiple deployments, you should have a unique namespace for each deployment For example, there might be a development and production environment. Additionally for multiple deployments:

    • Each environment must have a uniquegateway_portvalue.
    • For each deployment after the first, the value of the update must be set to true.

    Note:: Kubernetes ports should be released (Non-listening mode).

    gateway_port: 30845

    Enter the port of the API gateway for your deployment. Do not set this port to 443 if setting up SSL.

    If you are not implementing SSL, this is the port used to connect to Sisense.

    is_ssl: false

    Enter true to initialize SSL. Sisense creates a SSL load balancer on port 443.

    SSL is terminated by NGINX Gateway Fabric, which requires Kubernetes 1.32 or later.

    If you enter true, see Setting Up SSL for Sisense on Linux for more configuration information.

    ssl_key_path: ""

    If you connect to your server securely, enter the SSL keypath.

    When SSL is defined, the Sisense API Gateway Port will be 443 and not the value defined in the gateway_portparameter.

    ssl_cer_path: ""

    If you connect to your server securely, enter the SSL certificate path (.cer file).

    internal_monitoring: true

    Enter false to disable a Prometheus supported Grafana dashboard from monitoring your deployment. For more information, see Monitoring Sisense on Linux.

    uninstall_sisense: false

    Enter true to uninstall Sisense services, but leave your Kubernetes infrastructure unchanged, in case it's needed in the future.

    remove_user_data: false
    Enter true to delete all user data. This deletes your ElastiCube models, application database, message broker, and add-ons.

    signature_validation: false

    Enter true to enable Image Signature Validation.

  7. Run the configuration script.

    ./sisense.sh cloud_config.yaml

    Your configuration settings are displayed with a message to confirm that you want to deploy Sisense with these settings.

  8. Enter Yes to confirm that you want to deploy Sisense.

    Enter No to abort the deployment.

    If you entered Yes, the script deploys Sisense. The installer writes its log to sisense-installer.log in the directory you ran ./sisense.sh from. If there are any issues, check this file.

When the installation finishes, the installer displays the address for accessing Sisense. The address is also written to sisense-installer.log. It is based on your settings:

  • If you set application_dns_name, Sisense is available at that address.

  • If you set cloud_load_balancer: true, Sisense is available at the external address of the api-gateway-external Service. To display it, run:

    kubectl get svc api-gateway-external -n <namespace>
  • Otherwise, for non-secure connections, Sisense is available at http://<node-address>:<gateway_port>/ (by default, port 30845). For secure connections, use https://<application_dns_name>/.

Note:

The kubectl cluster-info command returns the addresses of the Kubernetes control plane, not the address of Sisense. The installer does not install the Kubernetes Dashboard.

To verify that all your services are running as expected, you can enter the Sisense URL with the port and /app/test to the end of the address in your browser. This displays the status of each of your services. For example:

0.0.0.0:PORT/app/test

Tip:

For more information, see Troubleshooting Pods in Kubernetes Clusters on the Sisense Community site.