Azure (AKS)

The Plixer ML Engine deployment utilizes a separate host VM to deploy, monitor, and control the deployment. All guide content and steps are managed from that host VM, which is distinct from the actual deployment nodes and resources. It is recommended to deploy the Plixer ML VM image as a deployment host because it installs all the required software prerequisites.

The following are the software prerequisites required:

Once all required software is installed, proceed with setting up the following:

Configuring Azure CLI

  1. Download and install the Azure CLI.

    Note

    Specific steps will depend on your OS. You may refer to the install guide here.

  2. Run az login to set up the client. This will prompt you to log in to your Azure account.

    Important

    The user account being used to deploy MUST be assigned to the “owner” role in Azure. This is because AKS needs to assign a role for the AKS cluster user, which only owners can perform.

  3. Make sure you have a .azure directory at your current user’s home directory.

Setting up Plixer Kubernetes in Azure

Run the following steps on a cloned VM template that will act as the deploy host to manage the rest of the infrastructure.

  1. Log in as the plixer user, and then accept the EULA and set up networking.

  2. Navigate to the /home/plixer/common/kubernetes directory.

  3. Modify azure.tfvars. You may refer to this table for the field values in azure.tfvars.

  4. Run 01_azure_infrastructure.sh.

  5. Run kubectl get nodes to make sure that the Kubernetes infrastructure has been deployed successfully.

Setting up the ML engine in Azure

After the Kubernetes infrastructure has been deployed and is now running successfully, you may proceed with deploying the ML engine in Azure.

  1. Run the following command: /home/plixer/ml/setup.sh

  2. If deploying to a VPC with internet access you will be asked for docker credentials.

  3. Enter the path to your Plixer Scrutinizer private SSH key or SSH password.

  4. Enter your Plixer Scrutinizer authentication token.

  5. Run kubectl get pods. The pods will have the Running status which means that it has been deployed successfully.

azure.tfvars field reference table

Field name

Description

cluster_name

REQUIRED: The name to associate with and identify this deployment.

vm_type

REQUIRED: This is the Azure VM instance type to create for AKS worker nodes.

location

REQUIRED: This is the location to create the AKS worker nodes in (e.g. East US 2).

resource_group_name

OPTIONAL: Name of existing resource group to use when deploying assets. If empty, a new resource group named ${var.cluster_name}-resource-group will be created. resource_group_name must also be in the specified location field.

vnet_name

OPTIONAL: Name of existing VNET to deploy AKS in.

vnet_subnet_name

OPTIONAL: Name of existing subnet within vnet_name to deploy AKS in. Each subnet can only contain one aks cluster.

vnet_addresses

OPTIONAL: If vnet_name is not specified, then use this address space when creating the new VNET to place AKS in. By default, value is set to 172.18.0.0/16.

new_subnet_cidr

OPTIONAL (required if vnet_subnet_name is not specified): If vnet_subnet_name is not specified, then use this address space when creating the new VNET subnet to place AKS in. Value must be within the address space of the specified VNET. Default value is set to 172.18.1.0/24.

public_node_ips

OPTIONAL: Whether or not to assign public IPs to AKS nodes. By default, value is set to FALSE.

service_cidr

OPTIONAL: Service CIDR space for internal k8s services. Must not conflict with the address space of the VNET being deployed to. By default, value is set to 172.19.1.0/24.

dns_service_ip

OPTIONAL: Service IP to assign to the k8s internal DNS service. Must be within the address space specified by service_cidr. By default, value is set to 172.19.1.5.