Skip to main content
In this tutorial, you’ll learn how to scale an Azure Kubernetes Service (AKS) deployment and understand the per-node pod limit enforced by Azure CNI. We’ll cover:
  1. Inspecting your current Deployment and Service
  2. Scaling the Deployment to 5 replicas
  3. Hitting the 30-pod per-node limit
  4. Examining Namespaces and system pods

1. Inspect the current Deployment and Service

Before scaling, verify your application’s replica count and external endpoint.

2. Scale to 5 replicas

Increase your Deployment to five pods:

Validate load balancing

Open three incognito browser windows and navigate to your Service’s public IP. You should see traffic routed to different pods:
The image shows three browser windows displaying the "KodeKloudApp" homepage with a welcome message, system name, and IP address highlighted in yellow. Each window has a different system name and IP address.

3. Scale to the pod limit (30 replicas)

When you created the AKS cluster, you configured Azure CNI with a maximum of 30 pods per node. Let’s push the Deployment to that limit:
Only 16 pods are running; the rest remain Pending:

Filter non-running pods

List pods that aren’t in the Running phase:

Inspect pod scheduling events

Describe one pending pod to see why it isn’t scheduled:
In the Events section you’ll find:

4. Namespaces and system pods

AKS uses several namespaces to isolate workloads. System pods in kube-system count toward your per-node limit.

Namespace overview

Azure CNI assigns IPs from your VNet based on the --max-pods setting at cluster creation. You cannot change this limit post-creation.

Next steps

To work around the per-node pod limit, consider:
  • Deploying multiple node pools with different --max-pods settings
  • Switching to Kubenet or Azure CNI Overlay networks
  • Splitting workloads across separate namespaces and node pools

Watch Video