Comparing Azure Kubernetes Networking Scenarios – Part 1 Intro

In Azure Kubernetes Service (AKS), I personally found the networking concepts much to understand and the configuration options are varied. After reading and experimenting with the configuration options, I hope to clear things up with 3 network oriented AKS configuration profiles I have come up with. Note that I won’t be covering App Gateway Ingress Controller as advanced option, but I plan to cover it in a different blog post series.

I will walk through and show its effects on some of the Azure resources such as the Load Balancer, Virtual Network and VM’s network interface card. I will give my own insight into the configuration profiles and draw up some conclusions and opinions at the end of this blog post series.

The following illustrates the model architecture that 3 configuration profiles are based out of.

Let’s look at the following AKS settings as they appear in the Azure Portal as you create the resource:

Network Model/Type: Basic (Kubenet) or Advanced (Azure CNI)

Choose between a basic network configuration using kubenet with a default VNet, or an advanced configuration using Azure CNI with the option to customize your VNet.

Kubenet is a very basic, simple network plugin, on Linux only. It does not, of itself, implement more advanced features like cross-node networking or network policy.

Azure Container Networking Interface (CNI) is where every pod gets an IP address from the subnet and can be accessed directly.

Enable or Disable Http application routing

The HTTP application routing solution makes it easy to access applications that are deployed to your cluster by creating publicly accessible DNS names for application endpoints. This will create a DNS zone in your subscription. HTTP application routing is designed for easily getting started with ingress controllers and as such is not recommended for production clusters.

Enable/Disable VM Scale Sets

Enabling VM scale sets will create a cluster that uses VM scale sets instead of individual virtual machines for the cluster nodes. VM scale sets are required for scenarios including autoscaling and multiple node pools.

The configuration profiles I have come up with:

Configuration Profile 1

Network Model/Type: Basic (Kubenet)
Http application routing: Disabled
VM Scale Sets: Disabled
1 Node/VM

Configuration Profile 2

Network Model/Type: Advanced (Azure CNI)
Http application routing: Disabled
Virtual Machine Scale Set: Enabled
2 VM instances in the scale set

Configuration Profile 3

Network Model/Type: Advanced (Azure CNI)
Http application routing: Enabled
Virtual Machine Scale Set: Disabled
Scale: 1 Node/VM

I will explore the effects of these settings on the Azure Load Balancer, Virtual Network, VM Network Interface(s) and the Kubernetes Dashboard Ingress resource. This will give an in depth understanding how these azure resources work together and support an AKS cluster and its applications.

The next blog posts, in this series, will walk through each configuration profile and the last blog post will conclude with my analysis, opinion and when to use what.