Most government IT shops run workloads in more than one place. One application runs in an Azure region. Another runs on servers in a traffic operations center, a water treatment facility, or a county data center, because the data it processes has to stay in that building or the latency to the cloud is too high. Until now, the usual Kubernetes answer was to build another cluster in each location. Each one brings its own control plane, upgrade cycle, identity setup, and policy drift.

On September 22, 2026, the AKS team announced the public preview of flex nodes for AKS. Flex nodes let you join customer-managed virtual machines and bare metal hosts to an existing AKS cluster as worker nodes. That includes hosts in other Azure regions, on-premises, or at the edge. The control plane stays in Azure and is managed by Microsoft. The compute runs wherever you need it.

This post explains how the feature works, where it fits next to Azure Arc-enabled Kubernetes and AKS on Azure Local, how to onboard a node and control scheduling from the CLI, and what to check before you plan around it in Azure Government.

Preview status: According to the flex nodes overview on Microsoft Learn (updated September 2026), flex nodes are an AKS preview feature. They are not covered by an SLA and are “not meant for production use.” Use them for evaluation, pilots, and labs.

Architecture: How Flex Nodes Work

The overview documentation describes five components:

The agent runs the Kubernetes worker inside an isolated environment on the host. The project README describes it as a systemd-nspawn machine. Because of this, AKS can upgrade or reset the node without reimaging the physical server. The agent supports amd64 and arm64 hosts and detects NVIDIA GPUs automatically, configuring the container runtime for accelerated workloads.

Identity

AKS didn’t provision these hosts, so each one needs a verifiable identity. The identity and access concepts article lists three options:

• Azure Arc managed identity: for on-premises servers that are already Arc-enabled. It is secretless, which makes it the strongest option for most facility servers.
• System- or user-assigned managed identity: for flex nodes that are Azure VMs, for example capacity in another region.
• Service principal: for any other host. Microsoft recommends a certificate credential over a client secret.

Whichever option you choose, the identity is granted the Azure Kubernetes Service Contributor Role scoped to that one cluster, not the whole subscription. That limits what a compromised host identity can reach.

Networking: Bring Your Own

This is the most important design point for the preview. Per the networking concepts article, AKS-managed network plugins (Azure CNI and Azure CNI Powered by Cilium) don’t run on flex nodes during public preview. You can attach flex nodes to a cluster that uses those plugins, but their pod networking and network policy capabilities won’t extend to the flex nodes.

The documented path creates the cluster with --network-plugin none and installs Unbounded-Net on both AKS nodes and flex nodes. Unbounded-Net models each location as a Site with its own node and pod CIDRs, then routes pod traffic between Sites. The underlying Layer 3 path is your responsibility. The planning guide lists the options:

• VNet peering: for flex hosts in other Azure regions
• Site-to-site VPN Gateway: for on-premises facilities
• ExpressRoute: for agencies with dedicated private connectivity
• Unbounded-Net WireGuard gateway: an alternative topology, covered in the GitHub labs, for when no private routed path exists

Plan non-overlapping ranges for AKS nodes, AKS pods, flex nodes, flex pods, and Kubernetes services. The AKS control plane also needs a path back to each flex node’s kubelet so that kubectl logs, exec, and port-forward work.

Flex Nodes vs. Arc-Enabled Kubernetes vs. AKS on Azure Local

These three options solve different problems, and you can use them together.

Arc-enabled Kubernetes gives you inventory, GitOps (Flux v2 or Argo CD), Azure Policy, Azure Monitor, and Microsoft Defender for Containers across clusters that run anywhere. AKS on Azure Local runs the control plane locally through a management appliance. The AKS platform comparison is a useful side-by-side reference.

Here is a practical way to decide. If the site must keep scheduling and self-healing workloads during a WAN outage, keep the control plane local with AKS on Azure Local. If the site has reliable connectivity and you mainly want a few workloads to run next to the data without another cluster to maintain, flex nodes remove a lot of operational overhead.

CLI Walkthrough: Onboarding a Flex Node

The commands below come from the Microsoft Learn deployment series. They are shortened here, so follow the full articles for the environment file and validation steps.

1. Install the preview extension and register features

From Prepare an AKS cluster for flex nodes. The minimum aks-preview version is 22.0.0b8. The docs also say you need a subscription that is approved for the preview.

1
2
3
4
5

az extension add --name aks-preview --allow-preview true --upgrade

az feature register --namespace Microsoft.ContainerService --name AKSFlexNodePreview
az feature register --namespace Microsoft.ContainerService --name PutMachinePreview
az provider register --namespace Microsoft.ContainerService --wait

2. Create the cluster without a built-in network plugin

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

az aks create \
  --resource-group "${RESOURCE_GROUP}" \
  --name "${CLUSTER_NAME}" \
  --location "${LOCATION}" \
  --kubernetes-version "${AKS_VERSION}" \
  --nodepool-name systempool \
  --node-count 1 \
  --node-vm-size "${AKS_NODE_VM_SIZE}" \
  --network-plugin none \
  --pod-cidr "${AKS_POD_CIDR}" \
  --vnet-subnet-id "${AKS_SUBNET_ID}" \
  --service-cidr "${SERVICE_CIDR}" \
  --dns-service-ip "${DNS_SERVICE_IP}" \
  --enable-managed-identity \
  --ssh-access disabled --no-ssh-key

For a private API server, add --enable-private-cluster --disable-public-fqdn --private-dns-zone system. Your facility network must then be able to resolve and reach the private endpoint, for example through Azure DNS Private Resolver over VPN or ExpressRoute.

3. Install Unbounded-Net and define the Sites

From Configure networking and create a flex node pool:

1
2
3
4
5
6
7
8

kubectl unbounded install --timeout 5m

kubectl unbounded site init \
  --name flex-site \
  --cluster-node-cidr "${AKS_NODE_CIDR}" \
  --cluster-pod-cidr "${AKS_POD_CIDR}" \
  --node-cidr "${FLEX_NODE_CIDR}" \
  --pod-cidr "${FLEX_POD_CIDR}"

Then apply a SitePeering (apiVersion: net.unbounded-cloud.io/v1alpha1) that lists the cluster and flex-site Sites with meshNodes: true.

4. Create a flex node pool with a protective taint

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

az aks nodepool add \
  --resource-group "${RESOURCE_GROUP}" \
  --cluster-name "${CLUSTER_NAME}" \
  --name "${FLEX_POOL_NAME}" \
  --vm-set-type FlexNodes \
  --mode User \
  --kubernetes-version "${AKS_VERSION}" \
  --max-pods 75 \
  --max-unavailable 1 \
  --labels site=traffic-ops \
  --node-taints site=traffic-ops:NoSchedule

The --vm-set-type FlexNodes flag is what makes this a flex pool. The taint means only workloads that explicitly tolerate it can land on facility hardware.

5. Grant the host identity and bootstrap the host

From Prepare a flex node host and identity, grant the role at cluster scope:

1
2
3
4
5

az role assignment create \
  --assignee-object-id "${HOST_PRINCIPAL_OBJECT_ID}" \
  --assignee-principal-type ServicePrincipal \
  --role "Azure Kubernetes Service Contributor Role" \
  --scope "${AKS_RESOURCE_ID}"

The host needs Ubuntu 24.04 LTS or Azure Linux 3, at least 4 vCPUs, and 8 GiB free under /var/lib. For an Arc-enabled server, Attach a flex node to an AKS cluster runs the version-matched bootstrap script as root, after you download the release archive and verify its checksum:

1
2
3
4
5
6
7
8

bash /tmp/bootstrap.sh \
  --auth arc \
  --fetch-bootstrap-data \
  --cluster-resource-id "${AKS_RESOURCE_ID}" \
  --agent-pool-name "${FLEX_POOL_NAME}" \
  --agent-url "file:///tmp/${AGENT_ARCHIVE}" \
  --agent-sha256 "${AGENT_SHA256}" \
  --config-overrides "${CONFIG_OVERRIDES}"

For managed identity or service principal paths, you first run az aks nodepool get-bootstrap-data from your workstation. The bootstrap token it returns expires after one hour.

Scheduling Data-Sensitive and AI Inference Workloads

Once the node joins, workload placement uses ordinary Kubernetes primitives. The management article shows that every flex node carries the label kubernetes.azure.com/nodepool-type=FlexNodes. You can add site-specific labels per machine:

1
2
3
4
5
6
7

az aks machine update \
  --resource-group "${RESOURCE_GROUP}" \
  --cluster-name "${CLUSTER_NAME}" \
  --nodepool-name "${FLEX_POOL_NAME}" \
  --machine-name "${FLEX_MACHINE_NAME}" \
  --labels site=traffic-ops data-class=local-only \
  --node-taints site=traffic-ops:NoSchedule

This command replaces the labels and taints it manages, so include every value you want the machine to keep. Next, pin an inference service that processes raw roadway sensor or camera feeds to that hardware:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

apiVersion: apps/v1
kind: Deployment
metadata:
  name: intersection-inference
spec:
  replicas: 1
  selector:
    matchLabels: { app: intersection-inference }
  template:
    metadata:
      labels: { app: intersection-inference }
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: kubernetes.azure.com/nodepool-type
                operator: In
                values: ["FlexNodes"]
              - key: data-class
                operator: In
                values: ["local-only"]
      tolerations:
      - key: site
        operator: Equal
        value: traffic-ops
        effect: NoSchedule
      containers:
      - name: model-server
        image: <your-registry>/intersection-model:1.0

This gives you a clean split:

• At the facility: high-volume raw data, such as video frames, sensor telemetry, or building management system signals, is processed where it is created. Only derived results, like counts, anomaly events, or occupancy summaries, leave the building.
• In Azure: dashboards, APIs, model training, and storage of aggregated results run on standard node pools with Azure CNI, autoscaling, and zone redundancy.

For GPU inference, the agent’s NVIDIA detection prepares the container runtime. Validate in your lab how GPUs are advertised to the scheduler, for example with a device plugin, before you write nvidia.com/gpu requests into manifests. If a site needs full local autonomy for inference, the AKS team’s September 2026 AI Inference on AKS enabled by Azure Arc series covers that pattern.

Operational guardrails

• A flex node can’t run a Kubernetes version newer than the control plane. Upgrade the control plane first with az aks upgrade --control-plane-only, then test one machine, then run az aks nodepool upgrade.
• You can’t stop a cluster that contains a flex node pool, and the Azure portal can’t create or manage flex pools (support policy).
• You own the host OS, patching, firmware, routing, firewalls, and Unbounded-Net lifecycle. Microsoft owns the control plane and the flex node integration.

Azure Commercial vs. Azure Government: What to Check

As of this writing, the flex nodes Learn documentation (September 2026) does not state availability in Azure Government. The walkthroughs assume the commercial cloud; for example, the rendered agent configuration uses https://management.azure.com as the Resource Manager endpoint. Azure Government uses different endpoints, such as management.usgovcloudapi.net for ARM and login.microsoftonline.us for Entra ID, as listed in Compare Azure Government and global Azure. Don’t assume that editing an endpoint makes an unsupported configuration work.

Before you plan a Government-cloud pilot:

1
2
3

az cloud set --name AzureUSGovernment
az login
az feature show --namespace Microsoft.ContainerService --name AKSFlexNodePreview --query properties.state

Also check Products available by region, confirm with your Microsoft account team, and watch the AKSFlexNode releases. Agent v0.2.0 shipped in September 2026. For workloads that must stay in Azure Government today, AKS in Azure Government, Arc-enabled Kubernetes, or AKS on Azure Local are the established options. A commercial-cloud flex node lab is a low-risk way to test the architecture in the meantime.

Why This Matters for Government

For CxOs: Flex nodes offer one Kubernetes operating model across the cloud and your own buildings. Agencies can put existing on-premises servers to work, keep regulated data physically local, and avoid paying for extra control planes, upgrade cycles, and separate policy baselines. The AKS team named the public sector explicitly as a data-residency scenario in the September 2026 announcement.

For IT leaders and platform engineers: You get one kubectl context, one RBAC model, and one upgrade path through AKS APIs. Placement uses the node affinity and taints your teams already know. Secretless Arc identities scoped to a single cluster fit zero-trust programs. The shared-responsibility boundaries are documented clearly.

For developers: An inference service for a transportation, public works, or facilities use case deploys with the same manifest style and CI/CD pipeline as the rest of the application. Only a node selector and a toleration change.

Recommended next step: Build a lab in Azure Commercial with an Arc-enabled server in a non-production facility, connected over your existing site-to-site VPN. Validate DNS, kubelet callbacks, cross-Site pod traffic, and upgrade behavior. Record what you learn, and send feedback through the AKSFlexNode issue tracker so the product can mature around public-sector requirements before general availability.