Skip to content
KEP Brain

KEP-5075keps/sig-scheduling/5075-dra-consumable-capacity

DRA Consumable Capacity

implementablestablesig-schedulinglatest v1.38
Without this KEP, device sharing is done by having multiple pods (and/or containers) reference the same resource claim, and that resource claim has allocated the device. This can be considered exclusive or dedicated allocation. With this KEP, independent resource claims (and/or requests within a claim) can allocate shares of resources provided by the same un… Full summary

Without this KEP, device sharing is done by having multiple pods (and/or containers) reference the same resource claim, and that resource claim has allocated the device. This can be considered exclusive or dedicated allocation. With this KEP, independent resource claims (and/or requests within a claim) can allocate shares of resources provided by the same underlying device. This enables resource sharing across pods that are completely unrelated, potentially even across different namespaces. When a device is shared across multiple resource claims, this enhancement enables device resource allocation to be drawn from the device’s overall capacity. It ensures that the total resources consumed by all claim requests remain within the device’s capacity and comply with any defined requestPolicy, such as minimum per-claim resource requirements, if specified. This concept is referred to as consumable capacity. If a request does not specify particular device resource requirements, it implies an expectation of full device capacity. Notably, each of these independent resource claims can still be referenced by one or more pods. However, the device resources allocated to each request are shared without any isolation guarantees among the pods that reference the same request. To achieve this, this KEP introduces - a new device property field to distinguish between devices those can be allocated only once and those can be allocated multiple times, - a capacity-aware scheduling mechanism that allows limiting or guaranteeing the capacity of devices among the resource claims (or requests) those are sharing, - a new capacity requirement field in the device request of the resource claim, - a new consumed capacity field in the allocation result of the resource claim, - a method to associate the allocated device status to the allocation result in the resource claim. With those in place, a resource claim with multiple requests might allocate the same device multiple times. This may or

Facts

Authors
@sunya-ch
Approvers
@dom4ha
PRR approvers
@deads2kalpha@deads2kbeta@deads2kstable
Tracking issue
#5075(opens GitHub in a new tab) openreopenedmilestone v1.38sig/networksig/nodesig/schedulingstage/stabletracked/yeslead-opted-inwg/device-management
Milestones
alpha v1.34beta v1.36stable v1.38
Participating SIGs
sig-nodesig-network
Feature gates
DRAConsumableCapacity
Created / last updated
2025-01-30 / none
Loading decisions and status history

Keyboard shortcuts

Everywhere

?
Show or hide this list
/
Focus the question box on Ask, otherwise the page search
Ctrl Kor⌘ K
Focus the KEP search in the top bar
t
Switch the theme (system, light, dark)
Esc
Close a dialog, a search list or a menu

Go to a page

Press g, then the letter

g h
Home
g a
Ask
g e
Explore
g u
Audit
g m
Memory
g b
About

Ask

Enter
Send the question
Shift Enter
New line in the question
Esc
Cancel the running question

Search lists

KEP search and Explore search

↓or↑
Move through the results
HomeorEnd
First or last result (Explore)
Enter
Open the highlighted result, or KEP-n when the query is a number

KEP page

o
Open the KEP on GitHub
y
Open kep.yaml on GitHub
a
Ask about this KEP
←or→
Previous or next tab, when a tab is focused

Findings table

With a finding row focused (Tab into the table or click a row)

jork
Next or previous finding
EnterorSpace
Expand or collapse the finding
o
Open the finding's KEP page
d
Draft the fix as an issue text (nothing is posted)
]or[
Next or previous page of findings

Shortcuts pause while you type in a field. Press ? or Esc to close.