[Feature] Helm Chart for Kubernetes GPU Fleet Deployment

[mitulgarg]

Summary

Add a Helm chart that deploys env-doctor as a DaemonSet on GPU-labeled Kubernetes nodes, automating the report install step across an entire cluster with a single command.

Motivation

Teams running GPU fleets on Kubernetes (GKE, EKS, AKS, bare-metal k8s) currently need to SSH into each node individually to run:

pip install env-doctor
env-doctor report install --url http://<dashboard>:8765 --interval 5m

For clusters with 20–100+ GPU nodes, this is tedious and error-prone. A Helm chart reduces this to:

helm install env-doctor ./charts/env-doctor \
  --set dashboard.url=http://<dashboard>:8765 \
  --set interval=5m

New GPU nodes joining the cluster would automatically pick up env-doctor — no manual intervention.

Scope

This is a packaging/distribution change only. No changes to the core CLI, dashboard, or reporting logic.

What the chart would contain

• A DaemonSet targeting nodes with nvidia.com/gpu labels
• A lightweight container that runs env-doctor report install on startup
• Host mounts for GPU driver access (nvidia-smi, device files)
• Configurable values: dashboard URL, reporting interval, image tag

Configurable values (values.yaml)

dashboard:
  url: ""            # required: http://<dashboard-host>:8765
reporting:
  interval: "5m"     # maps to --interval flag
nodeSelector:
  nvidia.com/gpu: "true"
image:
  repository: ghcr.io/mitulgarg/env-doctor
  tag: latest

What this does NOT change

• Reporting behavior (hash-based change detection, heartbeat — all unchanged)
• Dashboard backend or API
• Core CLI functionality
• Non-k8s deployment paths (cron/Task Scheduler still work as-is)

Acceptance criteria

• helm install deploys env-doctor to all GPU nodes in a cluster
• Nodes report to the dashboard using existing --report-to flow
• New GPU nodes auto-enroll when they join the cluster
• helm uninstall cleanly removes the DaemonSet
• README documents the 3-command setup (add repo → configure → install)

[mitulgarg]

Why it's not a priority

1. The existing flow already works for k8s users
   env-doctor report install with cron handles the same job. The only difference is one SSH + two commands per node vs. one Helm command for the whole cluster. For teams with 5–20 GPU nodes, this is a minor convenience, not a blocker.
2. Zero users have asked for it
   No issues, discussions, or feedback requesting k8s-native deployment. Building it now would be speculative — we'd be packaging a feature for a user that hasn't shown up yet.
3. It's pure packaging, not product value
   The Helm chart adds no new functionality. It doesn't improve diagnostics, doesn't add checks, doesn't make the dashboard better. It just changes how env-doctor gets installed on nodes. That's valuable at scale, but it's not where our effort compounds right now.
4. It's fast to build when needed
   Estimated effort: 1–2 days. A DaemonSet manifest, a values.yaml, host mounts for nvidia-smi, and a README. This can be built reactively when an enterprise prospect or community member asks for it, without delaying them meaningfully.
   What we're prioritizing instead

Telemetry API and compatibility knowledge graph (the actual moat)
MCP ecosystem integration and agent-tool distribution
Enterprise features: fleet policy enforcement, drift alerts, audit logs
Core CLI improvements based on existing user feedback

When to revisit

A user or prospect explicitly requests k8s-native deployment
We engage with an enterprise team running 50+ GPU nodes on k8s
The Helm chart becomes a blocker in a sales or adoption conversation

At that point, it's a weekend of work to ship. Until then, the issue stays open and labeled priority: low.