Wilson Darko

Azure Kubernetes Service (AKS) Node Auto-Provisioning (NAP) keeps your clusters efficient: it provisions nodes for pending pods, and it continuously removes nodes when it's safe to do so, for example, when nodes are empty or underutilized. That node-removal disruption is where many production surprises happen.

When you manage Kubernetes, a few disruption questions come up fast:

• How do I control when scale down happens, or when it should not happen?
• How do I make workload disruption predictable?
• Why won’t NAP scale down my nodes, even with lots of underused capacity?
• Why do upgrades get stuck on certain nodes?

This post focuses on NAP disruption best practices, not workload scheduling tools such as topology spread constraints, node affinity, and taints. For scheduling best practices, see the NAP scheduling fundamentals blog post.

If you’re new to these features, start here. If you already use NAP disruption settings, use this post as a checklist for the behaviors AKS users most commonly ask about.

With Kubernetes, you control what your workloads (or pods) need with resource requests. But how do you control where they land? On AKS, three scheduling levers work with Node Auto-Provisioning (NAP) to give you predictable placement: taints, affinity, and topology spread constraints.

When Growth Meets a Wall​

Imagine this: your application is thriving, traffic spikes, and Kubernetes promises elasticity. You hit “scale,” expecting seamless provisioning - only to be greeted by errors like:

• SkuNotAvailable: The VM size (also referred to as VM SKU) you requested is not available.
• AllocationFailed: Azure can’t allocate the specific VM size with the constraints you requested in a particular region.
• Quota exceeded: Your subscription has hit its compute limits for a particular location or VM size.
• ZonalAllocationFailed: Azure can’t allocate the VM size with the constraints you requested in a particular zone.
• OverconstrainedAllocationRequest: Azure can’t allocate the specific VM size with the constraints you requested in a particular region.
• OverconstrainedZonalAllocationRequest: Azure can’t allocate the VM size with the constraints you requested in a particular zone.

For customers, these aren’t just error messages - they’re roadblocks. Pods remain pending, deployments stall, and SLAs tremble. Scaling isn’t just about adding nodes; it’s about finding capacity in a dynamic, multi-tenant cloud where demand often outpaces supply. In the case of quota gaps, usually users can increase their quotas in a particular location - but what about when a specific virtual machine size (also known as a "VM SKU") is simply unavailable? This can cause many challenges for users.