Audience: System Administrators
Content Summary: This page outlines instructions for troubleshooting specific issues with Helm.
Using a Kubernetes namespace
If deploying Immuta into a Kubernetes namespace other than the default, you must include the --namespace
option into the helm
and kubectl
commands provided throughout this section.
If you encounter Immuta Pods that have had the status Pending
or Init:0/1
for an extended period of time, then there may be an issue mounting volumes to the Pods. You may find error messages by describing one of the pods that had the Pending
or Init:0/1
status.
If an event with the message pod has unbound PersistentVolumeClaims
is seen on the frozen pod, then there is most likely an issue with the database backup storage Persistent Volume Claims. Typically this is caused by the database backup PVC not binding because there are no Kubernetes Storage Classes configured to provide the correct storage type.
Solution
Review your backup configuration and ensure that you either have the proper storageClassName
or claimName
set.
Once you have updated the immuta-values.yaml
to contain the proper PVC configuration, you will want to first delete the Immuta deployment, then run helm install
.
Occasionally Helm has bugs or loses track of Kubernetes resources that it has created. Immuta has created a Bash script that you may download and use to cleanup all resources that are tied to an Immuta deployment. This command should only be run after helm delete <YOUR RELEASE NAME>
.
Download cleanup-immuta-deployment.sh.
Run the script:
After a configuration change or cluster outage you may need to perform a rolling-restart to refresh the database pods without data loss. Use the command below to update a restart
annotation on the database pods to instruct the database StatefulSet to roll the pods.
After a configuration change or cluster outage you may need to perform a rolling-restart to refresh the web service pods. Use the command below to update a restart
annotation on the web pods to Deployment to roll the pods.
Solution
Should the need arise that you need to regenerate internal TLS certificates follow the instructions below.
Solution
Delete the internal TLS secret
Recreate the internal TLS secret by running Helm Upgrade.
Note
If you need to modify any postgres settings such as TLS certificate verification for the Query Engine. Be sure to modify values.yaml
file before running this command.
Helm 3: helm upgrade immuta/immuta --values
Helm 2: helm upgrade immuta/immuta --values --name
WAIT FOR PODS TO RESTART BEFORE CONTINUING
Restart Query Engine:
WAIT FOR PODS TO RESTART BEFORE CONTINUING
Restart Web Service:
Should you need to rotate external TLS certificates, follow the instructions below:
Solution
Create a new secret with the relevant TLS files.
Update your tls.externalSecretName
in immuta_values.yaml with the new external TLS secret.
Run Helm Upgrade to update the certificates for the deployment.
Delete the old secret.