I spotted this land in the aks-preview extension recently. Microsoft has merged support for a control plane scaling profile into the AKS CLI, introducing what the API calls “hyperscale” control plane sizes. For the first time you can specify a control plane tier at cluster creation with guaranteed capacity and predictable performance, and actually see what you are getting in exchange.
Why this matters
For most clusters, the managed control plane is invisible in the best way. You set your node count, configure autoscaling, and the control plane keeps up. But for large clusters with thousands of pods, or workloads that drive high API server request rates, the control plane becomes a bottleneck. You see it as API server latency, slow pod scheduling, or etcd pressure under load.
The new --control-plane-scaling-size flag lets you pick between H2, H4, and H8 when creating a cluster. The docs are now live with specific numbers.
| Size | API Server Concurrency | Pod Scheduling Rate | Etcd Storage |
|---|---|---|---|
| H2 | 1,750 executing requests | 200 pods/second | 6 partitions, 8 GB each |
| H4 | 3,500 executing requests | 300 pods/second | 6 partitions, 8 GB each |
| H8 | 7,000 executing requests | 400 pods/second | 6 partitions, 8 GB each |
Concurrency and scheduling throughput double between each tier. Storage does not scale with the tier. All three use six etcd partitions at 8 GB each, split by resource type across Events, Leases, Nodes, Pods, Secrets, and a default partition for everything else like Deployments, Services, and ConfigMaps. Microsoft recommends keeping each partition at or below 2 GB to maintain low latency and shorter startup times.
Hyperscale configuration requires a Standard or Premium pricing tier cluster. It is not supported on the Free tier.
How to set it up
You need aks-preview at version 21.0.0b8 or later, Kubernetes 1.33.0 or later, and the ControlPlaneScalingProfilePreview feature flag registered on your subscription. Run these three commands to get set up.
|
1 2 3 4 5 6 7 |
az extension add --name aks-preview --allow-preview true az feature register \ --namespace Microsoft.ContainerService \ --name ControlPlaneScalingProfilePreview az provider register --namespace Microsoft.ContainerService |
Wait for the feature flag to show as Registered before moving on. You can check with az feature show --namespace Microsoft.ContainerService --name ControlPlaneScalingProfilePreview. It usually takes a couple of minutes.
There is one preview-specific limit worth knowing upfront. Only one hyperscale cluster is supported per subscription per region. If you are planning to test across multiple environments, factor that in before you decide where to stand it up.
Once the flag is registered, create your cluster with a scaling size. H4 is used here as a reasonable middle tier.
|
1 2 3 4 5 6 7 8 9 10 11 |
az aks create \ --resource-group MyResourceGroup \ --name MyManagedCluster \ --kubernetes-version 1.33.0 \ --tier Standard \ --control-plane-scaling-size H4 \ --network-plugin azure \ --network-plugin-mode overlay \ --pod-cidr 10.244.0.0/16 \ --node-count 3 \ --generate-ssh-keys |
Expect provisioning to take longer than a standard cluster. H2 takes around 10 minutes; H4 and H8 take around 20. Once it completes, confirm the control plane scaling profile was applied.
|
1 2 3 4 |
az aks show \ --resource-group MyResourceGroup \ --name MyManagedCluster \ --query controlPlaneScalingProfile |
You should see {"scalingSize": "H4"} back. If the field is null or missing, the feature flag was likely not in a Registered state when the cluster was created.
There is an important distinction on what you can and cannot change later. Once a cluster has a hyperscale profile, you can resize between tiers using az aks update.
|
1 2 3 4 |
az aks update \ --resource-group MyResourceGroup \ --name MyManagedCluster \ --control-plane-scaling-size H8 |
What you cannot do is add hyperscale to an existing standard cluster or remove the profile after creation. To revert to a standard control plane, you are looking at a cluster deletion and recreate. Size deliberately from the start.
One more tooling limitation worth calling out. Terraform and the Azure SDKs do not support the control plane scaling profile yet. You are limited to the Azure CLI with aks-preview, the REST API, or ARM templates for now.
A few things worth keeping in mind when you build the cluster. Avoid enabling the Azure Policy add-on on large hyperscale clusters. It increases API server load and can affect control plane performance at scale. The Azure CNI Overlay networking in the example above is also the recommended option for clusters expecting high pod counts, not just a style choice, because it reduces IP address consumption.
Hyperscale gives you guaranteed capacity, but your workloads should still be good API citizens. Excessive list and watch operations add up and will eat into that headroom faster than you might expect. Each etcd partition has an 8 GB hard limit, but Microsoft’s guidance is to design for 2 GB or less per partition to keep latency low and reduce startup time.
Things to watch once it is running
AKS exposes three metrics that tell you whether your chosen tier is holding up under real load. You can access them through Azure Monitor Metrics Explorer or Azure Managed Prometheus.
- API request concurrency (
apiserver_flowcontrol_executing_seats) shows the current number of API Priority and Fairness execution seats in use. If this is consistently approaching the guaranteed limit for your tier, you are running close to the ceiling. - Pod scheduling rate (
scheduler_schedule_attempts_rate) breaks down scheduling attempts by outcome. A rising rate of unschedulable pods is a sign the scheduler is not keeping pace with demand. - Cluster database size (
etcd_database_usage_percentage) shows utilisation per etcd partition. Any partition approaching 100% needs attention before it hits the 8 GB hard limit.
Set alerts on all three before you go near production. Catching tier pressure early is far better than diagnosing it under incident conditions.
Wrapping up
The control plane has always been the part of AKS you could not tune. That changes with this. The numbers in the docs are specific enough to make a real sizing decision, and the ability to resize between tiers after creation removes some of the risk of getting it wrong initially.
That said, this is still preview, and the constraint that matters most is the one you cannot work around without recreating the cluster. If you stand up an H4 cluster and later decide you need H2 to cut costs, or realise you should have started at H8, you are looking at a rebuild. The resize path only works within the hyperscale tier set, not back to standard.
If you are running large clusters and already feeling control plane pressure, this is worth testing in a dev or staging environment now. The one-cluster-per-subscription-per-region limit during preview means you only get one shot per region, so pick the environment deliberately. If you try it, I would be interested to hear how the metrics look under real load.
0 Comments