You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The consumable capacity feature allows the same devices to be consumed by multiple independent ResourceClaims, with the Kubernetes scheduler
538
+
managing how much of the device's capacity is used up by each claim. This is analogous to how Pods can share
539
+
the resources on a Node; ResourceClaims can share the resources on a Device.
540
+
541
+
The device driver can set `allowMultipleAllocations` field added in `.spec.devices` of `ResourceSlice` to allow allocating that device to multiple independent ResourceClaims or to multiple requests within a ResourceClaim.
542
+
543
+
Users can set `capacity` field added in `spec.devices.requests` of `ResourceClaim` to specify the device resource requirements for each allocation.
544
+
545
+
For the device that allows multiple allocations, the requested capacity is drawn from — or consumed from — its total capacity, a concept known as **consumable capacity**.
546
+
Then, the scheduler ensures that the aggregate consumed capacity across all claims does not exceed the device’s overall capacity. Furthermore, driver authors can use the `requestPolicy` constraints on individual device capacities to control how those capacities are consumed. For example, the driver author can specify that a given capacity is only consumed in increments of 1Gi.
547
+
548
+
Here is an example of a network device which allows multiple allocations and contains
549
+
a consumable bandwidth capacity.
550
+
551
+
```yaml
552
+
kind: ResourceSlice
553
+
apiVersion: resource.k8s.io/v1
554
+
metadata:
555
+
name: resourceslice
556
+
spec:
557
+
nodeName: worker-1
558
+
pool:
559
+
name: pool
560
+
generation: 1
561
+
resourceSliceCount: 1
562
+
driver: dra.example.com
563
+
devices:
564
+
- name: eth1
565
+
allowMultipleAllocations: true
566
+
attributes:
567
+
name:
568
+
string: "eth1"
569
+
capacity:
570
+
bandwidth:
571
+
requestPolicy:
572
+
default: "1M"
573
+
validRange:
574
+
min: "1M"
575
+
step: "8"
576
+
value: "10G"
577
+
```
578
+
579
+
The consumable capacity can be requested as shown in the below example.
580
+
581
+
```yaml
582
+
apiVersion: resource.k8s.io/v1
583
+
kind: ResourceClaimTemplate
584
+
metadata:
585
+
name: bandwidth-claim-template
586
+
spec:
587
+
spec:
588
+
devices:
589
+
requests:
590
+
- name: req-0
591
+
exactly:
592
+
- name:
593
+
deviceClassName: resource.example.com
594
+
capacity:
595
+
requests:
596
+
bandwidth: 1G
597
+
```
598
+
599
+
The allocation result will include the consumed capacity and the identifier of the share.
600
+
601
+
```yaml
602
+
apiVersion: resource.k8s.io/v1
603
+
kind: ResourceClaim
604
+
...
605
+
status:
606
+
allocation:
607
+
devices:
608
+
results:
609
+
- consumedCapacity:
610
+
bandwidth: 1G
611
+
device: eth1
612
+
shareID: "a671734a-e8e5-11e4-8fde-42010af09327"
613
+
```
614
+
615
+
In this example, a multiply-allocatable device was chosen. However, any `resource.example.com` device with at least the requested 1G bandwidth could have met the requirement. If a non-multiply-allocatable device were chosen, the allocation would have resulted in the entire device. To force the use of a only multiply-allocatable devices, you can use the CEL criteria `device.allowMultipleAllocations == true`.
616
+
533
617
### Device taints and tolerations {#device-taints-and-tolerations}
0 commit comments