[Feature] Optional operator-level policy to require explicit GPU resource requests
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 2.9k
- Forks
- 552
- Avg merge
- 2d 4h
- Merged PRs (30d)
- 90
Description
Motivation
In some cluster environments, administrators want to enforce a strict policy where workloads must explicitly request GPU resources (e.g. nvidia.com/gpu) in order to gain access to GPUs on a node.
Today, it is possible for containers to access GPUs indirectly (for example via environment variables or runtime configuration) without passing through device plugin allocation, which can make it difficult to enforce cluster-wide GPU usage policies.
Scope
This request is intentionally scoped to the GPU Operator rather than the Kubernetes device plugin.
Since containers that do not explicitly request GPU resources do not pass through device plugin allocation, enforcement at the device-plugin level is not feasible. However, the GPU Operator is well-positioned to provide optional, cluster-level policy and validation mechanisms before GPU workloads are admitted or configured.
Proposed Behavior
Introduce an optional, opt-in policy at the GPU Operator level that enforces explicit GPU resource requests.
When enabled, the operator would prevent or warn against configurations where workloads gain access to GPUs without explicitly requesting nvidia.com/gpu, for example via environment variables or runtime configuration.
This behavior would be disabled by default and only activated when explicitly configured by the cluster administrator.
Non-Goals
-
This proposal does not attempt to block or modify low-level GPU access mechanisms outside the scope of the GPU Operator (e.g., direct runtime configuration or container toolkit behavior).
-
This proposal does not change default GPU exposure behavior unless the feature is explicitly enabled by a cluster administrator.
-
This proposal does not introduce enforcement at the Kubernetes device plugin level.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
The issue names no files, tests, or entry points. Start by locating the GPU Operator's workload admission and configuration paths, then determine where an opt-in policy could inspect explicit nvidia.com/gpu requests. Done means the policy behavior, default-off configuration, warning or blocking semantics, and coverage for indirect GPU access are specified and tested.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, kubernetes
- Domain
- devops, infrastructure
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100