{"slug": "aks-and-near-bare-metal-workloads-what-platform-teams-can-responsibly-plan-for", "title": "AKS and Near-Bare-Metal Workloads: What Platform Teams Can Responsibly Plan For", "summary": "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.", "body_md": "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?\"\n\nThe 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.\n\nA 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`\n\nthroughout. Everything else is grounded in general AKS behavior that is broadly consistent across the platform.\n\nAKS 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.\n\nAzure 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`\n\n— check the current AKS supported VM sizes documentation for your target region before designing around a specific SKU.\n\nWhat you get with isolated or near-bare-metal SKUs, if available:\n\n`NEEDS_VALIDATION`\n\nfor specific feature compatibility with AKS CNI configurations)What you do NOT automatically get:\n\nThat last point is where platform teams usually get surprised.\n\nAKS 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.\n\nThe practical consequence: **your cluster auto-repair and upgrade assumptions need re-evaluation for specialty node pools.**\n\nFor 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:\n\n`terminationGracePeriodSeconds`\n\nreflects that.`NEEDS_VALIDATION`\n\n— 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.\n\nThe pattern:\n\nHere's a minimal node pool configuration pattern for a tainted specialty pool:\n\n```\n# Create a specialty node pool with a taint to prevent accidental scheduling\n# Replace <SKU_NAME> with your validated target SKU\naz aks nodepool add \\\n  --resource-group myRG \\\n  --cluster-name myCluster \\\n  --name specialtypool \\\n  --node-vm-size <SKU_NAME> \\ # NEEDS_VALIDATION: confirm SKU is AKS-supported\n  --node-count 2 \\\n  --node-taints workload-class=hardware-intensive:NoSchedule \\\n  --labels workload-class=hardware-intensive \\\n  --zones 1 2 3\n```\n\nAnd the corresponding pod spec side:\n\n```\napiVersion: v1\nkind: Pod\nmetadata:\n  name: hardware-sensitive-workload\nspec:\n  tolerations:\n    - key: \"workload-class\"\n      operator: \"Equal\"\n      value: \"hardware-intensive\"\n      effect: \"NoSchedule\"\n  nodeSelector:\n    workload-class: hardware-intensive\n  containers:\n    - name: app\n      image: your-registry/your-image # pin your digest, don't use latest\n      resources:\n        requests:\n          cpu: \"8\"\n          memory: \"32Gi\"\n        limits:\n          cpu: \"8\"\n          memory: \"32Gi\"\n```\n\n**Validate SKU availability in your target region.** Run `az vm list-skus --location <region> --size <sku-prefix> --output table`\n\nand cross-reference against the AKS supported VM sizes list. Do not assume a SKU that works for standalone VMs is available for AKS node pools.\n\n**Check current AKS release notes for the SKU family.** Look specifically for known issues with node auto-repair, OS image compatibility, or accelerated networking feature support. `NEEDS_VALIDATION`\n\n— this is release-cadence dependent.\n\n**Model your capacity headroom.** For upgrade surge and auto-repair replacement, you need available quota *and* available physical capacity. For isolated SKUs, physical capacity is the harder constraint. File a support ticket to confirm capacity commitments if the workload is business-critical.\n\n**Test node pool upgrade behavior in a non-production cluster first.** Don't discover that your specialty SKU has zero surge capacity during a production Kubernetes version upgrade. The upgrade series we've covered previously (#50 is the most current approved version) gives you the tooling — apply the same runbook to a test specialty pool before you need it for real.\n\n**Define your eviction and rescheduling strategy.** If a node is auto-repaired and the replacement takes longer than expected (capacity contention), what happens to your workload? PodDisruptionBudgets should reflect the actual tolerance of the workload, not the default.\n\n**Align with your golden path guardrails.** If your platform has golden path templates (covered in #25), specialty node pools should either be an explicit supported variant or explicitly out-of-scope. The worst outcome is an undocumented workaround that every team discovers independently and implements differently.\n\nAKS can host workloads on VM SKUs designed to reduce virtualization overhead and provide single-tenant hardware access. The exact SKUs available, their compatibility with specific AKS networking and acceleration features, and their behavior under node lifecycle operations all require validation against current documentation before you commit. `NEEDS_VALIDATION`\n\non the specifics is not a cop-out — it's the difference between a platform that works and a platform that works until it doesn't.\n\nWhat you *can* design now: isolation strategy, taint/toleration patterns, upgrade runbooks, and capacity planning processes. Get those right and the hardware specifics slot in cleanly once validated.\n\n``` php\nflowchart TD\n    A[Platform Team Evaluation] --> B{Workload Requirements}\n    B --> C[Standard Latency\\nGeneral Purpose VMs]\n    B --> D[Low Latency / Hardware Intensive\\nSpecialty VM SKUs]\n    D --> E[Validate SKU Availability\\nby Region]\n    E --> F[Dedicated Node Pool\\nIsolation Strategy]\n    F --> G[Review Auto-Repair &\\nOS Upgrade Behavior]\n    G --> H[Node Pool Taints & Tolerations\\nfor Workload Scheduling]\n    C --> H\n    H --> I[Mixed Cluster:\\nStandard + Specialty Pools]\n    I --> J[Ongoing: Monitor AKS\\nRelease Notes & SKU Docs]\n```\n\n", "url": "https://wpnews.pro/news/aks-and-near-bare-metal-workloads-what-platform-teams-can-responsibly-plan-for", "canonical_source": "https://dev.to/sathpal_singh/aks-and-near-bare-metal-workloads-what-platform-teams-can-responsibly-plan-for-5927", "published_at": "2026-07-23 16:55:32+00:00", "updated_at": "2026-07-23 17:04:13.235868+00:00", "lang": "en", "topics": ["developer-tools", "ai-infrastructure"], "entities": ["Azure Kubernetes Service", "AKS", "Azure"], "alternates": {"html": "https://wpnews.pro/news/aks-and-near-bare-metal-workloads-what-platform-teams-can-responsibly-plan-for", "markdown": "https://wpnews.pro/news/aks-and-near-bare-metal-workloads-what-platform-teams-can-responsibly-plan-for.md", "text": "https://wpnews.pro/news/aks-and-near-bare-metal-workloads-what-platform-teams-can-responsibly-plan-for.txt", "jsonld": "https://wpnews.pro/news/aks-and-near-bare-metal-workloads-what-platform-teams-can-responsibly-plan-for.jsonld"}}