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
537
+
managing how much of the device's capacity is used up by each claim. This is analogous to how Pods can share
538
+
the resources on a Node; ResourceClaims can share the resources on a Device.
539
+
540
+
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.
541
+
542
+
Users can set `capacity` field added in `spec.devices.requests` of `ResourceClaim` to specify the device resource requirements for each allocation.
543
+
544
+
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**.
545
+
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.
546
+
547
+
Here is an example of a network device which allows multiple allocations and contains
548
+
a consumable bandwidth capacity.
549
+
550
+
```yaml
551
+
kind: ResourceSlice
552
+
apiVersion: resource.k8s.io/v1
553
+
metadata:
554
+
name: resourceslice
555
+
spec:
556
+
nodeName: worker-1
557
+
pool:
558
+
name: pool
559
+
generation: 1
560
+
resourceSliceCount: 1
561
+
driver: dra.example.com
562
+
devices:
563
+
- name: eth1
564
+
allowMultipleAllocations: true
565
+
attributes:
566
+
name:
567
+
string: "eth1"
568
+
capacity:
569
+
bandwidth:
570
+
requestPolicy:
571
+
default: "1M"
572
+
validRange:
573
+
min: "1M"
574
+
step: "8"
575
+
value: "10G"
576
+
```
577
+
578
+
The consumable capacity can be requested as shown in the below example.
579
+
580
+
```yaml
581
+
apiVersion: resource.k8s.io/v1
582
+
kind: ResourceClaimTemplate
583
+
metadata:
584
+
name: bandwidth-claim-template
585
+
spec:
586
+
spec:
587
+
devices:
588
+
requests:
589
+
- name: req-0
590
+
exactly:
591
+
- name:
592
+
deviceClassName: resource.example.com
593
+
capacity:
594
+
requests:
595
+
bandwidth: 1G
596
+
```
597
+
598
+
The allocation result will include the consumed capacity and the identifier of the share.
599
+
600
+
```yaml
601
+
apiVersion: resource.k8s.io/v1
602
+
kind: ResourceClaim
603
+
...
604
+
status:
605
+
allocation:
606
+
devices:
607
+
results:
608
+
- consumedCapacity:
609
+
bandwidth: 1G
610
+
device: eth1
611
+
shareID: "a671734a-e8e5-11e4-8fde-42010af09327"
612
+
```
613
+
614
+
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`.
615
+
532
616
### Device taints and tolerations {#device-taints-and-tolerations}
0 commit comments