Why GPU Requests Must Equal Limits

Why this matters

For CPU and memory, Kubernetes lets you set requests (the guaranteed minimum) separately from limits (the ceiling), and the gap between them drives bin-packing and overcommit. GPUs break that model: because they are an extended resource, request and limit must be equal, and you effectively only set limits. Builders who carry their CPU intuition over to GPUs write specs that get rejected or, subtly, end up requesting more than they meant. Knowing that GPUs are an all-or-nothing, request-equals-limit resource is what keeps your QoS class and your scheduling predictable.

Demo

Try to set a GPU request smaller than its limit and the API server rejects it. Extended resources require request == limit, which also pins GPU pods to the Guaranteed QoS class.

Try it yourself

1. Apply the bad spec and read the exact API server rejection message about requests equaling limits.
2. Apply the good spec and confirm with kubectl get pod -o yaml that requests.nvidia.com/gpu was auto-populated to match limits.
3. Check the pod's QoS class with kubectl describe and confirm it is Guaranteed.
4. Reason about why you cannot overcommit GPUs the way you overcommit CPU by setting requests below limits.

References

• Kubernetes — Resource management (extended resources)
• Kubernetes — Schedule GPUs