DEV Community: Sathpal Singh

Picking the Latest Kubernetes Release on AKS Without Shooting Yourself in the Foot

Sathpal Singh — Fri, 24 Jul 2026 07:41:22 +0000

Picking the Latest Kubernetes Release on AKS Without Shooting Yourself in the Foot

Every few months a platform engineer opens a Slack message that reads something like: "Hey, our AKS cluster is on a version that's being retired — what do we do?" The answer is never "just click upgrade," but it also shouldn't be a three-week fire drill. This post walks through how AKS versions work, how to find what's actually available in your region, and how to set a defensible upgrade posture — without repeating the node pool mechanics we've already covered in earlier posts in this series.

How AKS Manages Version Support Windows

AKS doesn't support every Kubernetes minor version forever. Microsoft maintains a sliding support window — commonly described as the three most recent minor versions (N, N-1, N-2) — and retires older releases on a rolling basis. ¹ NEEDS_VALIDATION: confirm the exact N/N-1/N-2 window against current Microsoft docs, as the supported count has varied historically.

What that means operationally: if 1.30 is the current stable release, you can expect 1.29 and 1.28 to remain supported, while 1.27 approaches end-of-life. Clusters still running a retired version don't immediately explode, but they stop receiving security patches and you lose Microsoft support SLA coverage — two things you do not want to explain to your CISO.

Patch versions (the third digit) within a supported minor are more granular. AKS regularly ships node OS patches and Kubernetes patch releases; these are where most of the day-to-day CVE fixes land.

Finding What's Available in Your Region

Version availability is per-region. A version that GA'd last week in East US may still be in preview in Southeast Asia. Always query your actual deployment region before planning an upgrade:

az aks get-versions --location eastus --output table

NEEDS_VALIDATION: confirm --output table renders usefully for this subcommand in current CLI versions; --output json is always safe if the table format shifts.

The output lists minor versions, their patch variants, and whether each is in preview or GA. Treat anything marked preview as off-limits for production unless you have a specific reason and the risk tolerance to match.

If you want the current default version AKS would pick if you didn't specify one:

az aks get-versions --location eastus --output json \
  | jq '[.values[] | select(.isDefault == true)]'

NEEDS_VALIDATION: the isDefault field name — verify against current CLI JSON schema.

Key insight: the AKS default is not necessarily the latest GA patch. ¹ Microsoft selects a "recommended" version that has had some soak time. If you want the latest, you have to ask for it explicitly.

Pinning a Version at Cluster Create Time

To be explicit about your version at cluster creation:

az aks create \
  --resource-group my-rg \
  --name my-cluster \
  --location eastus \
  --kubernetes-version 1.30.2 \
  --node-count 3 \
  --generate-ssh-keys

NEEDS_VALIDATION: substitute the actual latest GA patch for your region; 1.30.2 is illustrative only — do not copy-paste without checking az aks get-versions first.

Omitting --kubernetes-version hands the decision to Microsoft's recommended default. That's fine for dev clusters. For production, pin it, document why you chose that version, and put the upgrade decision in your change process.

Auto-Upgrade Channels: Declaring Upgrade Intent

Manually upgrading clusters is fine until you have fifteen of them. Auto-upgrade channels let you express intent rather than managing individual upgrade events. AKS supports the following channels ¹:

none — no automatic upgrades; you control everything manually.
patch — automatically upgrades to the latest patch within the current minor version.
stable — targets the latest patch on the N-1 minor version.
rapid — targets the latest patch on the latest supported minor version (N).
node-image — upgrades only the node OS image, not the Kubernetes version itself.

NEEDS_VALIDATION: confirm exact current semantics for stable and rapid against Microsoft docs — the mapping of "N" vs "N-1" has been adjusted in past releases.

The node-image channel is worth calling out explicitly: node image upgrades and Kubernetes version upgrades are decoupled. ¹ You can roll fresh OS images (security patches, kernel updates) without touching your Kubernetes minor or patch version. This is the channel most production clusters should be running continuously — there's little reason to let node images go stale.

Setting the channel on an existing cluster:

az aks update \
  --resource-group my-rg \
  --name my-cluster \
  --auto-upgrade-channel patch

Gating Upgrades with Planned Maintenance Windows

Auto-upgrade without a maintenance window means upgrades can fire at any time AKS decides conditions are met. That's a bad day when it happens at 2 PM on a Tuesday during peak traffic. Planned Maintenance lets you constrain when auto-upgrades are allowed to execute. ¹ NEEDS_VALIDATION: confirm current Planned Maintenance API capabilities and whether it gates both K8s and node-image upgrades or only one.

apiVersion: maintenance.azure.com/v1
kind: MaintenanceConfiguration
metadata:
  name: aksmaintenance
spec:
  timeInWeek:
    - day: Saturday
      hourSlots:
        - 2
        - 3
  notAllowedTime:
    - start: "2024-12-20T00:00:00Z"
      end: "2025-01-03T00:00:00Z"

NEEDS_VALIDATION: the above YAML structure is illustrative — validate the exact CRD schema against current AKS documentation before applying.

Alternatively via CLI:

az aks maintenanceconfiguration add \
  --resource-group my-rg \
  --cluster-name my-cluster \
  --name aksManagedAutoUpgradeSchedule \
  --weekday Saturday \
  --start-hour 2

NEEDS_VALIDATION: confirm subcommand name and flags for the current CLI version.

A Concrete Upgrade Decision Process

Here's the numbered checklist I'd run through before touching a production cluster's Kubernetes version:

Query available versions in your target region with az aks get-versions. Confirm the version you want is GA, not preview.
Check your current cluster version with az aks show --resource-group my-rg --name my-cluster --query kubernetesVersion.
Review the Kubernetes changelog for the target minor version. Focus on API deprecations — if your workloads use APIs removed in the target version, fix that first.
Run kubectl deprecations (via the kubent tool or similar) against your cluster to catch any in-use deprecated APIs before the upgrade window. NEEDS_VALIDATION: confirm kubent compatibility with your target version.
Upgrade control plane first, validate, then upgrade node pools — this is standard AKS sequencing. If you need the node pool mechanics, see our earlier posts in this series.
Set your auto-upgrade channel to patch at minimum so you don't fall behind on patch releases between planned minor upgrades.
Configure a Planned Maintenance window so automated patch upgrades don't surprise you in business hours.

The Version Skew Problem

One thing that catches teams off guard: AKS allows your control plane and node pools to differ by at most one minor version, with the control plane always ahead. ² If you're running control plane 1.30 and node pools at 1.28, you have a problem — the node pools need to come up through 1.29 before they can reach 1.30. You cannot skip minor versions on node pools.

This is why letting clusters drift is expensive. A cluster that hasn't been upgraded in a year may require sequential minor version upgrades, each with its own validation cycle.

Putting It Together

Version management on AKS is less about clicking the upgrade button and more about having a policy that makes the decision for you at the right time. Set the patch auto-upgrade channel, add a maintenance window, keep node images continuously current via node-image channel, and plan minor version upgrades quarterly. That's a posture you can defend, automate, and sleep through.

The clusters that cause incidents are the ones where version management was treated as a one-time task rather than a continuous process.

Sources

Architecture

flowchart TD
    A([Platform Engineer]) --> B[az aks get-versions\n--location region]
    B --> C{Version Selection\nStrategy}
    C -->|Pin explicit version| D[az aks create\n--kubernetes-version X.Y.Z]
    C -->|Declare upgrade intent| E[Set Auto-Upgrade Channel]
    E --> F{Channel Choice}
    F -->|Conservative| G[patch\nStay on current minor]
    F -->|Balanced| H[stable\nN-1 minor version]
    F -->|Aggressive| I[rapid\nLatest supported minor]
    D --> J[AKS Cluster]
    G --> J
    H --> J
    I --> J
    J --> K[Planned Maintenance\nWindow Gates Upgrades]
    K --> L{Upgrade Scope}
    L -->|K8s version| M[Control Plane\n+ Node Pools]
    L -->|OS patches only| N[Node Image Upgrade\nDecoupled from K8s]

AKS and Near-Bare-Metal Workloads: What Platform Teams Can Responsibly Plan For

Sathpal Singh — Thu, 23 Jul 2026 16:55:32 +0000

AKS and Near-Bare-Metal Workloads: What Platform Teams Can Responsibly Plan For

Every few months a team shows up with a workload that has opinions about hardware. GPU inference, high-frequency packet processing, latency-sensitive financial systems — something that makes a shared-tenant VM feel like a traffic jam. The conversation usually ends up at "can we get bare-metal nodes on AKS?"

The honest answer right now: partially, with caveats, and you should not trust anyone who gives you a confident full answer without pointing at current documentation. This post is about what you can design around today, what requires validation before you commit to it, and where the gaps are that will bite you if you skip due diligence.

A note on sources: The AKS core concepts and product overview documentation available at time of writing covers cluster and workload fundamentals¹² but does not address bare-metal or near-bare-metal node pool specifics. Claims in that category are marked NEEDS_VALIDATION throughout. Everything else is grounded in general AKS behavior that is broadly consistent across the platform.

Why "Bare-Metal on AKS" Is Complicated Terminology

AKS runs on Azure VMs. Azure VMs run on Azure's physical fleet. The question is how much of the hypervisor overhead and hardware sharing model you can escape.

Azure offers VM SKU families that are designed to minimize virtualization overhead — isolated VM sizes that occupy an entire physical host, giving you a single-tenant hardware environment. Whether specific SKUs in this category are available as AKS node pool targets depends on regional availability and AKS's supported VM size list. NEEDS_VALIDATION — check the current AKS supported VM sizes documentation for your target region before designing around a specific SKU.

What you get with isolated or near-bare-metal SKUs, if available:

Predictable NUMA topology — no neighbor noise on the physical host
Full access to hardware features — relevant for SR-IOV, DPDK, and accelerated networking scenarios (NEEDS_VALIDATION for specific feature compatibility with AKS CNI configurations)
Single-tenant physical isolation — meaningful for compliance frameworks that require it

What you do NOT automatically get:

A different version of Kubernetes
Different node lifecycle behavior
Escape from AKS's node auto-repair or OS upgrade mechanics

That last point is where platform teams usually get surprised.

Node Lifecycle Is Still AKS's Domain

AKS manages node health and upgrades at the node pool level¹. This does not change because you picked a specialty VM SKU. If auto-repair decides a node is unhealthy and reprovisioned it, the replacement VM must come from available capacity of the same SKU. For isolated VM families, that capacity is often constrained — regionally and numerically.

The practical consequence: your cluster auto-repair and upgrade assumptions need re-evaluation for specialty node pools.

For standard node pools on commodity SKUs, AKS node upgrade behavior is well-documented and we've covered it in depth in our prior upgrade series (#2, #42, #50). The short version is that AKS handles node image upgrades via cordon-drain-replace, and you control the surge buffer and max unavailable settings. That mechanical behavior is the same regardless of SKU. What changes is the risk profile:

Capacity risk: If your isolated SKU has low regional availability, a surge node during upgrade may not provision. The upgrade stalls.
Drain timing risk: Pods on high-performance hardware often have longer graceful termination windows. Make sure your terminationGracePeriodSeconds reflects that.
OS upgrade compatibility: Node OS image updates on specialty hardware SKUs may lag behind standard SKU rollouts. NEEDS_VALIDATION — check AKS release notes for your target SKU family.

Node Pool Isolation Strategy

If you're mixing standard workloads and hardware-sensitive workloads in the same cluster (which is a reasonable cost efficiency decision), node pool isolation is non-negotiable. This is standard AKS practice¹ and applies regardless of whether the specialty pool is "bare-metal adjacent" or not.

The pattern:

Separate node pools by workload class — one pool for standard platform services, one for hardware-intensive workloads
Taint specialty node pools — prevent accidental scheduling of standard workloads onto expensive hardware
Use node selectors and tolerations explicitly — don't rely on the absence of a node being "wrong enough" to avoid it
Set resource requests and limits that reflect actual hardware — on high-performance SKUs with full NUMA access, misconfigured limits can be worse than no limits

Here's a minimal node pool configuration pattern for a tainted specialty pool:

# Create a specialty node pool with a taint to prevent accidental scheduling
# Replace <SKU_NAME> with your validated target SKU
az aks nodepool add \
  --resource-group myRG \
  --cluster-name myCluster \
  --name specialtypool \
  --node-vm-size <SKU_NAME> \ # NEEDS_VALIDATION: confirm SKU is AKS-supported
  --node-count 2 \
  --node-taints workload-class=hardware-intensive:NoSchedule \
  --labels workload-class=hardware-intensive \
  --zones 1 2 3

And the corresponding pod spec side:

apiVersion: v1
kind: Pod
metadata:
  name: hardware-sensitive-workload
spec:
  tolerations:
    - key: "workload-class"
      operator: "Equal"
      value: "hardware-intensive"
      effect: "NoSchedule"
  nodeSelector:
    workload-class: hardware-intensive
  containers:
    - name: app
      image: your-registry/your-image # pin your digest, don't use latest
      resources:
        requests:
          cpu: "8"
          memory: "32Gi"
        limits:
          cpu: "8"
          memory: "32Gi"

Concrete Steps Before Committing to a Specialty Node Pool

Validate SKU availability in your target region. Run az vm list-skus --location <region> --size <sku-prefix> --output table and cross-reference against the AKS supported VM sizes list. Do not assume a SKU that works for standalone VMs is available for AKS node pools.
Check current AKS release notes for the SKU family. Look specifically for known issues with node auto-repair, OS image compatibility, or accelerated networking feature support. NEEDS_VALIDATION — this is release-cadence dependent.
Model your capacity headroom. For upgrade surge and auto-repair replacement, you need available quota and available physical capacity. For isolated SKUs, physical capacity is the harder constraint. File a support ticket to confirm capacity commitments if the workload is business-critical.
Test node pool upgrade behavior in a non-production cluster first. Don't discover that your specialty SKU has zero surge capacity during a production Kubernetes version upgrade. The upgrade series we've covered previously (#50 is the most current approved version) gives you the tooling — apply the same runbook to a test specialty pool before you need it for real.
Define your eviction and rescheduling strategy. If a node is auto-repaired and the replacement takes longer than expected (capacity contention), what happens to your workload? PodDisruptionBudgets should reflect the actual tolerance of the workload, not the default.
Align with your golden path guardrails. If your platform has golden path templates (covered in #25), specialty node pools should either be an explicit supported variant or explicitly out-of-scope. The worst outcome is an undocumented workaround that every team discovers independently and implements differently.

What Not To Do

Don't build production dependency on a feature that's in preview. AKS preview features can change or be dropped. If a specific bare-metal adjacent capability is currently in preview, treat it as R&D, not production infrastructure.
Don't assume SKU-level isolation means network-level isolation. Physical host isolation and network security are different axes. Your CNI configuration and network policies still matter.
Don't skip the PodDisruptionBudget. On hardware-intensive workloads, the instinct is often "this thing is stateful and complex, let's not let Kubernetes touch it." That instinct leads to nodes that can't be drained and upgrades that time out.

The Responsible Summary

AKS can host workloads on VM SKUs designed to reduce virtualization overhead and provide single-tenant hardware access. The exact SKUs available, their compatibility with specific AKS networking and acceleration features, and their behavior under node lifecycle operations all require validation against current documentation before you commit. NEEDS_VALIDATION on the specifics is not a cop-out — it's the difference between a platform that works and a platform that works until it doesn't.

What you can design now: isolation strategy, taint/toleration patterns, upgrade runbooks, and capacity planning processes. Get those right and the hardware specifics slot in cleanly once validated.

Sources

Architecture

flowchart TD
    A[Platform Team Evaluation] --> B{Workload Requirements}
    B --> C[Standard Latency\nGeneral Purpose VMs]
    B --> D[Low Latency / Hardware Intensive\nSpecialty VM SKUs]
    D --> E[Validate SKU Availability\nby Region]
    E --> F[Dedicated Node Pool\nIsolation Strategy]
    F --> G[Review Auto-Repair &\nOS Upgrade Behavior]
    G --> H[Node Pool Taints & Tolerations\nfor Workload Scheduling]
    C --> H
    H --> I[Mixed Cluster:\nStandard + Specialty Pools]
    I --> J[Ongoing: Monitor AKS\nRelease Notes & SKU Docs]

Karpenter on AKS in 2026: What Actually Works

Sathpal Singh — Sun, 31 May 2026 05:21:06 +0000

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="my-rg"
export LOCATION="eastus2"
export KARPENTER_NAMESPACE="kube-system"

# Get cluster details needed for Karpenter config
export SUBSCRIPTION_ID=$(az account show --query id -o tsv)
export NODE_RESOURCE_GROUP=$(az aks show \
  --name "${CLUSTER_NAME}" \
  --resource-group "${RESOURCE_GROUP}" \
  --query nodeResourceGroup -o tsv)

# Install via Helm
# NEEDS_VALIDATION: confirm chart version and repo URL against
# https://github.com/Azure/karpenter-provider-azure at time of deployment
helm upgrade --install karpenter oci://mcr.microsoft.com/aks/karpenter/karpenter \
  --namespace "${KARPENTER_NAMESPACE}" \
  --create-namespace \
  --set "settings.clusterName=${CLUSTER_NAME}" \
  --set "settings.location=${LOCATION}" \
  --set "settings.subscriptionID=${SUBSCRIPTION_ID}" \
  --set "settings.resourceGroup=${NODE_RESOURCE_GROUP}" \
  --wait

Defining Your First NodePool

This is where Karpenter's model diverges most from node pools. Instead of pre-creating a pool for every SKU you might want, you define constraints and let Karpenter pick:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: general
spec:
  template:
    metadata:
      labels:
        workload-type: general
    spec:
      nodeClassRef:
        apiVersion: karpenter.azure.com/v1alpha2
        kind: AKSNodeClass
        name: default
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["on-demand", "spot"]
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64"]
        - key: karpenter.azure.com/sku-family
          operator: In
          values: ["D", "E"]
        - key: karpenter.azure.com/sku-version
          operator: Gt
          values: ["3"]
  limits:
    cpu: "200"
    memory: 800Gi
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 30s
---
apiVersion: karpenter.azure.com/v1alpha2
kind: AKSNodeClass
metadata:
  name: default
spec:
  imageFamily: AzureLinux
  osDiskSizeGB: 128

Note on API versions: The karpenter.azure.com API group is versioned separately from upstream Karpenter. v1alpha2 was current as of early 2026 but NEEDS_VALIDATION check the CRD definitions in the installed chart before you copy this into a GitOps repo.

What Works Well

Spot consolidation is the headline win. When spot VMs get preempted or you have underutilized nodes, Karpenter's consolidation loop handles bin-packing without you writing any automation. With CAS you're responsible for node pool min/max sizing and the consolidation is coarse.

Multi-SKU scheduling is the other real win. A pod requesting 8 vCPU and 64 GiB RAM will cause Karpenter to search the allowed SKU families for a node that fits, rather than failing because your single pre-configured node pool is exhausted.

GPU node provisioning works, including time-slicing scenarios, as long as your AKSNodeClass uses an image family that ships the NVIDIA drivers. AzureLinux with GPU extensions does this. You still need to manage the device plugin separately.

What Is Still Rough

Node provisioning latency is higher than AWS because Azure VM creation is slower than EC2. Plan for 3–5 minutes from pod pending to node ready on cold starts. This isn't a Karpenter problem per se, but it affects how you design your buffer capacity and PodDisruptionBudgets.

Windows node pools are not supported by the Azure Karpenter provider. If you have Windows workloads, keep a static node pool managed by CAS or manual scaling.

Custom VNet/subnet selection requires care. The AKSNodeClass lets you specify subnet IDs, but if you're using private clusters with complex network topologies, test thoroughly before rolling to production. Subnet exhaustion errors surface late and are annoying to debug.

Observability is immature. Karpenter emits metrics to Prometheus and logs to stdout, but the AKS provider's specific actions (VM creation, NIC attachment) aren't surfaced as well as you'd want. You'll be reading kubectl logs more than you'd like.

Concrete Steps to a Safe Rollout

Start with a non-production cluster. Run Karpenter alongside CAS, not instead of it. CAS can manage your system node pool; Karpenter handles a workload node pool namespace.
Define limits on your NodePool. Without a CPU/memory ceiling, a scheduling bug or runaway HPA can provision hundreds of nodes before you notice. Set limits conservatively and raise them deliberately.
Set consolidateAfter to something sane for your workload. 30 seconds is aggressive for stateful apps. Use 5–10 minutes for anything with slow startup or persistent volumes.
Test spot preemption handling. Deploy a test workload on spot nodes and manually deallocate a VM. Verify that Karpenter reprovisioned within your acceptable window and that your pod disruption budgets held.
Add Karpenter's node labels to your monitoring dashboards. Specifically track karpenter.sh/capacity-type, karpenter.azure.com/sku-name, and karpenter.sh/nodepool as label dimensions so you can see cost and performance breakdown by node type.
Pin your Helm chart version in GitOps. The provider is still in active development. Uncontrolled upgrades have broken NodePool CRD schemas between minor versions. Treat upgrades as a planned event.

CAS vs. Karpenter: The Honest Comparison

Concern	CAS	Karpenter
Operational maturity on AKS	Production-grade	Production-capable with caveats
Multi-SKU bin-packing	Requires pre-defined pools	Native
Spot handling	Decent	Better
Windows nodes	Yes	No
Debug tooling	Mature	Developing
Azure support	First-party	Community + Microsoft OSS

Final Thoughts

Karpenter on AKS in 2026 is the right choice if you have heterogeneous compute requirements and engineering capacity to own the operational model. It is not yet the "set it and forget it" experience that CAS is for straightforward clusters.

The Azure team has been shipping at a reasonable pace and the GitHub issues backlog is actually getting shorter, which is a good sign. The API is stabilizing. The path from alpha to beta to stable is visible.

Just don't copy that YAML into production without validating the API versions first. I warned you.