Audience: System Administrators
Content Summary: This guide illustrates the deployment of an Immuta cluster on Microsoft Azure Kubernetes Service. Requirements may vary depending on the Azure Cloud environment and/or region. For comprehensive assistance, please contact an Immuta Support Professional.
This guide is intended to supplement the main Helm installation guide, which is referred to often throughout this page.
Prerequisites:
Node Size: Immuta's suggested minimum Azure VM size for Azure Kubernetes Service deployments is
Standard_D3_v2
(4 vCPU, 14GB RAM, 200 GB SSD) or equivalent. The Immuta helm installation requires a minimum of 3 nodes. Additional nodes can be added on demand.TLS Certificates: See the main helm installation guide for TLS certificate requirements.
To install Azure CLI 2.0, please visit Microsoft's documentation and follow the instructions for your chosen platform. You can also use the Azure Cloud Shell.
For more information on nodes, see the Azure VM sizing documentation.
Before installing Immuta, you will need to spin up your AKS cluster. If you would like to install Immuta on an existing AKS cluster, you can skip this step. If wish to deploy a dedicated cluster for Immuta, please visit Deploying Immuta Cluster Infrastructure on AKS.
Navigate to the installation method of your choice:
Please see the main helm installation guide for the full walkthrough of installing Immuta via our Helm Chart. This section will focus on the specific requirements for the helm installation on AKS.
Since you are deploying Immuta as an Azure cloud application in AKS, you can easily configure the Nginx Ingress Controller that is bundled with the Immuta Helm deployment as a load balancer using the generated hostname from Azure.
Confirm that you have the following configurations in your values.yaml
file before deploying:
If you are using the included ingress controller, it will create a Kubernetes LoadBalancer Service to expose Immuta outside of your cluster. The following options are available for configuring the LoadBalancer Service:
nginxIngress.controller.service.annotations
: Useful for setting options such as creating an internal load balancer or configuring TLS termination at the load balancer.
nginxIngress.controller.service.loadBalancerSourceRanges
: Used to limit which client IP addresses can access the load balancer.
nginxIngress.controller.service.externalTrafficPolicy
: Useful when working with Network Load Balancers on AWS. It can be set to “Local” to allow the client IP address to be propagated to the Pods.
Possible values for these various settings can be found in the Kubernetes Documentation.
After running helm install
, you can find the public IP address of the nginx controller by running
If the public IP address shows up as <pending>
, wait a few moments and check again. Once you have the IP address, run the following commands to configure the Immuta Azure Cloud Application to use your ingress controller:
Shortly after running these commands, you should be able to reach the Immuta console in your web browser at the configured externalHostName
.
Best Practice: Network Security Group
Immuta recommends that you set up the network security group for the Immuta cluster to be closed to public traffic outside of your organization. If your organization already has rules and guidelines for your Azure Cloud Application security groups, then you should adhere to those. Otherwise, we recommend visiting Microsoft's documentation page for configuring Network security groups to find a solution that fits your environment.
To configure backups with Azure, see the backup section in the Immuta Helm Chart.
If you've previously provisioned an AKS cluster (see Deploying Immuta Cluster Infrastructure on AKS) and have installed the Installation Prerequisites, you can run an automated script that will
Prepare the Helm values file,
Register the required secrets to pull Immuta's Docker images,
Run the Helm installation, and
Create the mapping between the external IP address Ingress Controller (the cluster's load balancer) and the cluster's public DNS name.
Please Note
Running the automated deployment script will make a series of decisions for you:
The TLS certificates will be generated on-the-fly and will be self-signed. You can easily change this later by following the instructions in the main Helm installation guide.
The number of replicas from each component will be automatically derived from your AKS cluster's node count. This can be easily modified by overriding the replicas parameter.
The installation will set up backup volumes by default. Set the BACKUPS
value to 0
to disable Immuta backups.
Download the script:
Make it executable by running:
Below is the list of the parameters that the script accepts. These parameters are environment variables that are prepended to the execution command.
To run the script and deploy, you can simply prepend the above-mentioned parameters to the execution command, with the action deploy
. For example,
You can use the same script to destroy a deployment you had previously run with this script, by running the following command:
The value of CLUSTER_NAME
should be identical to the name of the CLUSTER_NAME
value you've used to deploy Immuta.
Variable Name | Description | Required | Default |
---|---|---|---|
CLUSTER_NAME
The name of your AKS cluster
Required
-
SUBSCRIPTION_ID
The Azure Subscription ID
Required
-
CLUSTER_RESOURCE_GROUP
The resource group that contains the cluster
Required
-
DOCKER_USERNAME
Obtain from your Immuta support professional
Required
-
DOCKER_PASSWORD
Obtain from your Immuta support professional
Required
-
DB_PASSWORD
An arbitrary metadata database password
Required
-
DB_SUPERUSER_PASSWORD
An arbitrary metadata database super-user password
Required
-
DB_REPLICATION_PASSWORD
An arbitrary metadata database replication password
Required
-
DB_PATRONI_API_PASSWORD
An arbitrary metadata database Patroni API password
Required
-
QE_PASSWORD
An arbitrary Query Engine password
Required
-
QE_SUPERUSER_PASSWORD
An arbitrary Query Engine super-user password
Required
-
QE_REPLICATION_PASSWORD
An arbitrary Query Engine replication password
Required
-
QE_PATRONI_API_PASSWORD
An arbitrary Query Engine Patroni API password
Required
-
IMMUTA_VERSION
The version tag of the desired Immuta installation
Optional
<Current Immuta version>
IMMUTA_K8S_NAMESPACE
The Kubernetes namespace to create and deploy Immuta to
Optional
default
REPLICAS
The number of replicas of each main component in the cluster
Optional
1
BACKUPS
Whether or not backups should be enabled
Optional
1
SA_RESOURCE_GROUP
Backup Storage Account resource group
Optional
Same as CLUSTER_RESOURCE_GROUP
Audience: System Administrators
Content Summary: Before installing Immuta, you will need to spin up your AKS or ACS cluster. This page outlines how to deploy Immuta cluster infrastructure on AKS and ACS.
If you would like to install Immuta on an existing AKS or ACS cluster, you can skip this section. However, we recommend deploying a dedicated resource group and cluster for Immuta if possible.
Once you have deployed your cluster infrastructure, please visit Helm Installation on Microsoft Azure Kubernetes Service to finish installing Immuta.
Best Practice: Use AKS
Immuta highly recommends to use the improved version of Azure Kubernetes Service, AKS. Immuta on AKS will exhibit superior stability, performance, and scalability than a deployment on the deprecated version known as ACS.
You will need a resource group to deploy your AKS or ACS cluster in:
Note: There is no naming requirement for the Immuta resource group.
Now it is time to spin up your cluster resources in Azure. This step will be different depending on whether you are deploying an AKS or ACS cluster.
After running the command, you will have to wait a few moments as the cluster resources are starting up.
Create AKS Cluster (Recommended):
Create ACS Cluster (Deprecated):
You will need to configure the kubectl
command line utility to use the Immuta cluster.
If you do not have kubectl
installed, you can install it through the Azure CLI.
If you are using AKS, run
For ACS clusters, run
If you are using AKS, run
For ACS clusters, run