Microsoft Build 2026 was, above all, about running AI workloads on Kubernetes. The official AKS announcement list reads like an AI platform roadmap: managed system node pools in AKS Automatic going GA, Azure Container Linux GA as the standardized host OS, AKS on bare metal in public preview for direct NVLink and RDMA access, Fleet Manager support for Arc-enabled clusters going GA, managed Ray through Anyscale on Azure, and the AI Runway plus KAITO model-serving stack.

But behind the AI headline, the operational foundations kept maturing too. Three capabilities matter most to the production teams I work with in Kuala Lumpur and Singapore: blue-green node pool upgrades (now configurable with soak times and batch drains), cross-cluster networking in Azure Kubernetes Fleet Manager, and AKS-managed GPU node pools that ship DCGM metrics out of the box. None of these are brand new at Build — some are GA, some are preview — but together they answer the question every enterprise AKS owner eventually asks: how do I upgrade, connect, and monitor this thing without a maintenance window?

Here is where each one actually stands, with the commands I use in real deployments.

Blue-Green Node Pool Upgrades: Soak Times Instead of Upgrade Windows

If you have ever stared at a Kubernetes upgrade at 2 AM, waiting for the last node to drain while your SLA bleeds away, blue-green node pool upgrades are the capability you have been asking for.

The mechanism is now first-class in AKS: every node pool carries an upgradeStrategy. The default is Rolling — the traditional surge-and-reimage flow. Set it to BlueGreen, and upgrades behave differently: AKS provisions a full set of green nodes at the target version, drains workloads off the blue nodes in controlled batches, and keeps the blue nodes around for a final soak period before deletion. Your old capacity stays intact until you are satisfied with the new one.

There are no az aks nodepool cordon or drain commands — the orchestration is declarative, driven by four tuning parameters on the node pool:

  • --drain-batch-size — number or percentage of nodes drained per batch (default 10%)
  • --batch-soak-duration — wait time between batches in minutes (default 15)
  • --drain-timeout-bg — eviction timeout per node, honors Pod Disruption Budgets (default 30 minutes)
  • --final-soak-duration — how long old nodes stay around after draining completes (default 60 minutes)

Enabling the Blue-Green Strategy

# New node pool with blue-green upgrade strategy
az aks nodepool add \
  --resource-group rg-aks-prod \
  --cluster-name aks-prod-my \
  --name nodepool1 \
  --upgrade-strategy BlueGreen

# Tune the upgrade behavior on an existing pool
az aks nodepool update \
  --resource-group rg-aks-prod \
  --cluster-name aks-prod-my \
  --name nodepool1 \
  --drain-batch-size 50% \
  --drain-timeout-bg 5 \
  --batch-soak-duration 10 \
  --final-soak-duration 10

When a cluster or node pool upgrade runs (az aks upgrade / az aks nodepool upgrade), the blue-green path executes automatically. You watch the batches soak, validate the green capacity under real traffic, and the old nodes are deleted only after the final soak completes.

Why Malaysian Enterprises Care

For customers operating under strict change management — financial institutions and government-linked companies in particular — the soak windows are a compliance feature, not just an engineering one. A batch soak gives you a defined observation point to attach to your change record. The 60-minute default final soak is your rollback window: if something surfaces on the green nodes, the blue capacity is still there and still registered.

Two operational notes from experience:

  • Size for double capacity. During the upgrade you temporarily carry blue and green nodes. If your quota or budget cannot absorb a full second pool, keep batch sizes small and drains slow.
  • The strategy applies to Kubernetes version and node image upgrades. It is not a substitute for application-level blue-green deployments, which remain your responsibility at the ingress and DNS layer.

Cross-Cluster Networking with Fleet Manager

Most teams I meet are not running one cluster — they are running several, often split by data residency. A common ASEAN pattern: a primary cluster in Malaysia West for PDPA-sensitive workloads, with a second cluster in Southeast Asia (Singapore) for DR and regional failover. Historically, unifying networking across those clusters meant manual DNS work, service mesh overlays, or custom ingress glue.

Azure Kubernetes Fleet Manager now covers three distinct traffic problems, and it is worth being precise about which is which:

  • East–west (service-to-service): cross-cluster networking lets endpoints in member clusters talk directly, with network policy enforcement and global service discovery integrated with CoreDNS.
  • North–south, public: DNS load balancing wires exported services into Azure Traffic Manager via TrafficManagerProfile and TrafficManagerBackend CRDs, giving exported services a globally available public DNS name.
  • North–south, intra-VNet: the MultiClusterService resource makes each member cluster's Azure Load Balancer route to local endpoints and to endpoints of the same service on other member clusters.

Multi-cluster networking features are still maturing — check current preview/GA status per capability before committing — but the primitives are stable enough to design against.

Joining Two Clusters to a Fleet

# Register the Malaysian cluster
az fleet member create \
  -g rg-fleet \
  -f fleet-asean \
  -n aks-my-central \
  --member-cluster-id "/subscriptions/{sub-id}/resourceGroups/rg-aks-my/providers/Microsoft.ContainerService/managedClusters/aks-my-central"

# Register the Singapore cluster
az fleet member create \
  -g rg-fleet \
  -f fleet-asean \
  -n aks-sg-dr \
  --member-cluster-id "/subscriptions/{sub-id}/resourceGroups/rg-aks-sg/providers/Microsoft.ContainerService/managedClusters/aks-sg-dr"

Exposing a Service Across Clusters

On the member cluster, export the service:

apiVersion: networking.fleet.azure.com/v1alpha1
kind: ServiceExport
metadata:
  name: payment-api
  namespace: production

On the hub, declare a MultiClusterService that load-balances across all member endpoints:

apiVersion: networking.fleet.azure.com/v1alpha1
kind: MultiClusterService
metadata:
  name: payment-api
  namespace: production
spec:
  ports:
    - port: 80
      targetPort: 8080

In practice this is what makes the Malaysia-plus-Singapore pattern operationally sane: the failover story stops being a runbook full of DNS changes and becomes a placement and health-check problem that the fleet control plane handles. Note that member clusters must share a Microsoft Entra tenant, though they can span regions, resource groups, and subscriptions.

GPU Monitoring Without Building Your Own Exporter Stack

If you run inference servers or training jobs on AKS, you have probably operated the NVIDIA GPU Operator yourself — driver versions, device plugin, a DCGM exporter scraping somewhere, dashboards bolted on after the fact. That stack works, but it is undifferentiated operational overhead.

AKS-managed GPU node pools (public preview) shift that burden to the platform. AKS installs and maintains the NVIDIA driver, the device plugin, the DCGM metrics exporter, and node-problem-detector GPU health signals for you. The DCGM exporter exposes standard Prometheus metrics — DCGM_FI_DEV_GPU_UTIL, DCGM_FI_DEV_GPU_TEMP, memory and ECC counters — on port 19400, labeled with kubernetes.azure.com/dcgm-exporter=enabled.

Creating a Managed GPU Node Pool

# Requires aks-preview extension >= 19.0.0b29 and the
# ManagedGPUExperiencePreview feature flag registered
az extension add --name aks-preview

az feature register --namespace Microsoft.ContainerService \
  --name ManagedGPUExperiencePreview

az aks nodepool add \
  --resource-group rg-aks-ai \
  --cluster-name aks-gpu \
  --name gpupool \
  --node-vm-size Standard_NC40ads_H100_v5 \
  --node-count 2 \
  --enable-managed-gpu true

Wiring DCGM Metrics into Azure Monitor

az aks update \
  --resource-group rg-aks-ai \
  --name aks-gpu \
  --enable-azure-monitor-metrics

With Azure Monitor managed service for Prometheus enabled on the cluster, the DCGM metrics are scraped into your Azure Monitor workspace and become available in Grafana dashboards and PromQL queries — no exporter deployment to maintain. Alerting follows the same path as the rest of your platform signals:

az monitor account create \
  --resource-group rg-monitoring \
  --name amw-aks-alerts

From there, Prometheus-rule alerts (for example on sustained 100% utilization or rising GPU temperature) are defined in the workspace exactly like any other container metric.

Two caveats worth knowing before you plan around preview limitations: managed GPU node pools currently support Linux pools only, and cluster autoscaler is not supported on them during preview — scale these pools manually. Both are typical preview constraints, but they bite real capacity plans, so model them now rather than at cutover.

The Compliance Angle: PDPA and Operational Control

The Personal Data Protection Act 2010 — including the PDPA (Amendment) Act 2024, which passed in 2024, phased in from 1 January 2025, and added mandatory data breach notification obligations (effective 1 June 2025) — is the baseline every Malaysian enterprise handling personal data must design against. The three capabilities above map onto it in concrete ways:

  • Data residency: keeping PDPA-covered workloads on clusters in Malaysia West, with Fleet Manager handling cross-cluster routing for DR, lets you hold residency boundaries without fragmenting operations.
  • Access control and integrity: blue-green upgrades with soak windows mean patching and version upgrades happen without availability gaps — and with an auditable observation point between batches. Combine with Entra-only identity (--disable-local-accounts) for centralized authentication and RBAC.
  • Breach detection: native GPU and cluster metrics flowing into Azure Monitor give your SOC a single pane for anomaly detection and alerting, integrated with Sentinel — which matters now that notification obligations carry real timelines.

I have been building exactly this mapping with Malaysian financial institutions. The combination of fleet-level networking for residency, blue-green upgrades for availability, and Azure Monitor for detection gives auditors something they can actually verify rather than a box-ticking narrative.

Pitfalls I Keep Seeing

  1. Assuming blue-green means zero planning. You still need quota and budget for double node capacity during upgrades, and PDBs still govern drain behavior. A misconfigured PDB can stall a batch until --drain-timeout-bg expires and the upgrade fails.
  2. Treating preview as GA. Cross-cluster networking capabilities and managed GPU pools are at different maturity points. Read the current status of each feature before putting it on a critical path — especially anything feeding a DR commitment.
  3. Forgetting tenant constraints. Fleet member clusters must live in the same Microsoft Entra tenant. Cross-tenant scenarios need a different design.
  4. Self-managed GPU drift. If you stay on the self-managed GPU stack, pin driver and plugin versions and test upgrades deliberately. Version skew between driver and CUDA workloads remains a top incident cause in AI clusters.
  5. Skipping the soak. Shortening --final-soak-duration to zero to save money removes your rollback window. The old nodes are your insurance policy; keep them for at least one full validation cycle.

Key Takeaways

  1. Blue-green node pool upgrades are declarative and tunable. Set --upgrade-strategy BlueGreen and control batch size, soak durations, and drain timeouts per pool — no custom cordon/drain scripting, and a built-in rollback window.
  2. Fleet Manager separates three networking problems. East–west service discovery, public DNS load balancing via Traffic Manager, and intra-VNet MultiClusterService L4 load balancing are distinct primitives — pick the one that matches your traffic pattern.
  3. Managed GPU node pools remove the exporter tax. Driver, device plugin, DCGM metrics exporter, and health signals installed and maintained by AKS; standard DCGM_FI_* Prometheus metrics flow straight into Azure Monitor.
  4. Preview constraints shape capacity plans. No cluster autoscaler on managed GPU pools during preview; Linux-only GPU pools; verify per-feature GA status before wiring into DR.
  5. Build 2026's AI story stands on these foundations. Managed system node pools, bare metal AKS, and model serving all assume you can upgrade safely, connect clusters cleanly, and observe GPUs natively.

Law Wen Feng is a Principal Solution Architect specializing in Azure infrastructure and cloud-native architecture across Southeast Asia. He writes about Azure, Kubernetes, and the intersection of technology and compliance in the region at wenfeng.my.