Using a Kubernetes namespace
If deploying Immuta into a Kubernetes namespace other than the default, you must include the --namespace option into all helm and kubectl commands provided throughout this section.
Immuta's Helm Chart requires Helm version 3+.
New installations of Immuta must use the latest version of Helm 3 and Immuta's latest Chart.
Run helm version to verify the version of Helm you are using:
In order to deploy Immuta to your Kubernetes cluster, you must be able to access the Immuta Helm Chart Repository and the Immuta Docker Registry. You can obtain credentials from your Immuta support professional.
Run helm repo list to ensure Immuta's Helm Chart repository has been successfully added:
Example Output
If you do not create a Kubernetes Image Pull Secret, installation will fail.
You must create a Kubernetes Image Pull Secret in the namespace that you are deploying Immuta in, or the installation will fail.
Run kubectl get secrets to confirm your Kubernetes image pull secret is in place:
Example Output
No Rollback
Immuta's migrations to your database are one way; this means that there is no way to revert back to an earlier version of the software. If you must rollback, you will need to backup and delete what you have and then proceed to restore from the backup to the appropriate version of the software.
No Modifying Persistence
Once persistence is set to either true or false for the database or query-engine, it cannot be changed for the deployment. Modifying persistence will require a fresh installation or a full backup and restore procedure as per Method B: Complete Backup and Restore Upgrade.
Run helm search repo immuta to check the version of your local copy of Immuta's Helm Chart:
Example Output
Update your local Chart by running helm repo update.
To perform an upgrade without upgrading to the latest version of the Chart, run helm list to determine the Chart version of the installed release, and then specify that version using the --version argument of helm repo update.
Run helm list to confirm Helm connectivity and verify the current Immuta installation:
Example Output
Make note of:
NAME - This is the '<YOUR RELEASE NAME>' that will be used in the remainder of these instructions.
CHART - This is the version of Immuta's Helm Chart that your instance was deployed under.
You will need the Helm values associated with your installation, which are typically stored in an immuta-values.yaml file. If you do not possess the original values file, these can be extracted from the existing installation using:
Select your method:
Method B - Backup and Restore: This method is intended primarily for recovery scenarios and is only to be used if you have been advised to by an Immuta representative. Reach out to your Immuta representative for instructions.
Rocky Linux 9
Review the potential impacts of Immuta's Rocky Linux 9 upgrade to your environment before proceeding:
ODBC Drivers
Your ODBC drivers should use a driver compatible with Enterprise Linux 9 or Red Hat Enterprise Linux 9.
Container Runtimes
You must run a supported version of Kubernetes.
Use at least Docker v20.10.10 if using Docker as the container runtime.
Use at least containerd 1.4.10 if using containerd as the container runtime.
OpenSSL 3.0
CentOS Stream 9 uses OpenSSL 3.0, which has deprecated support for older insecure hashes and TLS versions, such as TLS 1.0 and TLS 1.1. This shouldn't impact you unless you are using an old, insecure certificate. In that case, the certificate will no longer work. See the OpenSSL migration guide for more information.
FIPS Environments
If you run Immuta 2022.5.x containers in a FIPS-enabled environment, they will now fail. Helm Chart 4.11 contains a feature for you to override the openssl.cnf file, which can be used to allow Immuta to run in your environment, mimicking the CentOS 7 behavior.
After you make any desired changes in your immuta-values.yaml file, you can apply these changes by running helm upgrade:
Note: Errors in upgrades can result when upgrading Chart versions on the installation. These are typically easily resolved by making slight modifications of your values to accommodate the changes in the Chart. Downloading an updated copy of the immuta-values.yaml and comparing to your existing values is often a great way to debug such occurrences.
If you are on Kubernetes 1.22+, remove nginxIngress.controller.image.tag=v0.49.3 when upgrading; otherwise, your ingress service may not start after the upgrade.