AKS and Near-Bare-Metal Workloads: What Platform Teams Can Responsibly Plan For Azure Kubernetes Service (AKS) offers partial support for near-bare-metal workloads through isolated VM SKUs, but platform teams must validate SKU availability and feature compatibility before committing. AKS's node health management and upgrade behavior remain unchanged for specialty node pools, requiring re-evaluation of auto-repair and upgrade assumptions due to constrained capacity for isolated VM families. 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 fundamentals12but 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. 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: NEEDS VALIDATION for specific feature compatibility with AKS CNI configurations What you do NOT automatically get: That last point is where platform teams usually get surprised. AKS manages node health and upgrades at the node pool level1. 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: terminationGracePeriodSeconds reflects that. NEEDS VALIDATION — check AKS release notes for your target SKU family.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 practice1 and applies regardless of whether the specialty pool is "bare-metal adjacent" or not. The pattern: 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