AKS Flex Nodes add a node pool type for machines Azure doesn't provision
The Azure Updates listing, titled "Public Preview: Flex Nodes for AKS," is sparse. The item page doesn't render its details publicly. Other first-party records back up the announcement and its date, though. A pull request in Microsoft's Azure/AKS GitHub repository adds a new AKS blog post announcing the public preview of flex nodes, and the post's file path is dated 2026-09-22. Microsoft's Azure CLI reference also already lists an az aks nodepool get-bootstrap-data command, described as a way to "get bootstrap data for a FlexNodes pool," which ships in the aks-preview extension.
The clearest description of the feature comes from the Azure-maintained AKSFlexNode repository on GitHub. It says the project extends Azure Kubernetes Service (AKS) to customer-managed virtual machines and bare metal hosts, enabling them to run as AKS worker nodes outside standard AKS node pools. The project is built on top of Azure Unbounded, which provides the host-side foundation for running and reconciling isolated Kubernetes node environments.
Here's how that differs from normal AKS. Today, az aks nodepool add creates Azure compute for you, either Virtual Machine Scale Sets or individual VMs of a size you pick, with an OS SKU Azure supplies. A Flex Nodes pool reverses that. You bring the machine, and AKS supplies the join process and the cluster membership.
Hybrid, lab, and GPU hardware are the target cases for Flex Nodes
The repository names the intended uses plainly. Flex Nodes are meant to bootstrap and join virtual machines or bare metal hosts for both amd64 and arm64 as AKS worker nodes and support hybrid, lab, and specialized hardware scenarios.
The feature list goes further than a join script. The project says Flex Nodes automatically detect NVIDIA GPU devices and configure the container runtime for accelerated workloads. It also claims lifecycle support. You can run blue-green in-place updates and upgrades while retaining the existing host, and manage your Flex Node fleet through AKS management APIs for upgrade, repair, reset, and related lifecycle operations. These are the project's descriptions of what it is building. WindowsForum has not tested them.
My read on the positioning: the GPU and lifecycle features are the real pitch. Joining an outside Linux box to a Kubernetes control plane has long been possible by hand. What Microsoft adds is the promise that the AKS management plane can upgrade and repair those machines alongside ordinary nodes. The main candidates are organizations with GPU servers they already own, arm64 hardware, or on-premises capacity they want scheduled from a single AKS cluster.
Don't confuse this with a separate Azure project called AKS Flex. That project describes a way to extend an Azure Kubernetes Service (AKS) cluster with nodes from external cloud providers or on-premises infrastructure, using remote nodes that join the AKS control plane over an encrypted overlay network. It has its own CLI and autoscaler. The names overlap, but the Azure Updates preview covers Flex Nodes.
Identity options for Flex Nodes: Azure Arc, managed identity, and bootstrap tokens
A machine outside Azure's fabric has to prove who it is before the cluster trusts it. The repository says Flex Nodes can use flexible authentication modes, including Azure Arc, managed identity (MSI), and Kubernetes bootstrap token. The quickstart's configuration generator also accepts a service principal. Each option fits a different kind of machine:
- An Azure VM you manage yourself can use a managed identity.
- An on-premises server already enrolled in Azure Arc can reuse that Arc identity.
- A lab machine with no Azure identity can use a Kubernetes bootstrap token, which is the route the repository's quickstart walks through.
The quickstart's generated configuration file shows what a Flex Node needs to know about its cluster: the subscription and tenant IDs, the target agent pool name, the AKS resource ID and region, the API server FQDN and certificate data, the cluster DNS service IP, and the Kubernetes component version. That file contains credentials, and the maintainers treat it that way. A current documentation-refresh issue in the repository sets the rule: don't log or print credentials, bootstrap data, kubeconfig content, private keys, or signed URLs.
Networking is the prerequisite most likely to block a Flex Nodes pilot
Most of the work in a Flex Nodes pilot is networking. The node has to reach the cluster's control plane, and a private cluster makes that harder. The repository says that for private AKS clusters, the Flex Node machine can resolve and reach the private API server endpoint. It adds that on-premises machines usually reach the cluster's private node network through a site-to-site VPN, ExpressRoute, or equivalent routed connectivity. Establishing that link is a prerequisite for this quickstart.
For more complex designs the project sends operators to hands-on lab guides: for advanced network scenarios such as cross-region, gateway, or custom CNI topologies, follow the lab guides. The quickstart also says the cluster needs preparing first, covering a FlexNodes pool, Unbounded networking, identity, RBAC, and node registration, before any machine can join.
In practice, then, the ten-minute join the repository advertises only starts once the routing, DNS resolution for the API server, and role assignments are in place. For an on-premises server that means a working VPN or ExpressRoute path into the cluster's network. Plan the network work first.
The Flex Nodes preview workflow is still settling
Two status labels are in play, and they describe different things. Azure Updates calls Flex Nodes a public preview. The GitHub repository's README says AKS Flex Node is currently alpha software. The first describes the Azure product offering. The second describes the open-source agent's maturity. Neither changes the preview's terms. Both point toward caution.
The repository's documentation is also mid-rewrite. An open issue plans to align the repo's customer journey, terminology, feature scope, and operational guidance with Flex Nodes documentation planned for Microsoft Learn. Its acceptance criteria include that the README and operator prerequisites no longer conflict, which suggests they currently do in places. A draft pull request in that series shows the direction of the supported path. It would add AKSFlexNodePreview registration and preview Azure CLI extension setup, replace raw FlexNodes pool creation with az aks nodepool add --vm-set-type FlexNodes, and verify Azure Machine registration with az aks machine list. The same draft describes testing live Flex node pool creation with Azure CLI 2.90.0, aks-preview 22.0.0b8, and AKS 1.36.2.
That draft is unmerged, and those versions come from one engineer's validation run, not a published support matrix. Still, it points to a familiar AKS preview pattern: register a subscription feature flag, install the aks-preview CLI extension, then create a pool with a new --vm-set-type value. When Microsoft Learn publishes the Flex Nodes articles, treat their procedure as authoritative over the older repository quickstart.
On the host side, the most recent tagged agent release, v0.2.0, gives quick-install instructions for Ubuntu 22.04 and 24.04 and tells operators to verify downloads against its published checksums. That is the only host OS guidance found in the evidence, so don't assume other distributions or Windows hosts are supported.
Standard AKS preview terms apply to Flex Nodes
Microsoft hasn't published Flex Nodes-specific support terms beyond the preview label. AKS's general preview policy therefore applies. Per Microsoft's AKS documentation, AKS preview features are available on a self-service, opt-in basis. Previews are provided "as is" and "as available," and they're excluded from the service-level agreements and limited warranty. They are partially covered by customer support on a best-effort basis. As such, these features aren't meant for production use.
Pricing, supported regions, and whether a customer-managed node counts against AKS node limits aren't stated in any record found. If your business case depends on the cost of running workloads on hardware you already paid for, that gap matters, and you should settle it with Microsoft before planning past a pilot.
What this means for AKS operators with on-premises or GPU hardware
Pilot Flex Nodes if you run AKS and have hardware sitting outside it: GPU servers, arm64 machines, or on-premises capacity you would rather schedule from a single cluster than run as a separate Kubernetes distribution. Use a non-production cluster, and put in the network work first. If all your workloads run happily on Azure-provisioned node pools, you can wait. The preview gives you nothing new until you need to bring your own machine.
- Flex Nodes for AKS entered public preview on September 22, 2026. It lets customer-managed VMs and bare-metal hosts join an AKS cluster as worker nodes.
- Standard AKS preview terms apply: no SLA, best-effort support, and not for production workloads.
- The open-source AKSFlexNode agent is still labeled alpha, and its documentation is being rewritten to match planned Microsoft Learn guidance. Expect the onboarding steps to change.
- On-premises nodes need routed connectivity to the cluster, such as a site-to-site VPN or ExpressRoute, plus DNS resolution of the API server for private clusters, before they can join.
- Choose an identity path to match the machine: Azure Arc for Arc-enrolled servers, managed identity for Azure VMs, or bootstrap tokens and service principals for everything else. Treat the generated node configuration file as a secret.
- Before building a business case, confirm pricing, regional availability, and host OS support with Microsoft. The only host guidance published so far is the agent's Ubuntu 22.04/24.04 install path.
Flex Nodes is Microsoft's move to make AKS the control plane for compute Azure doesn't own. The design already covers identity, GPU detection, and lifecycle operations, and the CLI already has FlexNodes plumbing. The next milestone is the Microsoft Learn documentation now being drafted. Once it's published, the feature-flag registration and the --vm-set-type FlexNodes pool creation become the documented preview path, and operators get a firmer base for testing than the alpha repository offers today.