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)