Orchestrating Dundas BI with Kubernetes and Helm charts
This article describes how to run Dundas BI on Kubernetes using Helm charts for automated scaling and management of Dundas BI containers.
These containers run Dundas BI 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 Dundas BI this way on your choice of OS or cloud platform.
Deploying using Dundas BI Helm charts requires the following:
- A Kubernetes cluster
- Helm 3 to be installed
3. Helm repository
To add the Dundas repository, run the following command:
helm repo add dundas https://helm-charts.dundas.com/repo/ helm repo update
4. Helm chart use & parameters
For all details on installing & uninstalling the Helm chart and the parameters available, see the Helm chart readme on GitHub.
5. Other considerations
5.1. WSL2 notes
- 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. This will be worked around in version 11. Until then when using WSL2 for Kubernetes 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 Dundas BI and reverse proxies article.