Question

Difficulty: HardConfigure Azure Kubernetes Service (AKS)

An administrator is designing a new Azure Kubernetes Service (AKS) cluster in a spoke virtual network (VNet) with the address space 10.80.0.0/2210.80.0.0/22. The cluster must scale up to 150150 nodes, with each node hosting up to 4040 pods simultaneously. The network security team mandates the use of Azure Network Policies for pod traffic enforcement. You need to select the network configurations that will support this scale and meet the security requirements while preventing IP address exhaustion in the VNet. Which two configurations should you implement? (Select two.)

  1. Configure the cluster network plugin to use Azure CNI Overlay.Answer
  2. Define a pod CIDR block, such as 192.168.0.0/16192.168.0.0/16, that does not overlap with the virtual network or any peered networks.Answer
  3. C
    Configure the cluster network plugin to use Kubenet and assign a custom Route Table to the node subnet.
  4. D
    Configure standard Azure CNI with dynamic IP allocation and delegate a dedicated pod subnet within the 10.80.0.0/2210.80.0.0/22 range.
  5. E
    Configure standard Azure CNI and set the maximum pods per node parameter (maxpods--max-pods) to 66.

Answer

Configure the cluster network plugin to use Azure CNI Overlay, and define a pod CIDR block, such as 192.168.0.0/16192.168.0.0/16, that does not overlap with the virtual network or any peered networks.
The correct configurations involve using the Azure CNI Overlay network plugin and defining a non-overlapping pod CIDR block. Azure CNI Overlay resolves VNet IP exhaustion by only assigning VNet IP addresses to the nodes, while pods are assigned IPs from a private overlay network. This allows a small virtual network range like 10.80.0.0/2210.80.0.0/22 to easily support 150150 nodes and their pods. Additionally, Azure CNI Overlay natively supports Azure Network Policies, satisfying the security mandate. A distinct, non-overlapping pod CIDR block (like 192.168.0.0/16192.168.0.0/16) must be defined to prevent routing conflicts between the overlay network and the underlying VNet.

Step-by-Step Solution

1
Analyze the IP addressing capacity requirements of the cluster.
The requirement is 150150 nodes hosting up to 4040 pods each, totaling up to 60006000 pods. The spoke virtual network is limited to a 10.80.0.0/2210.80.0.0/22 range, providing only 10241024 IP addresses.
Determining the total IP requirement shows that standard Azure CNI (which assigns VNet IPs to pods) will cause IP address exhaustion since 6150>10246150 > 1024.
2
Evaluate networking models that conserve VNet IP addresses.
Both Kubenet and Azure CNI Overlay conserve VNet IPs by using private internal pod ranges. However, Kubenet does not support Azure Network Policies, whereas Azure CNI Overlay supports them.
Selecting a model that supports Azure Network Policies is necessary to meet the security mandate while conserving VNet IPs.
3
Determine the necessary configuration parameters for Azure CNI Overlay.
Azure CNI Overlay requires enabling the overlay plugin and specifying a non-overlapping private pod CIDR (like 192.168.0.0/16192.168.0.0/16) for routing within the overlay network.
Specifying these configurations ensures correct cluster deployment and avoids IP conflicts with the underlying VNet or peered networks.

Key Concept

Azure CNI Overlay allows AKS pods to be deployed on a private CIDR range to conserve virtual network IP addresses, while still supporting Azure Network Policies and high-performance routing.
Rate this question