Helm Installation Prerequisites
Audience: System Administrators
Content Summary: This page outlines the prerequisites for installing Helm.
- Helm 3.2 or greater
- Kubernetes: See the Install Immuta page for a list of versions Immuta supports.
Helm and Immuta's Helm Chart
Immuta uses Helm to manage and orchestrate Kubernetes deployments. Check the Helm Release Notes to ensure you are using the correct Helm Chart with your version of Immuta.
Database backups for the metadata database and Query Engine may be stored in either cloud-based blob storage or a Persistent Volume in Kubernetes.
Cloud Storage (Recommended)
Backups may be stored using one of the following cloud-based blob storage services:
- AWS S3
- Supports authentication via AWS Access Key ID / Secret Key, IAM Roles via kube2iam or kiam, or IAM Roles in EKS.
- Azure Blob Storage
- Supports authentication via Azure Storage Key or Azure SAS Token.
- Google Cloud Storage
- Supports authentication via Google Service Account Key
When database persistence is enabled, Immuta requires access to
PersistentVolumes through the use of a persistent
volume claim template. These volumes should normally be provided by a block device, such as AWS EBS, Azure Disk, or
GCE Persistent Disk.
Additionally, when database persistence is enabled, Immuta requires the ability to run an
initContainer as root.
PodSecurityPolicies are in place, service accounts must be granted access to use a
PodSecurityPolicy with the ability to
Use Persistent Volumes
Backups may be stored in a Kubernetes Persistent Volume. The Persistent Volume must be backed by a storage technology that supports the "ReadWriteMany" access mode.
Best Practice: Persistent Volumes
Your company cluster should be able to provision persistent volumes for the best Immuta use.
The Immuta Helm Chart supports RBAC and will try to create all needed RBAC roles by default.
Immuta needs Ingress for two services:
- Immuta Web Service (HTTP)
- Immuta Query Engine (TCP)
The Immuta Helm Chart creates Ingress resources for HTTP services (the Immuta Web Service), but because of limitations with Kubernetes Ingress resources TCP ingress must be configured separately. The configuration for TCP ingress is dependent on the Ingress Controller that you are using in your cluster. Also, the configuration for TCP ingress is optional if you will only integrations, and it can be disabled.
Best Practice: Use Nginx Ingress Controller
Immuta recommends that you use the Nginx Ingress Controller because it supports both HTTP and TCP ingress.
To simplify the configuration for cluster Ingress, the Immuta Helm Chart contains an optional Nginx Ingress component that may be used to configure a Nginx Ingress Controller to be used specifically for Immuta. Contact your Immuta Support Professional for more information.
Worker Node Size
Immuta’s suggested minimum node size has 4 CPUs and 16GB RAM. The default Immuta Helm deployment requires at least 3 nodes. It is not recommended, but smaller deployments are possible by decreasing the replica count for each Immuta component.
All Immuta services use TLS certificates to enable communication over HTTPS. In order to support many configurations, the Immuta Helm chart has the ability to configure internal and external communication independently. If TLS is enabled, by default, a certificate authority will be generated then used to sign a certificate for both internal and external communications. See Enabling TLS for instructions to configuring TLS.
Internal HTTPS communication refers to all communication between Immuta services. External HTTPS communication refers to communication between clients and the Immuta Query Engine and Web Service, which is configured using a Kubernetes Ingress resource.