GPU device-plugin applied via imperative kubectl (outside Helm)

[shujaatTracebloc]

Found by the post-incident installer/chart audit (first-install, minor).

Problem

scripts/install-k8s.ps1:2490 applies the GPU device plugin via imperative kubectl apply (outside Helm). Not a restart break (the object persists in etcd), but it isn't Helm-managed: it would linger through a helm uninstall and is re-created on installer re-run.

Proposed fix

Render the GPU device plugin as a chart template gated on a gpu.enabled value so it's part of the release lifecycle.

Severity: Tier 3 — hygiene. Confidence: CONFIRMED.

[shujaatTracebloc]

This is now stale on the path that matters — flagging rather than closing, since re-scoping is the owner's call.

Since #633 the Windows GPU route is CDI + a baked-in nvidia RuntimeClass, not the NVML device plugin. The reason is that nvmlInit fails on WSL2, so the plugin registered 0 GPUs and then pinned the extended resource at 0. The installer now deletes a leftover nvidia-device-plugin-daemonset as cleanup, and advertises nvidia.com/gpu itself via a node-status patch.

Concretely, against the current file:

• The line this issue cites, scripts/install-k8s.ps1:2490, no longer contains the apply — the reference is stale.
• grep for a device-plugin kubectl apply finds it only in the non-WSL2 else fallback (~:3504, pinned to k8s-device-plugin/v0.14.5), reached when /dev/dxg is absent. A normal Windows/WSL2 install with Docker Desktop never takes that branch.

So the concern is still real, but its blast radius is now the fallback branch only, which is why I'd suggest re-scoping rather than leaving it as-is:

1. Update the title/body to say non-WSL2 fallback, and fix the line reference.
2. Keep the Tier-3 hygiene severity — the object still lingers through a helm uninstall and is re-created on re-run, exactly as described.
3. Worth noting while it's open: that branch downloads the manifest from raw.githubusercontent.com at install time, so it's also a network dependency in the install path, not just a Helm-lifecycle wart. Rendering it as a chart template gated on gpu.enabled — the proposed fix — removes both.

No code change from me here; I only verified the premise while auditing what's left on the Windows install path.