Azure Kubernetes Service (AKS) provides a hosted Kubernetes service where Azure handles critical tasks like health monitoring and maintenance for you. AKS reduces the complexity and operational overhead of managing Kubernetes by offloading much of that responsibility to Azure. When you create AKS, Azure provides the Kubernetes control plane. You need manage only the agent nodes within your clusters.
In this walkthrough, you will create an AKS cluster using an ARM template and then use Azure CLI to deploy a simple application to the cluster. You will review the design decisions made for the walkthrough, see how the template supports Kubenet for Kubernetes networking, role-based-access-control (RBAC) and how it supports managed identities to communicate with other Azure resources. Finally, you will use a Kubernetes manifest file to define the desired state of the cluster, and test the application.
An ARM template sets you up to being able to deploy AKS clusters and your applications into Pods in your Azure DevOps pipeline or using GitHub actions. You can set the parameters to define the characteristics of the cluster at deployment time.
To run this walkthrough, you will need:
- Azure Account.
- Have basic understanding of Azure resource groups and ARM templates
- Understand how to navigate the Azure portal.
- To have completed Quickstart: Deploy an Azure Kubernetes Service (AKS) cluster using an ARM template. The quickstart provides a quick introduction to the concepts in this article.
- To run locally, you will need:
- Azure CLI, version 2.8.0 or later.
- Bash. For Windows, Windows Services for Liniux (WSL) or GitBash.
- To run in Azure Portal, start Azure Cloud Shell and run in the CLI
- A high level understanding of Azure Role Based Access Control (RBAC), the concept of a built-in role, what an objectId is.
This walkthrough implements the following design considerations:
- Kubenet. In the example, use Kubenet networking where Azure manages the virtual network resources as the cluster is being deployed. The alternative is Azure Container Networking Interface (CNI) plugin. With CNI pods receive individual IP addresses that can route to other network services. For more information, see Choose the appropriate network model.
- Managed identities. AKS requires additional resources like load balancers and managed disks in Azure. To create these resources, Azure uses either a service principal or a managed identity. If you use managed identity, you do no need to manage a service principal. For more information, see Use managed identities in Azure Kubernetes Service.
- Kubernetes Role-based-access-control (RBAC). Kubernetes provides its own role-based-access control when enabled. It is the way you can dynamically configure policies that regulating access to computer or network resources based on the roles of individual users within your organization. For more information, see Using RBAC Authorization in the Kubernetes documentation.
- Linux nodes. You can run Windows nodes in your AKS cluster that uses CNI, but in this walkthrough we will use Linux.
- Virtual machine scale set. Because we are deploying a single node, you may need to adjust the number of nodes that run your workloads. The cluster autoscaler component can watch for Pods in your cluster that can’t be scheduled because of resource constraints. For more information, see Automatically scale a cluster to meet application demands on Azure Kubernetes Service (AKS).
In a future blog post, you will learn now to assign an admin group to manage Kubernetes using Azure Active Directory.
Let’s first look at the step in the walkthrough.
Steps in the walkthrough
You will take the following steps to deploy:
- Start your command prompt
- Set environment variables, log in to Azure, and create a resource group
- Review the ARM template
- Deploy the ARM template
- Review what was deployed
- Log in to the cluster
- Connect to the cluster
- Run an application
Start your command prompt
Let’s begin by creating an SSH key pair.
Set environment variables, log in, create resource group
Next, use the following code to log in, set environment variables, and create the resource group:
|SUBSCRIPTION_ID=<your subscription id>|
|LOCATION="east us 2"|
|az account set –subscription $SUBSCRIPTION_ID|
|az group create –name $RESOURCE_GROUP_NAME –location "$LOCATION"|
Review the ARM Template
Next copy the ARM template into your directory. In Cloud Shell, you can upload the file.
|"description": "The name of the Managed Cluster resource."|
|"description": "The location of AKS resource."|
|"description": "Optional DNS prefix to use with hosted Kubernetes API server FQDN."|
|"description": "Disk size (in GiB) to provision for each of the agent pool nodes. This value ranges from 0 to 1023. Specifying 0 will apply the default disk size for that agentVMSize."|
|"description": "The number of nodes for the cluster. 1 Node is enough for Dev/Test and minimum 3 nodes, is recommended for Production"|
|"description": "The size of the Virtual Machine."|
|"description": "The type of operating system."|
|"displayname": "AKS Cluster"|
|"value": "[reference(resourceId('Microsoft.ContainerService/managedClusters/', parameters('aksClusterName'))).fqdn]"|
Let’s review some key lines in the ARM template. You will need to pass in:
aksClusterName. The name of the managed cluster resource. The name is used to create the resource group containing the nodes.
dnsPrefix. DNS prefix specified when creating the managed cluster.
In the template itself, the following properties are set in the
identity. The identity is system assigned managed identity. Credential rotation for managed identity happens automatically every 46 days according to Azure Active Directory default. For more information how managed identities are used in AKS including the permissions granted to the managed identity, see Summary of managed identities for Kubernetes.
kubernetesVersion. The version number needs to include
[major].[minor].[patch]. To check for supported versions use
az aks get-versions --location $LOCATION --output table
enableRBACWhether to enable Kubernetes internal Role-Based Access Control to grant users, groups, and service accounts access to only the resources they need. Note that this parameter does not provide for Azure Active Directory RBAC.
agentPoolProfiles.type. This is set to virtual machine scale sets.
You can review the various properties available for the latest ARM Template reference.
Deploy the cluster
Run the following code to deploy the cluster.
|az deployment group create –name $DEPLOYMENT_NAME \|
|–resource-group $RESOURCE_GROUP_NAME –template-file "./azuredeploy.json" \|
|–parameters aksClusterName=$AKS_NAME dnsPrefix=aks-eus2-aksdays-demo-01 \|
The script show how to use
az deployment group create to deploy the ARM template and uses
--parameters to provide the deployment parameter values, such as
dnsPrefix, and a small
agentVMSize. Note: The The system node pool must use VM sku with more than 2 cores and 4GB memory.
The script then retrieves the output and displays the
Review what is deployed
The AKS template deploys the following resources:
- A resource group that contains:
- The nodes
- A load balancer
- Public IP
- Network Security Group (NSG)
- Managed identity
- Virtual network
- Route table
- A resource group that contains:
- The Kubernetes service
- The node pools
- Kubernet Networking
You can view the deployment in the portal. First, go to the resource group and view the resources deployed as shown in the following illustration.
Go to the resource group that was created for your cluster. It will have a name similar to
MC_aks-eus2-aksdays-demo-01_aks-eus2-aksdays-demo-01_eastus2. Here you will see the various resources deployed to support Kubernetes service.
In this example, Azure resources are created using managed identity, which allows Azure to create additional resources such as a load balancer and managed disks.
Let’s log into the cluster.
Connect to the cluster
Next, install the Kubernetes tools that you will need, and then use AKS to get your credentials
|az aks install-cli|
|az aks get-credentials –resource-group $RESOURCE_GROUP_NAME –name $AKS_NAME|
The code installs the tools you will need to interact with Kubernetes, including kubectl. And then it downloads credentials and configures the Kubernetes CLI to use them.
To verify the connection to your cluster, use the
kubectl get to return a list of the cluster nodes.
|kubectl get nodes|
Run an application
Next, let’s use a Kubernetes manifest file defines a desired state for the cluster. In this case, let’s use the example in the Azure quickstart documentation.
|– name: azure-vote-back|
|– name: ALLOW_EMPTY_PASSWORD|
|– containerPort: 6379|
|– port: 6379|
|– name: azure-vote-front|
|– containerPort: 80|
|– name: REDIS|
|– port: 80|
Save this file locally as
Let’s do a quick code review before you apply the manifest into Kubernetes. The manifest has four parts separated by
--. The manifest could have been deployed as four separate files. But for simplicity in the walkthrough it is a single file here. The file includes two deployments and two services.
- A deployment is a declarative way to update a Pod and ReplicaSet. The Pod has one or more containers. You describe a desired state in a Deployment, and the Kubernetes Deployment Controller changes the actual state to the desired state at a controlled rate.
- A service is an abstraction which defines a logical set of Pods and a policy by which to access them (sometimes this pattern is called a micro-service).
The deployment of
azure-vote-back has a single container that pulls the
mcr.microsoft.com/oss/bitnami/redis:6.0.8 image and sets its resource sizes. It also defines a label
The service of
azure-vote-back specification creates a new Service object named “azure-vote-back”, which targets TCP port 6379 on any Pod with the
The labels connect Services to Deployments. Deployments define the Pods.
Next, let’s apply the manifest using
kubectl apply as in the code sample:
|kubectl apply -f azure-vote.yaml|
The Pod does not come up right away. To monitor the progress, use:
|kubectl get service azure-vote-front –watch|
Kubernetes will report back the status of the service. Watch the EXTERNAL-IP column. Type
ctrl+c to exit watch.
When it changes to an public IP address, you can use the external IP address in your browser to go to the application.
In this walkthrough, you reviewed the design decisions and deployed a Kubernetes cluster. Then you used a manifest to deploy an image into Kubernetes.