Orchestrating Custom Analytics with Kubernetes and Helm charts

Contents[Hide]

1. Overview

This article describes how to run Custom Analytics on Kubernetes using Helm charts for automated scaling and management of Custom Analytics containers.

These containers run Custom Analytics Docker images, but you can use a Helm chart rather than managing and running Docker images directly, and it will handle many aspects of deployment and scaling for you automatically. You can deploy Custom Analytics this way on your choice of OS or cloud platform.

Note

There are certain known limitations when Custom Analytics runs on Linux, including these images when using Kubernetes.

2. Prerequisites

Deploying using Custom Analytics Helm charts requires the following:

A Kubernetes cluster
Helm 3 installed

For information about these, see Getting started in the Kubernetes documentation, and Quickstart Guide in the Helm documentation.

Tip

If you have Docker Desktop installed, its Enable Kubernetes option can be used to start a single-node test cluster.

3. Helm repository

Run the following command to add the Dundas repository, which is used to deploy Simba Custom Analytics:

helm repo add dundas https://helm-charts.dundas.com/repo/
helm repo update

4. Helm chart use & parameters

See the Dundas BI Helm readme on GitHub or using Helm for all other details on using this Helm chart to deploy Simba Custom Analytics and for all the parameters available.

If you are defining connection strings to Custom Analytics application and warehouse databases, details on their syntax and options can be found in Microsoft Docs for SQL Server and Npgsql for PostgreSQL.

Tip

In general, the Helm chart will configure many things for you automatically, such as the Internal Application URL configuration setting. The express option can deploy and configure a database server for Custom Analytics to use as storage automatically, although this is recommended only for evaluation purposes.

5. Other considerations

5.1. WSL2 notes

For Dundas BI versions 10 and below, due to WSL2 not supporting service sessionAffinity (https://github.com/microsoft/WSL/issues/7124), the defaults in the Dundas BI helm chart will cause the services to be unavailable. When using WSL2 for Kubernetes before version 11, set dundas.bi.website.service.sessionAffinity to None, and set dundas.bi.authbridge.service.sessionAffinity to None. In this scenario, do not use any website scaling or replicas.

5.2. OpenShift notes

When using Federated Authentication on Red Hat OpenShift, it is recommended to use the Dundas BI full image that contains both the scheduler and the authbridge website in the same image as the Dundas BI website. This can be done by setting dundas.bi.website.includeSchedulerAndAuthBridgeInWebsiteContainer to true, then setting dundas.bi.authbridge.enabled and dundas.bi.scheduler.enabled to false. Alternatively, you would need to use networking to ensure that the Dundas BI authbridge website is a subdirectory below the Dundas BI website. For more information, see the Reverse proxies article.

6. See also

Kubernetes: Getting started
Helm: Quickstart Guide
Kubernetes: Container Images
GitHub: Dundas BI Helm Readme
Using Custom Analytics Docker containers
Import and export a project

Custom Analytics Support

Documentation