The controller needs to be configured with credentials in order to programmatically create and configure required AKS infrastructure on Azure in your account. These credentials securely managed as part of a cloud credential in the Controller.
The creation of a cloud credential is a "One Time" task. It can then be used to create clusters in the future when required. Please review Microsoft AKS Credentials for additional instructions on how to configure this.
To guarantee complete isolation across Projects (e.g. BUs, teams, environments etc.,), cloud credentials are associated with a specific project. These can be shared with other projects if necessary.
Self Service Wizard¶
This approach is ideal for users that need to quickly provision and manage AKS clusters without having to become experts in Microsoft AKS tooling, best practices and writing bespoke Infrastructure as Code (IaC).
The wizard prompts the user to provide critical cluster configuration details organized into logical sections:
- General (mandatory)
- Cluster Settings
- Node Pool Settings
Only the General section is mandatory. Out of box details are provided for the remaining sections.
- Click Clusters on the left panel and the Clusters page appears
- Click New Cluster
- Select Create a New Cluster and click Continue
- Select the Environment Public Cloud
- Select the Cloud Provider Azure
- Select the Kubernetes Distribution Azure AKS
- Provide a cluster name and click Continue
General section is mandatory to create a cluster
- Enter the Resource Group for the AKS cluster
- Select the Cloud Credential from the drop-down created with Azure credentials
- Select a region and version
- Select a Blueprint and version. The default and minimal are the two blueprints available by default for the roles Org Admin, Infra Admin and Cluster Admin. Customized blueprint can also be selected from the drop-down if required
Note: The default and minimal are the system defined blueprints, hence versions cannot be selected.
- Click SAVE & CUSTOMIZE to customize the cluster configuration or SAVE CHANGES to proceed with the cluster provisioning
Cluster Settings (Optional)¶
Cluster Settings allows to customize the network settings. Click Edit next to Cluster Settings section
Network Configuration By default, Network Congifuration is set to Kubenet. Selecting Kubenet network automatically creates Virtual Network (VNet) for the clusters with default values.
Users who do not require a new network and make use of the existing network can select Azure CNI. Selecting Azure CNI allows to enter the existing Virtual Network Name, Cluster subnet Name, IP address range, Vnet Resource Group Name, etc.
Cluster Endpoint Access
Below are the different cluster endpoints:
Private cluster uses an internal IP address to ensure that network traffic between the API server and node pools remains on a private network only
Public cluster endpoints is accessible from external network (public network). Selecting Public enables the Authorized IP Ranges field providing cluster access to a specific IP address. Multiple IP ranges are allowed
Network Policies allows to define rules for ingress and egress traffic between pods in a cluster, improving you cluster security by restricting access to certain pods. Choose one of the three options, None, Calico and Azure for the cluster. Network policies are applicable only to Linux node pools
ACR Settings Provide ACR Resource Name allows to provide the ACR Resource Group name and ACR Name. This helps the controller to interact with the Azure Container Registry to pull in the stored container images available in the existing Azure Container Registry Service
Node Pools Settings (Optional)¶
A primary node pool is created by default when creating a cluster. It is mandatory to have one primary node pool for a cluster. To perform any changes to the existing node, click Edit. Primary node should always have the System Mode and Linux OS Type.
Secondary Node Pool
Click Add Node Pool to add secondary node and provide the required details.
If Kubenet is selected as the Network Configuration under Cluster Settings, Azure do not support Windows OS Type for the secondary node pool. If Azure CNI is selected as the Network Configuration under Cluster Settings, Azure allows both Linux and Windows OS type for the User Mode.
Spot Price Enable Spot Price allows the user to set a price for the require instances. Based on the availability of the instances for the provided bid price, users can make use of the instances for the clusters at a significant cost savings. This check-box is enabled only for the combination of User Mode and Linux OS Type.
Once all the required config details are provided, perform the below steps
- Click Save Changes and proceed to cluster provisioning
- The cluster is ready for provision. Click Provision
Click SAVE & CUSTOMIZE to customize the cluster. Users can also use the self service wizard to create a "baseline cluster configuration", view the YAML based specification, update/save, and use the updated configuration to provision an AKS cluster. This can be very useful for advanced cluster customization or for advanced features that are only supported via the "cluster configuration file"
Click SAVE & CUSTOMIZE
This will present the user with the baseline cluster configuration in a YAML viewer. The user has two options for customizing the cluster configuration before provisioning using the self service wizard.
(a) Copy the configuration, make changes offline and paste the updated configuration and Save (OR) (b) Make the required changes inline in the YAML viewer and Save
Once all the steps are complete, the cluster is successfully provisioned as per the specified configuration. Users can now view and manage the Azure AKS Cluster in the specified Project in the Controller. On successfully provisioning, the user can view the dashboards
Cluster provisioning can fail if the user had misconfigured the cluster configuration (e.g. wrong cloud credentials) or encountered soft limits in their Azure account for resources. When this occurs, the user is presented with an intuitive error message. Users are allowed to edit the configuration and retry provisioning
Automated Cluster Creation¶
Users can also automate the cluster creation process without any form of inbound access to their VNet and these can be created via config file.