RFC: KEP-4381: DRA: management access #4611
Conversation
A claim with management access to the underlying resource(s) is useful, e.g. for health checks or statistics gathering. Because this is privileged access, we need a way to control whether users are granted that privilege.
k8s-ci-robot
added
the
cncf-cla: yes
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: pohly The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
kind/kep
k8s-ci-robot
added
the
size/M
| // access mode that is only granted when there is a Quota object | ||
| // in the same namespace as the claim where AllowManagementAccess | ||
| // is true. | ||
| ManagementAccess bool |
There was a problem hiding this comment.
This also needs to be in the allocation result, together with some explanations that the DRA driver kubelet plugin should validate allocation results. It's always possible that an error occurred and two claims both have the same instance in their result. The plugin should catch that and reject preparing the second claim, except when management access is involved.
There was a problem hiding this comment.
This is also necessary because devices might be injected differently if they are meant for management access vs. normal allocation (this is true for NVIDIA GPUs with MIG devices, for example).
There was a problem hiding this comment.
I added a comment saying that the ResourceClaimSpec.ManagementAccess is immutable. Then this information will be available to drivers - assuming that we do #4615.
| This new boolean alone is not sufficient to deploy a daemon set which requests | ||
| and gets access to all resource instances of a certain type on a node. Some way | ||
| to ask for ">= 1 instance" with no upper bound will be needed. This can be | ||
| added together with support for optional allocation. |
There was a problem hiding this comment.
What I have in mind is adding an optional "range" to a request. No range means "exactly one" (current KEP). Adding a range with "min: 1" could be used to ask for all GPUs. A range with "min: 0, max: 1" would be for a resource that is not absolutely required.
I'll do a separate PR with this.
This proposal takes the existing KEP as base and includes: - vendor-independent classes and attributes (kubernetes/enhancements#4614) - optional allocation (kubernetes/enhancements#4619) - inline parameters (kubernetes/enhancements#4613) - management access (kubernetes/enhancements#4611) - renaming "named resources" to "devices" wherever it makes sense and is user-facing (Slack discussion) - MatchAttributes (from k8srm-prototype) - OneOf (from k8srm-prototype) `pkg/api` currently builds, but the rest doesn't. None of the YAML examples have been updated yet.
This proposal takes the existing KEP as base and includes: - vendor-independent classes and attributes (kubernetes/enhancements#4614) - optional allocation (kubernetes/enhancements#4619) - inline parameters (kubernetes/enhancements#4613) - management access (kubernetes/enhancements#4611) - renaming "named resources" to "devices" wherever it makes sense and is user-facing (Slack discussion) - MatchAttributes (from k8srm-prototype) - OneOf (from k8srm-prototype) `pkg/api` currently builds, but the rest doesn't. None of the YAML examples have been updated yet.
This proposal takes the existing KEP as base and includes: - vendor-independent classes and attributes (kubernetes/enhancements#4614) - optional allocation (kubernetes/enhancements#4619) - inline parameters (kubernetes/enhancements#4613) - management access (kubernetes/enhancements#4611) - renaming "named resources" to "devices" wherever it makes sense and is user-facing (Slack discussion) - MatchAttributes (from k8srm-prototype) - OneOf (from k8srm-prototype) `pkg/api` currently builds, but the rest doesn't. None of the YAML examples have been updated yet.
This proposal takes the existing KEP as base and includes: - vendor-independent classes and attributes (kubernetes/enhancements#4614) - optional allocation (kubernetes/enhancements#4619) - inline parameters (kubernetes/enhancements#4613) - management access (kubernetes/enhancements#4611) - renaming "named resources" to "devices" wherever it makes sense and is user-facing (Slack discussion) - MatchAttributes (from k8srm-prototype) - OneOf (from k8srm-prototype) `pkg/api` currently builds, but the rest doesn't. None of the YAML examples have been updated yet.
This proposal takes the existing KEP as base and includes: - vendor-independent classes and attributes (kubernetes/enhancements#4614) - optional allocation (kubernetes/enhancements#4619) - inline parameters (kubernetes/enhancements#4613) - management access (kubernetes/enhancements#4611) - renaming "named resources" to "devices" wherever it makes sense and is user-facing (Slack discussion) - MatchAttributes (from k8srm-prototype) - OneOf (from k8srm-prototype) `pkg/api` currently builds, but the rest doesn't. None of the YAML examples have been updated yet.
This proposal takes the existing KEP as base and includes: - vendor-independent classes and attributes (kubernetes/enhancements#4614) - optional allocation (kubernetes/enhancements#4619) - inline parameters (kubernetes/enhancements#4613) - management access (kubernetes/enhancements#4611) - renaming "named resources" to "devices" wherever it makes sense and is user-facing (Slack discussion) - MatchAttributes (from k8srm-prototype) - OneOf (from k8srm-prototype) `pkg/api` currently builds, but the rest doesn't. None of the YAML examples have been updated yet.
One-line PR description: management access
Issue link: DRA: structured parameters #4381
Other comments:
A claim with management access to the underlying resource(s) is useful, e.g. for health checks or statistics gathering. Because this is privileged access, we need a way to control whether users are granted that privilege.