Managed Azure Kubernetes Services (AKS) – Network Design with Azure CNI Plugin

Azure Kubernetes Service, AKS, Azure CNI Networking

Note: Special thanks to Navisite leaders  John Rudenauer , Balaji Sundara and Mike Gallo for their continued support on this blog series.

Managed Kubernetes, a part of Navisite’s Azure Cloud Management Services, simplifies deployment, management and operations of Kubernetes, and allows developers to take advantage of Kubernetes without worrying about the underlying plumbing to get it up running and freeing up developer time to focus on the applications. Different Cloud Providers are offering this service – for example Google Kubernetes Engine (GKE), Amazon has Elastic Container Service for Kubernetes (EKS), Microsoft has Azure Container Service (AKS) etc..

This is Part 2 of the AKS network design. In Part 1 we looked at the AKS cluster deployed with Kubenet networking.  Kubenet networking is the default configuration with AKS cluster. With Kubernet, nodes get IPs from the Azure Virtual Network while pods receive IPs from a different address space.  With Azure CNI, every pod gets an IP address in the Azure Virtual network subnet and can directly access nodes in the virtual network. This blog walks you through a step-by-step process to create a public facing “Load Balancer” service type in AKS using the Azure CNI plugin. Once the sample application is deployed we will do a deep dive into networking and traffic flow.

More upcoming blogs (#4 and #5) in this series so stay tuned…

  1. Azure Kubernetes Services (AKS) – Kubenet Network Design (Part 1)
  2. Azure Container Registry
  3. Managed Azure Kubernetes Services (AKS) – Advanced Network Design with CNI (Part 2)
  4. Custom Kubernetes Cluster on IaaS VMs in Azure using Flannel Overlay
  5. AKS with Persistent volumes using Azure Disks and Azure Files

Reference Architecture

Azure Documentation

Azure provides great documentation, so be sure to check out the detailed documentation on networking concepts here.

From Azure documentation:
Source – Azure Documentation

Create an AKS Cluster using Exisiting VNET

For details check out the Azure documentation here.

With Azure Container Networking Interface (CNI), every pod gets an IP address from the subnet and can be accessed directly. These IP addresses must be unique across your network space, and must be planned in advance. Each node has a configuration parameter for the maximum number of pods that it supports. The equivalent number of IP addresses per node are then reserved up front for that node. This approach requires more planning, and often leads to IP address exhaustion or the need to rebuild clusters in a larger subnet as your application demands grow.

Specify the --max-pods argument when you deploy a cluster with the az aks create command. The maximum value is 110.

Note: You can’t change the maximum number of pods per node when you deploy a cluster with the Azure portal. Azure CNI networking clusters are limited to 30 pods per node when you deploy using the Azure portal.

Run AKS Cluster Validations and Sample Application

Azure Side Screen Captures

Resource Groups

VNET and Subnets

Virtual Machines/Nodes

Node Interfaces

External Load Balancer


Finally, connect to the Azure load balancer front end IP.

Managed AKS – Easier container deployment and management

Managed AKS makes it easy to deploy and manage containerized applications without container orchestration expertise. However, making the right decision for the network design is critical because it affects the overall solution for remote access, internal and external load balancing.

Note: I’d like to thank my manager John Rudenauer and leaders from our Navisite Product Management – Balaji Sundara , my colleagues Umang Chhibber and Eric Corbett, Marketing team – Chris Pierdominici and Carole Bailey, and Professional Services team – Mike Gallo for their continued support and direction

Learn more about how Navisite’s Azure Cloud Management Services can help you more optimally deploy containers in AKS.  If your organization needs assistance in migrating to Azure, or managing an existing deployment, please contact us for additional information, or call us at (888) 298-8222 in the US, or 0800-6122933 in the UK.

Nehali Neogi

Nehali Neogi

Principal Cloud Architect at Navisite
Nehali Neogi is a Principal Cloud Architect at Navisite, leading many of their global initiatives on building the next generation of hybrid cloud services. She enjoys designing and architecting reliable and highly available solutions for Navisite’s clients. She is a Cisco, VMware NSX and Azure certified Cloud Architect leading Hybrid Cloud offerings. Her interests are cloud technologies, Software Defined Networking, full stack engineering, and realizing the transition to DevOps and system Automation.Nehali holds an Expert Level Certification in VMware NSX(VCIX-NV) and Microsoft Certified Azure Cloud Architect.She holds Masters in Computer Engineering from UMass, Lowell.
Nehali Neogi