AKS networking (kubenet, Azure CNI) - Step-by-Step Execution

Process Flow - AKS networking (kubenet, Azure CNI)

Start AKS Cluster Setup

↓

Choose Network Plugin

↓

Kubenet

↓

Pod IPs from

↓

Node IP range

↓

Pods use NAT

↓

to access VNet

↓

Limited Pod

↓

IP scalability

↓

Cluster Ready with chosen networking

The flow shows choosing between Kubenet and Azure CNI networking for AKS, detailing how pod IPs are assigned and network behavior.

Execution Sample

Azure

az aks create --name myAKS --resource-group myRG --network-plugin kubenet
az aks create --name myAKS --resource-group myRG --network-plugin azure

Creates AKS clusters with either Kubenet or Azure CNI networking plugin.

Process Table

Step	Action	Network Plugin	Pod IP Assignment	Network Behavior	Result
1	Start cluster creation	N/A	N/A	N/A	Preparing resources
2	Select network plugin	kubenet	Pods get IPs from node subnet (private range)	Pods use NAT to access VNet	Pods share node IP range
3	Assign pod IPs	kubenet	Pod IPs assigned from node subnet	Pods cannot be reached directly from VNet	Limited IP scalability
4	Cluster ready	kubenet	Pods use node IP for outbound	Simpler setup, less IP usage	Cluster operational
5	Start cluster creation	N/A	N/A	N/A	Preparing resources
6	Select network plugin	azure	Pods get IPs directly from Azure VNet	Pods have unique IPs in VNet	Pods fully integrated in VNet
7	Assign pod IPs	azure	Pod IPs assigned from VNet subnet	Pods reachable directly, no NAT	Better network control
8	Cluster ready	azure	Pods have own IPs	Supports advanced networking	Cluster operational

💡 Cluster creation completes with chosen network plugin and pod IP assignment method.

Status Tracker

Variable	Start	After Kubenet Setup	After Azure CNI Setup	Final
Network Plugin	None	kubenet	azure	Set per cluster
Pod IP Source	None	Node subnet	Azure VNet subnet	Assigned per plugin
Pod IP Reachability	None	Via NAT through node IP	Direct VNet IP	Depends on plugin
IP Scalability	None	Limited by node subnet	High, uses VNet IPs	Depends on plugin

Key Moments - 3 Insights

Why do pods in Kubenet use NAT to access the VNet?

Because pods get IPs from a private range inside the node, they must use NAT through the node's IP to communicate outside. See execution_table rows 2 and 3.

How does Azure CNI allow pods to have their own IPs in the VNet?

Azure CNI assigns pod IPs directly from the Azure VNet subnet, making pods first-class network participants. See execution_table rows 6 and 7.

What limits the number of pods in Kubenet compared to Azure CNI?

Kubenet limits pods by the node subnet IP range, while Azure CNI uses VNet IPs allowing more pods. See variable_tracker row 'IP Scalability'.

Visual Quiz - 3 Questions

Look at the execution_table at step 3, where do pods get their IPs in Kubenet?

A From the node subnet (private range)

B From the Azure VNet subnet

C From a public IP pool

D From a separate Kubernetes subnet

💡 Hint

Check execution_table row 3 under 'Pod IP Assignment'

At which step does the cluster assign pods IPs directly from the Azure VNet?

A Step 2

B Step 4

C Step 7

D Step 3

💡 Hint

Look at execution_table row 7 under 'Pod IP Assignment'

If you want pods to be reachable directly in the VNet without NAT, which plugin should you choose?

A kubenet

B azure

C none

D both

💡 Hint

See execution_table rows 6 and 7 under 'Network Behavior'

Concept Snapshot

AKS networking uses two main plugins:
- Kubenet: Pods get IPs from node subnet, use NAT for VNet access, simpler but limited IPs.
- Azure CNI: Pods get IPs directly from Azure VNet, no NAT, better integration and scalability.
Choose based on IP needs and network complexity.
Use az aks create --network-plugin to specify.

Full Transcript

This visual execution shows how AKS networking works with Kubenet and Azure CNI plugins. The flow starts with cluster setup, choosing the network plugin, then assigning pod IPs. Kubenet assigns pod IPs from the node subnet and uses NAT for VNet access, limiting pod IP scalability. Azure CNI assigns pod IPs directly from the Azure VNet subnet, allowing pods to have unique IPs reachable directly in the VNet. The execution table traces each step of cluster creation and pod IP assignment for both plugins. Variable tracking shows how key variables like network plugin choice and pod IP source change. Key moments clarify why NAT is used in Kubenet and how Azure CNI improves network integration. The quiz tests understanding of pod IP assignment and network behavior. The snapshot summarizes the key differences and usage of Kubenet and Azure CNI in AKS networking.

Practice

1. What is the main difference between kubenet and Azure CNI networking in AKS?

easy

A. Both assign IPs from the Azure subnet but differ in routing protocols.

B. Kubenet uses NAT and assigns pod IPs from a private range, Azure CNI assigns IPs from the Azure subnet directly.

C. Kubenet assigns IPs from the Azure subnet, Azure CNI uses NAT for pod IPs.

D. Azure CNI uses NAT, while kubenet assigns IPs from the Azure subnet.

Solution

1. Step 1: Understand kubenet networking

   Kubenet assigns pod IPs from a private IP range and uses NAT to allow pods to communicate outside the cluster.

2. Step 2: Understand Azure CNI networking

   Azure CNI assigns pod IPs directly from the Azure virtual network subnet, allowing pods to have direct IP addresses visible in the Azure network.

3. Final Answer:

   Kubenet uses NAT and assigns pod IPs from a private range, Azure CNI assigns IPs from the Azure subnet directly. -> Option B

4. Quick Check:

   Kubenet = NAT, Azure CNI = Azure subnet IPs [OK]

Hint: Kubenet uses NAT; Azure CNI uses Azure subnet IPs [OK]

Common Mistakes:

• Confusing which method uses NAT
• Thinking both assign IPs from Azure subnet
• Assuming Azure CNI uses private IP range

2. Which of the following is the correct way to specify Azure CNI networking when creating an AKS cluster using Azure CLI?

easy

A. az aks create --name myAKS --resource-group myRG --network-plugin azure

B. az aks create --name myAKS --resource-group myRG --network-plugin kubenet

C. az aks create --name myAKS --resource-group myRG --network-plugin azure-cni

D. az aks create --name myAKS --resource-group myRG --network-plugin azurecni

Solution

1. Step 1: Identify the correct network plugin name for Azure CNI

   The Azure CLI uses the exact string azure to specify Azure CNI networking.

2. Step 2: Check the command syntax

   The command must include --network-plugin azure to enable Azure CNI networking.

3. Final Answer:

   az aks create --name myAKS --resource-group myRG --network-plugin azure -> Option A

4. Quick Check:

   Azure CNI plugin = azure [OK]

Hint: Azure CNI plugin is exactly 'azure' in CLI [OK]

Common Mistakes:

• Using 'azure-cni' instead of 'azure'
• Confusing kubenet with Azure CNI plugin name
• Typos in the network plugin parameter

3. Given an AKS cluster configured with kubenet, what will happen if a pod tries to communicate with another pod in a different node?

medium

A. Pods communicate directly using their Azure subnet IPs without NAT.

B. Pod traffic is blocked by default between nodes.

C. Pods cannot communicate across nodes in kubenet mode.

D. The pod-to-pod traffic will be routed through the node's NAT IP and may require additional routing setup.

Solution

1. Step 1: Understand pod communication in kubenet mode

   In kubenet, pods get private IPs and use NAT on the node to communicate outside their node.

2. Step 2: Analyze cross-node pod communication

   Traffic between pods on different nodes goes through the node's NAT IP, requiring routing rules to allow this traffic.

3. Final Answer:

   The pod-to-pod traffic will be routed through the node's NAT IP and may require additional routing setup. -> Option D

4. Quick Check:

   Kubenet cross-node uses NAT routing [OK]

Hint: Kubenet pods use NAT IPs for cross-node traffic [OK]

Common Mistakes:

• Assuming direct pod IP communication in kubenet
• Thinking pods cannot communicate across nodes
• Believing pod traffic is blocked by default

4. You deployed an AKS cluster with Azure CNI but pods are not getting IP addresses from the Azure subnet. What is the likely cause?

medium

A. The Azure subnet does not have enough free IP addresses for pods.

B. The cluster was created with kubenet instead of Azure CNI.

C. The pods are configured to use host networking.

D. The Azure CNI plugin is not installed on the nodes.

Solution

1. Step 1: Check IP availability in Azure subnet

   Azure CNI assigns pod IPs from the Azure subnet. If the subnet IP pool is exhausted, pods cannot get IPs.

2. Step 2: Verify cluster network plugin and configuration

   Since the cluster is deployed with Azure CNI, the plugin is installed. Host networking would not prevent IP assignment.

3. Final Answer:

   The Azure subnet does not have enough free IP addresses for pods. -> Option A

4. Quick Check:

   Subnet IP exhaustion blocks pod IP assignment [OK]

Hint: Check subnet IP availability first for Azure CNI issues [OK]

Common Mistakes:

• Assuming plugin is missing when cluster uses Azure CNI
• Ignoring subnet IP exhaustion
• Confusing host networking with IP assignment

5. You want to deploy an AKS cluster that allows pods to communicate directly with other Azure resources in the same virtual network using their pod IPs. Which networking option should you choose and why?

hard

A. Use kubenet with additional routing rules to enable pod IP visibility.

B. Use kubenet because it saves IP addresses and allows direct pod IP communication.

C. Use Azure CNI because it assigns pod IPs from the Azure subnet enabling direct communication with Azure resources.

D. Use Azure CNI but disable IP assignment to pods for better security.

Solution

1. Step 1: Identify networking needs for direct pod-to-Azure resource communication

   Direct communication requires pods to have IPs visible in the Azure virtual network.

2. Step 2: Compare kubenet and Azure CNI capabilities

   Kubenet uses NAT and private IPs, so pods are not directly reachable. Azure CNI assigns pod IPs from the Azure subnet, enabling direct communication.

3. Final Answer:

   Use Azure CNI because it assigns pod IPs from the Azure subnet enabling direct communication with Azure resources. -> Option C

4. Quick Check:

   Azure CNI = direct pod IPs in Azure subnet [OK]

Hint: Azure CNI enables direct pod IP communication with Azure resources [OK]

Common Mistakes:

• Choosing kubenet for direct pod IP communication
• Thinking kubenet allows direct pod IP visibility
• Disabling IP assignment in Azure CNI disables communication