In this video I want us to continue our conversation about the Azure Kubernetes service and specifically how it's going to integrate into your VNet. The best way to see that is to walk through the Creation wizard for an Azure Kubernetes cluster and see what their requirements are in that wizard for creating the cluster and putting it into an Azure virtual network. 

We are in the Azure portal and I have already kicked off the Azure Kubernetes cluster creation wizard and I've already filled in some of the fields that aren't really relevant to networking at all.

Things like specifying a resource group, giving the cluster a name, choosing a region, availability zones, version of Kubernetes, those kinds of things aren't necessarily specific to networking.

Once we start to Scroll down, we then can specify manual or auto-scaling for the method of scaling for your cluster. Not everybody needs scaling at all for their Kubernetes cluster. If they know their application, they know the user base for that particular application and they can set up a cluster that is going to just maintain that application, then auto-scaling may not be needed.

Hence using the manual scale method where you're actually going to specify a static value.

However, if you are going to provide scalability and elasticity for your application to allow for your user base to shrink and grow over time, you're going to want to specify a minimum and maximum node count range.

I'm bringing this up because although most people would not consider this a networking issue.

For the Azure CNI based networking model it is going to be important because you're going to need to allocate IP addresses for the nodes as well as the pods, so making sure to prepare and understand how many potential IP addresses you're going to need for your cluster is going to be extremely important.

The next tab we're going to take a look at is Node pools. This also ties back into the exact same discussion I was just mentioning, which is you start off with an agent pool which is primarily running the orchestration engine of Kubernetes and then maybe you want to separate out your workload or your application into a separate node pool.

You could absolutely do that, so if you'll remember, I said three to six for the minimum and maximum scaling. Maybe the first three are going to be your agent pool. The remaining three will be your application pool. Again, this ties back into the number of IP addresses that you're going to need in your virtual network if you are using Azure CNI.

You can also turn on Azure virtual nodes which connects your cluster to Azure container instances. That is a very advanced feature and is not specific to this discussion, but I just wanted to mention it.

Lastly on the tab, if you are in fact using scaling, you're going to automatically check the enable virtual machine scale sets so that you can specify how that scaling is going to be managed. Whether it be via processor percentage or queue length or any number of different health checks that can be performed against your cluster.

Next tab is on authentication. I'm just going to go ahead and skip past this, because this has no bearing on networking.

Now we have the networking tab, and this is where you're going to specify a number of different things. You're going to specify which network configuration you're going to choose, the Kubenet or Azure CNI. If you are going to choose Azure CNI then you have the ability to either select a new or existing virtual network.

Now, because of the particular region that I chose at the beginning in the Basics tab, I do not have any existing virtual networks in this region. However, if I had chosen a different region, say, and actually, let's go ahead and go back and do that. Let’s choose South Central and then go back to the networking tab. I should now have an available VNet that I can actually place the cluster into. 

The minute that I do that you'll notice I've got some error messages. They are letting me know that because of the fact that I'm using Azure CNI, that my subnet IP ranges are not large enough to support the node pools and then eventuality of the pods running in those node pools. You need to have a minimum of 555 addresses. Therefore, the /24 is not going to do it for me. I'm going to need something in the neighborhood of probably a /20. That's what happens when you choose Azure CNI.

If we specify Azure Kubenet, then the only thing we need to specify is a DNS name prefix. It's going to choose a load balancer. We're going to specify any HTTP application routing, whether or not this should be a private cluster, meaning that the load balancer would have a private IP address rather than a public one, and do we want to set authorized IP address ranges.

You'll notice there is no selection here for the choosing of an existing or new virtual network.

In this instance, it's going to automatically create a virtual network for you, and then you'll have access to modify it or configure it afterward, but the virtual network will get created for you by default. 

Lastly, do you want to specify any network policies? The default is none, but you can absolutely specify Calico. However, the Azure network policy is not compatible with Kubenet. If you chose Azure CNI, then the Azure network policy option would be available.

That is really all that there is with respect to VNet integrations.

Once you have your cluster up and running, you can absolutely set your default user-defined routes. You can create additional network security groups and have them all be applied inside of the virtual network, but this is going to be the minimum configuration that you're going to start with when you create your cluster. 

It's then going to be dependent on your specific application requirements as to what additional services and features you need to integrate into that environment.

In the next set of videos, we're going to take a look at App Services and, specifically application service environments and how they can be integrated to provide a private PaaS App Service instance inside of your virtual network.