In this final blog post of the following series

• Comparing Azure Kubernetes Networking Scenarios – Part 1 Intro
• Comparing Azure Kubernetes Networking Scenarios – Part 2 Kubenet
• Comparing Azure Kubernetes Networking Scenarios – Part 3 Azure CNI
• Comparing Azure Kubernetes Networking Scenarios – Part 4 Http App Routing

Let’s recap the AKS network related configuration settings I explored:

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.

My comparison and commentary:

	Network Model/Type	Http Application Routing	VM Scale Sets
Configuration Profile 1	Kubenet	Disabled	Disabled
My Commentary	Kubenet DIY ingress controller
Configuration Profile 2	Azure CNI	Disabled	Enabled
My Commentary	Every pod gets an IP address and direct network connectivity. DIY ingress controller
Configuration Profile 3	Azure CNI	Enabled	Disabled
My Commentary	Every pod gets an IP address and direct network connectivity. OOTB ingress controller, but not recommended for production. Every pod gets an IP address and direct network connectivity.

From Microsoft Documentation AKS Best Practices I like to note the following:

AKS Network Concepts – Compare Network Models

• kubenet
  • Conserves IP address space.
  • Uses Kubernetes internal or external load balancer to reach pods from outside of the cluster.
  • You must manually manage and maintain user-defined routes (UDRs).
  • Maximum of 400 nodes per cluster.
• Azure CNI
  • Pods get full virtual network connectivity and can be directly reached via their private IP address from connected networks.
  • Requires more IP address space.

Operator Best Practices – Choose Network Model

For most production deployments, you should use Azure CNI networking. This network model allows for separation of control and management of resources. From a security perspective, you often want different teams to manage and secure those resources. Azure CNI networking lets you connect to existing Azure resources, on-premises resources, or other services directly via IP addresses assigned to each pod.

Ingress Controllers

In AKS, you can create an Ingress resource using something like NGINX, or use the AKS HTTP application routing feature.

My Recommendations

If you are a developer, beginner in AKS and Kubernetes and you have a containerized application ready to deploy, then go with Kubenet model with HTTP Application Routing enabled. This is the least path of resistance to show a working application. From there, explore more advanced settings and deploy your own Ingress Controller.

If you are more of an operator/systems admin, beginner in AKS and Kubernetes, you may care more about control and manageability of the networking. Therefore, explore either Kubenet or Azure CNI network model and deploy your own Ingress Controller with HTTP Application Routing disabled. And work up the learning curve with Azure CNI for more extensibility with networking.

If are already experienced with Kubernetes and working towards an production grade implementation, I would suggest Azure CNI network model and deploy your own Ingress Controller without HTTP Application Routing enabled.