Now, let’s create and configure a cluster using the Azure Kubernetes Service. The easiest way to get to the AKS section of the portal is to use the search bar. If you type “aks”, it will come back with “Kubernetes service”.

Then click Add and select “Add Kubernetes cluster”. Let’s create a new resource group to put it in. I’ll call it “aks1”. And I’ll call the cluster “cluster1”.

You’ll notice that the availability zones field is greyed out. That’s because this region doesn’t support availability zones. So if we create the cluster in this region, then it won’t be a highly available cluster since the nodes will all be in the same zone. If that zone were to go down, then the whole cluster would go down. If we change it to a region that supports availability zones, such as “Central US”, then we can put a node in each zone and make it highly available. By default, it selects all three zones.

You can select a specific Kubernetes version if you want, but we’ll leave that with the default.

Now we specify what kind of nodes we want. If you’ll recall, the nodes are virtual machines, so we need to give the specifications for those VMs. The default is a good choice, but you can change it if you want. You might be tempted to choose the smallest (and cheapest) one to save money, but this one is actually too underpowered for a Kubernetes cluster, so you’ll eventually get an error if you select this one. Let’s leave it with the default.

Now we need to tell it how many nodes to provision. If we only needed this cluster for testing or development purposes, then we could get away with only having one node, but if we needed it for production, then we’d want to have at least three nodes. If you’re following along on your own Azure account, then you can change this to one to save money if you want.

All three nodes will be the same type of VM. But suppose you needed a more powerful VM for one of your applications. You wouldn’t want to use that more expensive type of VM for all of your nodes just to accommodate that one application. Instead, you could create a separate node pool with bigger nodes. We don’t need to do that for this example, so we’ll stick with one node pool.

Now we’ll configure authentication. First, the cluster itself needs to be able to access other Azure resources, such as disks, so it needs to have an identity that can be trusted by the other Azure resources. There are two options for doing this, a service principal or a system-assigned managed identity. The easiest option is the managed identity, which actually uses a service principal under the hood, but it takes care of all of the details of managing it for you. So we’ll use that one.

The other authentication and authorization that’s required is for users who need to access the cluster, such as developers and system administrators. Authentication means verifying a user’s identity. The standard way to do authentication in Azure is to use Azure Active Directory. This option lets you give administrative access to the cluster to a particular group in Azure Active Directory. That would require some extra steps, so I’m going to leave this disabled. Don’t worry, though. Even without this option enabled, it’ll still restrict who can access the cluster.

Authorization means giving permissions to a user to perform specific tasks. The standard way to do authorization is called role-based access control, so we should leave this option enabled.

The next page is for network configuration. You can leave it with the defaults unless you need something specific, such as restricting cluster management access to a particular range of IP addresses.

The Integrations page is where you can integrate your cluster with other services like Azure Container Registry and Azure Monitor. Azure Container Registry is a centralized place where you can keep all of your container images, so if you integrate it with your cluster, then it will be easier to deploy your containers to the cluster.

Azure Monitor is enabled by default because it is the standard way to monitor the health and performance of your cluster.

Azure Policy is a service that lets you set governance policies, such as only allowing specific container images to run on your cluster.

Finally, the Tags page lets you create tags to categorize your cluster. Tags are often used for billing purposes in large organizations.

Okay, now we can go to the “Review + create” page. It does a quick validation check to make sure our configuration will work, and then we can click the Create button.

In the next demo, I’ll show you what we can do with the cluster.