Deploying Sisense on AKS with Azure Files Premium

Last updated: October 21, 2026

Tier Deployment
Enterprise On-Prem

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.

Prerequisites

  • Sisense version L2021.1.4 (or later)
  • An installed Azure CLI version on the system
  • AKS with CSI Enabled. When azure_csi.enabled is true, the installer checks for the csi-azuredisk-node DaemonSet in the kube-system namespace and stops with an error if it does not exist.
  • Azure Files Premium CSI drivers (regular/non-premium do not provide enough IOPS for Sisense)
  • The general AKS prerequisites (installation machine, Linux user, pod capacity, and node pool labels). See Deploying Sisense on Azure Kubernetes Service.

Deploying Sisense with Azure Files

It is recommended to deploy Azure Files via NFS (rather than SMB/"azurefile").

Deploying Sisense via NFS Protocol Access to the Azure Files Premium Storage

  1. Go to Deploying Sisense on Azure Kubernetes Service and complete the deployment procedure, starting with the step that directs you to open and edit the cloud_config.yaml file.

  2. In the cloud_config.yaml file, set the following parameters. The installer installs the NFS CSI driver and creates the nfs-csi StorageClass for the shared storage, unless an nfs-client StorageClass already exists.

storage_type: nfs
nfs_server: "<your NFS server address>"
nfs_path: "<your NFS remote path>" 
              

Deploying Sisense with Azure Files Using CSI Drivers via SMB Protocol Access

The Azure Files Container Storage Interface (CSI) driver is a CSI specification-compliant driver used by Azure Kubernetes Service (AKS) to manage the lifecycle of Azure Files shares deployed in storage accounts.

The CSI is a standard for exposing arbitrary block and file storage systems to containerized workloads on Kubernetes. By deploying the CSI, AKS can write, deploy, and iterate plug-ins to expose new, or improve existing, Kubernetes-based storage systems without having to touch the core Kubernetes code or depend on the Kubernetes code release cycles.

To create an AKS cluster with CSI driver support:

Before you deploy Sisense, use the following script to deploy AKS with CSI Drivers enabled.

curl http://data.sisense.com/linux/scripts/sisense_azure_aks-csi.sh | bash
      

To deploy Sisense with Azure Files using CSI Drivers:

  1. Download a Sisense version package. Contact your Sisense Customer Success Manager for a link to the latest version.

    wget [sisense-linux-deployment-link]
                  
  2. Extract the Sisense package.

    tar zxf [sisense-linux-deployment-package-name]
                  
  3. Navigate to the directory where you extracted the tar.gz file.

    cd sisense-$sisense_version
                  
  4. Open the configuration file for editing (for older versions open ./installer/experimental.yaml).

    vim ./installer/extra_values/installer/installer-values.yaml
                  
  5. Set the azure_csi enabled parameter to true.

    azure_csi:
      enabled: true
                  

    Note:

    If you set azure_csi: false, the Sisense installation uses In-tree (Non CSI) Premium Azure Files Drivers.

  6. Go to Deploying Sisense on Azure Kubernetes Service and complete the deployment procedure, starting with the step that directs you to open and edit the cloud_config.yaml file.

  7. In the cloud_config.yaml file, set the following parameters:

    • To use the SMB protocol for accessing your Azure Files Premium storage, set:

    storage_type: azurefile
                  

    For more information about these parameters, and all parameters in the cloud_config.yaml file, see Deploying Sisense on Azure Kubernetes Service.

After you complete the Sisense deployment, you can use the URLs returned by the installer to access Sisense.

Azure Files StorageClass Settings

Azure Files over SMB does not support changing file ownership (chown) or permissions. Every file and directory on the share appears with the owner, group, and modes set in the StorageClass mountOptions. Sisense pods run as UID and GID 1000 by default (run_as_user and run_as_group). If the uid and gid mount options do not match these values, the Sisense pods that prepare the shared storage fail on first start with Operation not permitted.

When storage_type is azurefile, the installer creates one of the following StorageClasses and sets uid and gid from run_as_user and run_as_group:

Installer setting StorageClass name Provisioner
azure_csi.enabled: false (default) sisense-azurefile-premium kubernetes.io/azure-file (in-tree)
azure_csi.enabled: true sisense-azurefile-csi-premium file.csi.azure.com (CSI)

The CSI StorageClass that the installer creates (shown with the default UID and GID of 1000):

Copy
ERROR: Invalid Code Highlighting Language

The in-tree StorageClass sisense-azurefile-premium uses the provisioner kubernetes.io/azure-file, skuName: Premium_LRS, and the first six mount options above (dir_mode=0777, file_mode=0777, uid, gid, mfsymlinks, cache=strict).

If you install Sisense with Helm directly, create the StorageClass yourself with these mount options, set global.kubernetesCloudProvider: azure and global.storageType: azurefile, and set sisense-utils.azureCsi.enabled: true to use sisense-azurefile-csi-premium (or leave it false to use sisense-azurefile-premium). If you change global.securityContext.runAsUser or runAsGroup, change uid and gid to match.

Size of the Shared Volume

On AKS, the shared ReadWriteMany volume requests the larger of sisense_disk_size and azure_default_disk_size (default 1200 GB, set in installer/extra_values/installer/installer-values.yaml). The Helm chart equivalent is sisense-utils.azureDefaultDiskSize (default 1200). The performance of an Azure Files Premium share scales with its provisioned size, so reduce this value only if you have confirmed that a smaller share performs well enough.

For more information, see Storage Requirements for Self-Deployment.