Sathpal Singh Posted on May 31 Karpenter on AKS in 2026: What Actually Works # kubernetes # aks # karpenter # autoscaling Karpenter on AKS in 2026: What Actually Works Karpenter on AKS has gone from "interesting experiment" to "something you can actually run in production" with some caveats that will save you a weekend of pain if you read them now. This post is a field report, not a sales pitch. The Short Version If you're running homogeneous, predictable workloads and you're happy with cluster-autoscaler (CAS), stay there. CAS is boring, it works, and Azure supports it fully. If you're running GPU workloads, spot-heavy batch pipelines, or you need bin-packing that doesn't require you to pre-define a node pool for every VM SKU you might want, Karpenter is now worth the operational overhead. What Karpenter Actually Does on AKS Karpenter watches for unschedulable pods and provisions nodes directly via the Azure provider, no VMSS node pools required for every SKU combination. It provisions, consolidates, and terminates nodes based on pod requirements and your defined NodePool and AKSNodeClass resources. The AKS provider for Karpenter ( karpenter-provider-azure ) is a separate project from the AWS provider. Same core Karpenter engine, different provider implementation. This matters because feature parity with AWS Karpenter is not guaranteed and the cadence of releases differs. Prerequisites and Installation You need: An AKS cluster with --network-plugin azure or --network-plugin overlay (Azure CNI in either mode works; kubenet is not supported) A managed identity with the right RBAC, the provider needs to create and delete VMs and manage NICs, disks, and NSGs Workload identity enabled on the cluster Karpenter installed via Helm The official installation path uses Helm with values pulled from your cluster. Here's a stripped-down install sequence: # Set environment variables: replace with your actual values export CLUSTER_NAME = "my-aks-cluster" export RESOURCE_GROUP = "m
LIVE