Deploying Sisense on Google GKE

Last updated: October 21, 2026

Tier Deployment
Enterprise On-Prem

Sisense can be provisioned on a Google Kubernetes Engine (GKE) cluster.

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 create a GKE cluster if you do not already have one, and then connect to it. After you have completed these steps, you must download and extract the Sisense Linux archive. This archive includes a configuration yaml file, which contains all the configuration settings for deploying a single-node or multi-node cluster.

From the configuration yaml file, 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 GKE cluster. The installer works only through the Kubernetes API: it does not connect to, or run anything on, the GKE nodes.

Prerequisites

  • Installed and configured gcloud
  • Deployed cluster that meets the minimum requirements, running a Kubernetes version supported by Sisense. See Minimum Requirements for Sisense in Linux Environments.

  • 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 GKE nodes. The same user needs kubectl access to the cluster with cluster-admin rights (a working ~/.kube/config, for example after gcloud container clusters 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. 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 removes these labels from all nodes and applies them with kubectl to the nodes listed in k8s_nodes. Labels applied with kubectl are lost when GKE replaces a node (for example, during autoscaling or a node upgrade). If you use autoscaling, or want nodes to keep their labels, apply the labels to the node pool and set skip_labeling: true in installer/extra_values/installer/installer-values.yaml.

  • By default, the GCE blocks traffic between hosts. You must run the following command to allow Calico traffic to flow between containers on different hosts, where the source-ranges parameter assumes you have created your project with the default GCE network parameters.

    gcloud compute firewall-rules create calico-ipip --allow 4 --network "default" --source-ranges "10.128.0.0/9"
   

Note:

Modify the address range if yours is different.

  • You must mark your worker nodes with labels recognized by Sisense, see Autoscaling and Linux
  • As Sisense version L2025.2 and newer use a new nfs-csi controller for new clusters, it is required to have a Resource Quota defined for the default namespace (or a different namespace if the utils_namespace parameter has been changed).

    The following is an example of such a ResourceQuota YAML:

    Copy
    apiVersion: v1
    kind: ResourceQuota
    metadata:
      name: gcp-critical-pods
      namespace: default
    spec:
      hard:
        pods: 100
      scopeSelector:
        matchExpressions:
        - operator: In
          scopeName: PriorityClass
          values:
          - system-node-critical
          - system-cluster-critical

Apply this as follows: kubectl apply -f <file>.yaml

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.

Deploying Sisense on Google GKE

  1. Create a GKE Cluster.
    8-6gkethumb0300.png
    GKE offers a number of cluster templates you can use. The default is Standard cluster. If you select Standard, you need to define the following fields:
    Name: A name for the cluster.
    Location type: You can deploy your cluster in a GCP zone or region. See Google's documentation for more information.
    (Optional) Node pool: Node pools are a subset of node instances within a cluster that all have the same configuration. You can change the number of nodes in the default pool or add a new node pool.
    There are other advanced networking and security settings you can configure but you can use the default settings for now.
  2. Click Create to deploy the cluster. After a minute or two, your Kubernetes cluster is deployed and available for use.
  3. To connect your cluster, you need to configure the kubectl command to communicate with the cluster.
  4. Download a Sisense version package. Contact your Sisense Customer Success Manager for a link to the latest version.
  5.     wget $sisense_url
  6. Extract the Sisense package.
  7.     tar zxf $package_name
  8. Navigate to the directory where you extracted the tar.gz file.
  9.     cd sisense-$sisense_version
  10. Access the cloud_config.yaml file.
  11.     vim cloud_config.yaml
  12. Edit the following values in the cloud_config.yaml file.
    ParametersValue
    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 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 Google GKE, the value must be the name of your zone.


    								kubernetes_cloud_provider: ""

    Enter gke.

    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 GKE, the installer does not install a cluster autoscaler; use the autoscaler built into GKE 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 GKE 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 GKE 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 nfs for Google GKE for using the Google Cloud Filestore storage service.

    You must also enter values for 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). MongoDB and ZooKeeper use the GKE StorageClass named standard.

    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.

    sisense_disk_size: 70

    Important! You must provide enough space to support your Sisense ElastiCube models, at least two times the amount of data in all ElastiCubes.

    Every namespace takes additional logical disk space from the physical disks, and the installation fails if you did not allocate enough space.To calculate the required space, you can use the following equation:sisense_disk_size = 70GB x 3 (for a three node deployment)If you allocate space for the application DB and configuration DB (the values of

    mongodb_disk_size
    and
    zookeeper_disk_size
    ) this should be considered as well. If you enter 210GB as the value, this allocates 70GB in a 3 node deployment minus 3 times (the values of mongodb_disk_size and zookeeper_disk_size).


    Sisense also recommends that you specify an additional 5GB free space for the value of sisense_disk_size.

    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 unique
      gateway_port
      value
    • Each deployment after the first, the value of the update should 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_port
    parameter.
    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.
  13. 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.
  14. 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. If you set application_dns_name, Sisense is available at that address. If you set cloud_load_balancer: true, you can display the external address of the load balancer with:

kubectl get svc api-gateway-external -n <namespace>

Otherwise, connect to Sisense in your browser with the relevant address:

  • For non-secure connections:
    http://{IP}:30845/
    where 30845 is the default gateway_port.
  • For secure connections:
    https://{IP}/

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

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.