Code change:
// Check that request <= limit. limitQuantity, exists := requirements.Limits[resourceName] if exists { <del> // For GPUs, not only requests can't exceed limits, they also can't be lower, i.e. must be equal. </del> <ins> // For non overcommitable resources, not only requests can't exceed limits, they also can't be lower, i.e. must be equal. </ins> if quantity.Cmp(limitQuantity) != 0 && !helper.IsOvercommitAllowed(resourceName) { allErrs = append(allErrs, field.Invalid(reqPath, quantity.String(), fmt.Sprintf("must be equal to %s limit", resourceName))) } else if quantity.Cmp(limitQuantity) > 0 { allErrs = append(allErrs, field.Invalid(reqPath, quantity.String(), fmt.Sprintf("must be less than or equal to %s limit", resourceName))) } <del> } else if resourceName == core.ResourceNvidiaGPU { allErrs = append(allErrs, field.Invalid(reqPath, quantity.String(), fmt.Sprintf("must be equal to %s request", core.ResourceNvidiaGPU))) </del> <ins> } else if !helper.IsOvercommitAllowed(resourceName) { allErrs = append(allErrs, field.Required(limPath, "Limit must be set for non overcommitable resources")) </ins> } }

Related discussion:
text: /kind bug /sig node /area hw-accelerators What happened: In devices are allocated from a function called . This function inspects only container resource limits, ignoring container resource requests. This is a usability problem because it is valid to omit limits for extended resources. If limit is omitted for a device resource, then the scheduler properly places the pod with respect to available node resources. However, the device manager never dispatches to the device plugin for that resource. The result is that the user application cannot access the requested device from inside the container. What you expected to happen: Following the documented behavior of extended resources, I expected that specifying a container resource request for a device would cause the device subsystem to properly configure access for my workload. How to reproduce it (as minimally and precisely as possible): Launch an alpha GKE cluster with GPU support enabled. Attempt to run any program that accesses the GPU from a container where the resource is specified in requests but omitted from limits. Environment: Kubernetes version (use ): v1.8+ Cloud provider or hardware configuration: device plugins enabled, devices available.
Related issue:
cc
/assign
FYI. The said issue has been fixed in . There are several valid cases when requesting extended resources: The user can specify 'limits' only. The API server will automatically set 'requests' to be equal to 'limits'. The user specify 'limits' and 'requests', and they are equal. The user specify 'requests' only. We can either reject the request saying that 'limits' must be set, or implicitly treat 'limits' as equal to 'requests'.
Hi went with to begin since it was ready to go and smaller (easier to revert if necessary.) Hopefully it's easy to rebase your work on top of that. Sorry for the inconvenience.
I feel the documented behavior is incorrect. The original intention was to always require for extended resources until we have better APIs to express bursting scenarios. I vote for fixing the documentation and fixing the validation logic and having kubelet use limits only.
/reopen