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 is no unusual networking configuration, IPv6, or other special setup. However, scaling a node pool or creating a new cluster repeatedly fails with OverconstrainedZonalAllocationRequest. The error says Azure cannot allocate the VMSS because of constraints involving the availability zone, networking requirements, and VM size, and suggests trying another size or zone. The affected region is Germany West Central, and my quota is sufficient. I also don't explicitly force a particular availability zone. Is this a regional capacity problem, and what is the best workaround so autoscaling continues to work?
2 Answers
Because the same error occurs during autoscaling, this is more than a one-time deployment failure. Your node pool is still asking Azure for a very specific combination of resources, even if you haven't manually selected a zone. Consider using a larger or different VM SKU, configuring a second node pool with an alternative size, or choosing another nearby region if possible. Having multiple acceptable node-pool options gives the autoscaler a better chance of finding available capacity. If you stay with the same B-series size and region, the failures may continue whenever capacity is tight.
This usually means Azure temporarily doesn't have enough capacity for the exact combination of region, VM size, zone, and networking requirements. B-series machines can be especially difficult to allocate because they're popular and capacity is limited. Try another supported size, such as the one suggested in the error, or allow a different zone if your configuration permits it. It is also worth checking quotas, although this error generally points to physical capacity rather than a quota limit.
That was my assumption too, but I was surprised it happened with a small Standard_B2 instance. I don't force a zone, and the quota checks are fine.
The main issue is that autoscaling fails whenever a scale event occurs, so I need a workaround that remains reliable instead of just retrying the deployment.