Networking basics in the Azure Kubernetes Service

The Azure Kubernetes Services provides two Network Plugin options. Kubenet, which was the first available option, and the Azure CNI (Advanced Networking).
The Azure CNI is the only networking option that supports provides support for capabilities like Vnet peering and network policies – basically most enterprise scenarios will require using the Azure CNI.

There’s a really comprehensive guide to the Azure CNI here : https://docs.microsoft.com/en-us/azure/aks/configure-azure-cnihttps://docs.microsoft.com/en-us/azure/aks/configure-azure-cni
This post is intended to serves as an example, and to emphasize several of the points in the official documentation.

Using an existing virtual network


I have a /23 vnet that offers 445 addresses. As each pod on each node will take an ip address from the virtual network, it’s pretty important to realise the limitations of using a small virtual network for your clusters. Where the virtual network is peered with other networks, including your on-prem network this can often mean you’ll end up needing a larger network address range than you first thought.
From the Azure CNI documentation, there’s a pretty handy formula you can plug into Excel to start seeing how many nodes/pods your address space will support.
=(A2+1) + ((A2+1) * B2)

Nodes Pods Addresses
50 30 1581
10 100 1111
6 62 441
So you can see that in my /23 vnet, a suitable combination is 6 nodes with a maximum pod capacity of 62.

Once you’ve done this, you can create your cluster. The important piece to note at this point is;
The service address range is a set of virtual IPs (VIPs) that Kubernetes assigns to internal services in your cluster.
Therefore when you select the Service address range, you need to ensure it won’t overlap with any other IP ranges you may use… EG.

After the cluster has been created, and you’ve provisioned some pods/services you’ll see the IP addresses used as per the following;

Using the edge Azure CLI in a Centos VM

If you’re wanting to use the Edge (developer, nightly build) of the Azure CLI tools I can definitely recommend using an Azure VM.
Firstly, the advantages are

  • Using a developer AZ CLI build in isolation from your main work machine
  • VM’s in Azure can using Managed Service Identity to easily authenticate with the control plane
  • You can run it on a really cheap B series VM ($9/$18 a month!)

See here for the GitHub repo: https://github.com/Azure/azure-cli#edge-builds

VM Spec

I’m running a CentOS Standard_B1ms VM which gives me 1 core 2GB RAM, 800 IOPS with a 32GB standard managed disk which offers a capped IOPS of 500. This costs approx. $18/month for 24×7 compute and approximately $2/month for my disk.

NSG

I have two IP’s opened up on port 22 so I can SSH on. Everything else is locked down.

VM Updates

The VM is enrolled for update management, as I’ve gone for the B-series the VM will be kept up 24×7 so I don’t need to worry about turning it on to get patched.

Managed Identity

The VM has a system managed identity in Azure Active Directory and I have given it limited Contributor access to one resource group and reader access to a few other resource groups.

Setup script

On a fresh CentOS VM here’s what I run to install the CLI and login to Azure.

1
2
3
4
5
6
7
sudo yum update
sudo yum install epel-release
sudo yum -y install python-pip
sudo pip install --upgrade pip
sudo pip install venv
pip install --upgrade --pre azure-cli --extra-index-url https://azurecliprod.blob.core.windows.net/edge --no-cache-dir --user
az login --identity