Microsoft Build 2026 produced a substantial wave of Azure Kubernetes Service announcements, and most of them point in the same direction: AKS is shifting from "managed Kubernetes" toward an opinionated platform for running AI-heavy production workloads with as little undifferentiated cluster work as possible.

If you run or plan production workloads on AKS — whether you are a Malaysian enterprise standardizing on malaysiawest, or a regional team operating clusters across Azure, on-premises, and other clouds — the useful question is not "what was announced?" but "what requires action now, and what can wait?"

This article cuts through the marketing. Everything below is checked against the official AKS release notes and Microsoft Learn documentation, with dates and commands you can verify yourself.

What Build 2026 Actually Announced for AKS

Microsoft's own framing of the Build announcements was honest about the problem: running training and inference at scale means cost, latency, and reliability are constantly in tension. The announcements expand what you can control at four layers: the cluster itself, hardware proximity, fleet operations, and the AI workload layer.

1. AKS Automatic grows up: managed system node pools are GA

AKS Automatic reached general availability in September 2025 (release notes 2025-09-21), with its compute-based billing model taking effect on 19 October 2025. At Build 2026, the headline cluster-layer announcement was that managed system node pools in AKS Automatic are now generally available (release notes 2026-05-29).

Previously, even on AKS Automatic you still had to plan capacity, patch, and scale the system node pool that runs core cluster components like CoreDNS and metrics-server. Now Azure handles that entire lifecycle. Three practical consequences:

  • System VMs are not charged to your subscription — AKS absorbs the compute cost of the managed system pool.
  • System components stop competing with your workloads for resources, which matters a lot when your user nodes are expensive GPU machines.
  • Security posture is hardened by default: new Automatic clusters with managed system node pools block customer-supplied SSH keys, deny kubectl port-forward to the system pool, restrict read access to kube-system secrets, and enforce a ValidatingAdmissionPolicy that blocks Services from setting spec.externalIPs.

AKS Automatic clusters also come preconfigured with the Standard tier (uptime SLA plus a financially backed pod readiness SLA — 99.9% of qualifying pod readiness operations complete within five minutes), a managed virtual network on Azure CNI Overlay powered by Cilium, a managed NAT gateway for egress, and — from AKS 1.36 — Gateway API ingress via the application routing add-on. New Automatic clusters also preconfigure LocalDNS in Required mode.

# Create an AKS Automatic cluster (verified syntax from the AKS quickstart)
az aks create \
  --resource-group rg-production \
  --name aks-automatic-prod \
  --sku automatic \
  --enable-hosted-system

# Confirm the managed system profile
az aks show \
  --resource-group rg-production \
  --name aks-automatic-prod \
  --query hostedSystemProfile

The practical impact: for new workloads that do not need exotic node-level customization, AKS Automatic removes most of the remaining node-lifecycle work. One important caveat: new AKS Automatic clusters can no longer be created without managed system node pools, and if you have an existing Automatic cluster without them, the documented path is to recreate the cluster and migrate workloads — there is no in-place flip.

AKS Automatic is GA in more than 35 regions, including malaysiawest, southeastasia, and eastasia.

2. The AI workload layer becomes first-class

This is where Build 2026 differed most from previous years. Three announcements target AI training and inference directly:

AKS on bare metal (public preview). You can now run AKS on dedicated machines without a hypervisor, with direct access to NVLink, RDMA, and high-performance networking — while keeping the same AKS control plane and APIs. This is aimed squarely at large training jobs, latency-sensitive inference, and high-throughput data pipelines, where virtualization overhead translates directly into cost and runtime.

Anyscale on Azure (public preview). Managed Ray, running on AKS, inside your own Azure subscription, integrated with Entra ID, and billed through your existing agreement. Kubernetes handles scheduling and cluster lifecycle; Ray coordinates distributed execution within a workload, including mixed CPU+GPU scheduling, heterogeneous and fractional GPU allocation, and dynamic job scaling. Microsoft's reference customer is Wayve, which uses AKS, Ray, and Anyscale to connect thousands of GPUs into a flexible training supercomputer for its autonomous driving models.

AI Runway and KAITO. AI Runway (an open-source project introduced at KubeCon + CloudNativeCon Europe 2026) gives you a Kubernetes-native path from "I have a model" to "I have a serving endpoint": select a model, validate it fits your available GPU memory, review a cost estimate, and deploy. That creates a ModelDeployment custom resource that drives the rest of the workflow. AI Runway sits as a platform layer with multiple serving providers — KAITO, NVIDIA Dynamo, KubeRay, and LLM-D — and supports engines including vLLM, SGLang, TensorRT-LLM, and llama.cpp. Underneath, KAITO — the Kubernetes AI Toolchain Operator, a CNCF open-source project — estimates resource requirements, provisions nodes through Karpenter, and launches the optimized runtime (vLLM today). From there, standard Kubernetes machinery takes over: KEDA autoscales on workload metrics, Gateway API handles routing, and rollouts follow familiar patterns.

The Royal Bank of Canada example from Build is worth studying: a self-service AI platform on AKS where dev teams provision GPU resources and deploy models through their own CI/CD, with KAITO handling production serving and model images kept in a private ACR — the whole path wrapped in private endpoints, Entra ID, and Key Vault. That is the compliance-friendly pattern Malaysian financial institutions will recognize.

3. Fleet Manager for Arc-enabled clusters is GA

Azure Kubernetes Fleet Manager for Arc-enabled clusters is now generally available, extending fleet-level control beyond Azure into on-premises and other-cloud clusters. From one control plane you can roll out updates progressively with health checks between stages, place workloads based on GPU availability and SKU, and apply RBAC consistently. If you operate more than two or three clusters — which is most enterprises I talk to — this is the feature that turns "many clusters" into "one system."

4. Azure Container Linux is GA

Azure Container Linux, a minimal container-optimized Linux distribution maintained by Microsoft, reached general availability. The smaller package footprint reduces patching overhead and limits configuration drift across clusters. For fleets, a consistent host-OS baseline is easier to secure over time — and it is one fewer OS variant to test during the Ubuntu migration discussed below.

The Unglamorous Deadline: Ubuntu 22.04 End of Support

Not a Build announcement, but arguably the most urgent item for anyone running AKS in production today. From the release notes of 2026-04-02:

  • 30 June 2027 — AKS stops supporting Ubuntu 22.04 and stops providing security updates. After that date you cannot create new Ubuntu 22.04 node pools, AKS produces no new node images, and existing pools stop receiving security patches.
  • 30 April 2028 — AKS removes Ubuntu 22.04 node images and code entirely; scaling and remediation operations fail.
  • 17 March 2027 — Ubuntu 20.04 retires: no new node pools, no new node images, and no security patches after that date (node images and code are removed on 17 March 2028).
  • Long-term support (LTS) for Kubernetes 1.33 or later requires Ubuntu 24.04.

Migration options are documented and, in the common case, automatic: if your node pools use the default Ubuntu OS SKU, they migrate to Ubuntu 24.04 automatically when you upgrade to Kubernetes 1.35 or later. If you pinned Ubuntu2204, update the OS SKU to Ubuntu (on Kubernetes 1.35+) or Ubuntu2404 (on 1.32+).

# Audit every cluster: which pools are on which OS SKU and Kubernetes version
az aks show --resource-group rg-prod --name aks-prod \
  --query "agentPoolProfiles[].{pool:name, osSku:osSku, version:currentOrchestratorVersion, nodes:count}" \
  --output table

# Refresh node images (also how CVE mitigations reach your nodes)
az aks nodepool upgrade \
  --resource-group rg-prod \
  --cluster-name aks-prod \
  --name systempool \
  --node-image-only

We saw exactly what waiting costs during the Azure Linux 2.0 retirement: support ended 30 November 2025, the node image froze, and from 31 March 2026 affected pools could no longer scale. Plan the Ubuntu migration in the second half of 2026, not in Q2 2027.

Practical Moves for Production Clusters

Cut idle compute costs with Spot and scale-to-zero

Node compute dominates AKS spend. Two well-proven levers:

# Spot node pool for interruption-tolerant workloads
az aks nodepool add \
  --resource-group rg-prod \
  --cluster-name aks-prod \
  --name spotpool \
  --priority Spot \
  --eviction-policy Delete \
  --spot-max-price -1 \
  --enable-cluster-autoscaler \
  --min-count 0 \
  --max-count 10

For queue-driven workloads, the KEDA add-on scales deployments to zero when there is nothing to process:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: worker-scaler
spec:
  scaleTargetRef:
    name: queue-worker
  minReplicaCount: 0
  maxReplicaCount: 50
  triggers:
  - type: azure-servicebus
    metadata:
      queueName: requests
      namespace: sb-prod

One warning from the KEDA documentation: do not combine a KEDA ScaledObject with a HorizontalPodAutoscaler on the same workload — KEDA uses an HPA internally, and the two will fight.

Use the new safety net: node pool rollback

Node pool rollback became generally available in the August 2026 release (v20260807). If a node pool upgrade goes wrong, you have seven days to restore the previous Kubernetes version and node image:

az aks nodepool rollback \
  --resource-group rg-prod \
  --cluster-name aks-prod \
  --name systempool

Combined with planned maintenance windows, this removes much of the weekend-upgrade anxiety from AKS operations.

Speed up deployments with Artifact Streaming

Also GA in mid-2026: Artifact Streaming pulls container images from Azure Container Registry on demand, fetching only the layers a pod needs at startup. For large AI images — where multi-gigabyte model-serving images are normal — this materially shortens pod startup time during scale-out events.

Pitfalls I See Repeatedly

1. Treating AKS Automatic as an in-place upgrade path. It is not. Existing Automatic clusters without managed system node pools must be recreated and migrated, and Standard clusters are not "converted" to Automatic. Evaluate Automatic for new workloads; plan Standard-to-Automatic as a migration project.

2. Ignoring node image versions after a security bulletin. Nodes are not patched in place. When AKS issued bulletin AKS-2026-0003 (CVE-2026-31431, a kernel vulnerability that lets a pod escalate to root on the node), the mitigation shipped in node images 202604.13.0 and 202604.24.0 — existing nodes only became protected after a node image upgrade. If your clusters sit on old node images, you are carrying CVEs that already have fixes.

3. Staying on Ingress NGINX. The upstream Ingress NGINX project ended maintenance in March 2026, and the AKS application routing add-on's NGINX experience remains production-supported only through November 2026. New Automatic clusters (1.36+) already default to Gateway API. Start migration planning now.

4. Waiting until 2027 for the Ubuntu migration. The Azure Linux 2.0 retirement showed the failure mode: frozen images, then scaling failures. Teams that audit OS SKUs now can ride the migration inside normal Kubernetes version upgrades instead of an emergency project.

5. Putting preview features on the production path. AKS on bare metal and Anyscale on Azure are public previews. Design your production AI path on GA primitives (GPU node pools, KAITO, KEDA, Fleet Manager) and use the previews for evaluation and benchmarking until they reach GA.

Recommendations for Malaysian Enterprises

  1. Pilot AKS Automatic in `malaysiawest` for your next new workload — the managed system node pools, Cilium networking, and pod readiness SLA remove most operational overhead.
  2. Audit OS SKUs across all clusters this quarter and schedule the Ubuntu 24.04 transition with your normal upgrade cadence in late 2026.
  3. For AI platforms, follow the RBC pattern: KAITO for serving, private ACR for model images, private endpoints plus Entra ID workload identity for data access. If you need managed distributed training, evaluate Anyscale on Azure in preview.
  4. Adopt the new operational safety nets: node pool rollback, Artifact Streaming, and automatic availability zone placement (availabilityZones=["auto"], globally enabled in the August 2026 release).
  5. Put Ingress NGINX migration on the 2026 roadmap before the November 2026 support boundary.

Key Takeaways

  1. AKS Automatic is the low-operations default now. Managed system node pools are GA, system pool compute is free to your subscription, and the default security posture is stricter than most hand-built clusters.
  2. The 2026 AI story is GPU operations on Kubernetes — bare-metal preview, Anyscale/Ray, and the AI Runway + KAITO toolchain make AKS a credible substrate for both training and inference.
  3. Ubuntu 22.04 support ends 30 June 2027. Audit OS SKUs now; the default Ubuntu SKU migrates automatically on Kubernetes 1.35+.
  4. Fleet Manager for Arc GA means one control plane across Azure, on-premises, and other clouds — progressive rollouts, GPU-aware placement, consistent RBAC.
  5. Use the safety features the platform just gained: seven-day node pool rollback, Artifact Streaming for fast image pulls, and automatic zone placement.

If you are planning an AKS modernization or an AI platform on Azure and want a second opinion on the architecture, reach out — I am happy to review your design.