Comparing Azure Kubernetes Networking Scenarios

To recap the AKS configuration settings we 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 analysis and comparison

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

https://docs.microsoft.com/en-us/azure/aks/concepts-network#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.

https://docs.microsoft.com/en-us/azure/aks/operator-best-practices-network#choose-the-appropriate-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.

https://docs.microsoft.com/en-us/azure/aks/concepts-network#ingress-controllers

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s