<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Etcd on Cloudkaramchari</title><link>https://www.cloudkaramchari.com/tags/etcd/</link><description>Recent content in Etcd on Cloudkaramchari</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>cloudkaramchari</copyright><lastBuildDate>Sat, 05 Sep 2026 16:27:09 +0530</lastBuildDate><atom:link href="https://www.cloudkaramchari.com/tags/etcd/index.xml" rel="self" type="application/rss+xml"/><item><title>AKS Hyperscale Control Plane (Preview): Setup Guide and When You Actually Need It</title><link>https://www.cloudkaramchari.com/blog/aks-hyperscale-control-plane-preview-setup-guide/</link><pubDate>Sat, 05 Sep 2026 16:27:09 +0530</pubDate><guid>https://www.cloudkaramchari.com/blog/aks-hyperscale-control-plane-preview-setup-guide/</guid><description>
&lt;h1 id="aks-hyperscale-control-plane-preview-setup-guide-and-when-you-actually-need-it">AKS Hyperscale Control Plane (Preview): Setup Guide and When You Actually Need It&lt;/h1>
&lt;p>If you've ever run a large AKS cluster and watched &lt;code>kubectl&lt;/code> requests start queuing during a traffic spike, or seen pods sit &lt;code>Pending&lt;/code> while the scheduler falls behind, the cause is usually invisible: the managed control plane itself, not your nodes, ran out of headroom. Azure just gave you a lever for that. As of the August 19, 2026 documentation update, AKS supports a &lt;strong>hyperscale control plane scaling profile (preview)&lt;/strong> — you pick a guaranteed capacity tier (&lt;code>H2&lt;/code>, &lt;code>H4&lt;/code>, or &lt;code>H8&lt;/code>) at cluster creation instead of relying entirely on AKS's dynamic control plane scaling.&lt;/p></description></item></channel></rss>