feat: support Windows node provisioning via the AKS Machine API

[MarcPow]

Description

Enable Karpenter (Azure provider) to provision Windows worker nodes when running in the AKS Machine API provision mode (PROVISION_MODE=aksmachineapi / aksmachineapiheaderbatch). The Karpenter controller continues to run as a Linux pod; only the provisioned worker nodes are Windows. This is the mode AKS ships as managed Node Auto Provisioning (NAP), and the AKS RP / Node Provisioning Service already handles Windows server-side (OSType/OSSKU, AgentPoolWindowsProfile, and admin-credential sourcing from the cluster windowsProfile), so no RP-side changes are required.

Previously every code path was hard-coded to Linux: instance types advertised kubernetes.io/os=linux unconditionally, there was no Windows image family, and the Machine builder always emitted OSType=Linux. As a result the scheduler never matched a Windows pod to any offering and no Windows node was ever created.

What this PR does

Scheduling

• Derive the kubernetes.io/os requirement from the NodeClass image family (new v1beta1.GetOSForImageFamily) instead of hard-coding Linux, so a Windows NodeClass advertises os=windows and the scheduler bin-packs Windows pods.

NodeClass API (v1beta1)

• Add Windows2019, Windows2022, Windows2025, WindowsAnnual image families, each mapped 1:1 to its kubernetes.azure.com/os-sku value, plus a WindowsFamilies set.
• Extend the imageFamily CEL enum, register the Windows os-sku values, and reject FIPS / linuxOSConfig for Windows via CEL. CRD (and Helm CRD copy) regenerated.

Image selection

• New Windows image family returning images from the AKS-managed shared image gallery (AKSWindows), gen2-then-gen1, amd64; SIG-only, no FIPS.
• Include the AKSWindows gallery in FilteredNodeImages (previously filtered to Ubuntu/Azure Linux only, which silently dropped all Windows images).
• Strip the windows- image-definition prefix so the node-image-version matches the AKS form (e.g. AKSWindows-2022-containerd-gen2-<version>).

AKS Machine API provisioning

• Set OSType=Windows and the Windows OSSKU, omit LinuxProfile, force EnableFIPS=false.
• Omit NodeImageVersion for Windows: the RP input parser splits on - and expects gallery-name-version, but Windows names contain hyphens, so an explicit value is rejected; leaving it empty lets the RP resolve the latest image from the OSSKU.
• Generate a short, deterministic, hyphen-free AKS machine name (≤12 chars, leading letter) for Windows to satisfy the NetBIOS computer-name limit enforced by the Machine API. Linux machine-name generation is unchanged.

Hybrid clusters

• Always pin the Karpenter controller Deployment to Linux nodes (kubernetes.io/os=linux), merged with and taking precedence over any user nodeSelector, so the Linux-only controller is never scheduled onto a Windows node in a mixed-OS cluster.

Testing

• Unit tests for the OS/os-sku mapping, the Windows image family and GetImageFamily wiring, Windows node-image-version conversion, OSSKU/OSType selection in the Machine builder, the AKSWindows gallery filter, and the Windows machine-name generator. Full suite green.
• New e2e suite (test/suites/windows) that provisions a Windows node via the Machine API and runs a Windows pod, asserting the node os and os-sku labels. It skips unless running in Machine API mode against the reserved NAP-managed agent pool (the only place usable Windows machine names are allowed). Adds WindowsNodeClass/WindowsNodePool helpers, an az-mkaks-windows cluster target with a windowsProfile, an AKSWindows SIG reader role assignment, and a configurable self-hosted machines-pool name.
• Live validation: the full create path was exercised against a real Windows-capable AKS cluster (Azure CNI overlay + windowsProfile, aksmachineapi, USE_SIG=true). The RP accepted a correct Windows machine (osType=Windows, osSKU=Windows2022, resolved image, zoneless, short name). End-to-end pod-Ready validation requires a NAP-managed cluster, since usable Windows machine names are only allowed in the reserved aksmanagedap pool (which cannot be created in a self-hosted cluster) — hence the suite's skip guard.

Scope & notes

• Targets the AKS Machine API path only; the in-provider bootstrapping paths (aksscriptless/bootstrappingclient) continue to reject Windows.
• Windows is amd64-only by design.
• GPU-on-Windows and Windows-specific max-pods defaults are intentionally left for follow-up.
• No AKS RP changes are required.

[theunrepentantgeek]

First pass review, needs another look from someone more familiar with the codebase.

Both Windows2019 and WindowsAnnual are on their way out (going or already gone), so we can simplify this code by omitting those.

Plus, I have a question about the uniqueness of Windows NetBIOS names - I suspect there's not sufficient entropy to make naming collisions unlikely.

[MarcPow]

@theunrepentantgeek thanks for the thorough review — all of your comments are addressed and the conversations are resolved. Summary:

• Windows2019 + WindowsAnnual removed entirely (enum, CEL, image-family defs, and both regenerated CRDs) — only Windows2022/Windows2025 remain.
• Case-insensitivity: added IsWindowsImageFamily (strings.EqualFold); all family checks route through it.
• Magic strings → constants: OSLinux/OSWindows; GetOSForImageFamily returns those.
• Boolean param → two methods: GetLinuxAKSMachineName / GetWindowsAKSMachineName(maxLen), chosen at the call site.
• Restored %w error wrapping on the node-image-version resolve.
• Doc: applied your DefaultImages() wording.
• Naming entropy: answered inline — the reserved NAP (production) pool gets an 11-char base36 hash (~2^57), far exceeding the NodeClaim's ~28-bit input entropy, so it's collision-free at any realistic scale; the short custom-pool budget is test-scoped (gated to pool names ≤ 6 chars).
• new(expr) Go 1.26 tip noted; kept lo.ToPtr for codebase consistency for now.

Follow-up beyond the review (worth a look):

• Found that for Windows2022 the RP defaults to a Gen1 image and only picks Gen2 when the caller sends UseWindowsGen2VM. Since NAP often selects Gen2-only SKUs, Karpenter now sends that header when the selected SKU supports Gen2 — so Windows provisions on any SKU generation. Validated end-to-end self-hosted on a Gen2-only SKU (Standard_D2als_v7) that previously failed.
• Added a separate commit wiring the Windows e2e suite into the CI matrix on a dedicated (non-Cilium) az-mkaks-windows cluster in machine-API mode.

Re-requesting review when you have a moment. 🙏