I'm running a basic Azure Kubernetes Service setup for development, using the free tier and B-series VM sizes for the node pools. There's no unusual networking configuration, IPv6, or intentionally selected availability zone. However, scaling a node pool—or creating a new cluster or pool—often fails with OverconstrainedZonalAllocationRequest.
The error says Azure cannot allocate the VMSS because the request is constrained by availability zone, networking requirements, and VM size. It suggests trying another size or zone. This happens repeatedly during autoscaling, not just during a one-time deployment. Quota checks look fine, and I'm deploying in Germany West Central. Is this likely a regional capacity issue, and what are the practical workarounds?
2 Answers
This usually means Azure temporarily doesn’t have enough capacity for that VM size and its required constraints in the selected region or zone. B-series machines can be especially difficult to allocate because they’re popular and availability varies. Quota being available doesn’t guarantee that physical capacity is available.
Try a different compatible VM SKU, preferably one listed in the error, or use another availability zone or nearby region. Also check that the node pool isn’t configured with a zone restriction or another networking requirement that narrows the allocation options.
The recurring autoscaling failures point more toward capacity or SKU availability than a configuration mistake. AKS may still end up with zonal constraints through the VMSS or cluster configuration, even when you didn’t explicitly choose one. Review the node pool’s zones, networking features, and VM size, then loosen whichever constraints are optional.
For a reliable workaround, use a different supported SKU as a fallback, recreate the pool without unnecessary zone restrictions, or deploy in another region. Azure capacity can change over time, so a retry may work temporarily, but switching sizes is usually more dependable.
The main issue is that cluster autoscaling fails whenever it needs to add nodes, so simply retrying isn’t a practical long-term solution. I’ll investigate the node pool’s effective zone and networking settings and test an alternate SKU.
That makes sense. I was surprised because Standard_B2 is a small machine, and I haven’t intentionally forced a zone. The quota is available, but the failure keeps happening during autoscaling rather than only during initial deployment.