# Kubernetes v1.34: Споживча ємність DRA

LLMS index: [llms.txt](/llms.txt)

---

Динамічне виділення ресурсів (Dynamic Resource Allocation, DRA) — це API Kubernetes для управління дефіцитними ресурсами Podʼів та контейнерів. Він дозволяє гнучкі запити ресурсів, виходячи за межі простого виділення _N_ кількості пристроїв, щоб підтримувати більш детальні сценарії використання. З DRA користувачі можуть запитувати специфічні типи пристроїв на основі їх атрибутів, визначати власні конфігурації, адаптовані до їх робочих навантажень, і навіть ділитися одним і тим же ресурсом між кількома контейнерами або Podʼами.

Тут ми зосередимося на функції спільного використання пристроїв і заглибимось в нову можливість, представлену в Kubernetes 1.34: _споживча ємність DRA_, яка розширює DRA для підтримки більш тонкого спільного використання пристроїв.

## Передумови: спільне використання пристроїв через ResourceClaims

З самого початку DRA представила можливість для кількох Podʼів ділитися пристроєм, посилаючись на один і той же ResourceClaim. Цей дизайн відокремлює виділення ресурсів від конкретного обладнання, що дозволяє більш динамічне та повторне використання пристроїв.

У Kubernetes 1.33 нова підтримка _розділювальних пристроїв (partitionable devices)_ дозволила драйверам ресурсів оголошувати частини пристрою, які доступні, а не виставляти весь пристрій як ресурс "все або нічого". Це дозволило Kubernetes більш точно моделювати обладнання спільного використання.

Але все ще залишалася одна відсутня частина: він ще не підтримував сценарії, коли драйвер пристрою керує тонкими, динамічними частинами ресурсу пристрою, такими як пропускна здатність мережі, на основі запитів користувачів, або для спільного використання цих ресурсів незалежно від ResourceClaims, які обмежені їх специфікацією та простором імен.

Саме тут зʼявляється _споживча ємність_ для DRA.

## Переваги підтримки споживчої ємності DRA

Ось короткий огляд того, що ви отримуєте в кластері з увімкненою [функціональною можливістю](/docs/reference/command-line-tools-reference/feature-gates/) `DRAConsumableCapacity`.

### Спільне використання пристроїв між кількома ResourceClaims або DeviceRequests

Тепер драйвери ресурсів можуть підтримувати спільне використання одного й того ж пристрою, або навіть частини пристрою, між кількома ResourceClaims або між кількома DeviceRequests.

Це означає, що Podʼи з різних просторів імен можуть одночасно ділитися одним і тим же пристроєм, якщо це дозволено та підтримується конкретним драйвером DRA.

### Виділення ресурсів пристроїв

Kubernetes розширює алгоритм виділення в планувальнику, щоб підтримувати виділення частини ресурсів пристрою, як визначено в полі `capacity`. Планувальник забезпечує, щоб загальна виділена ємність для всіх споживачів ніколи не перевищувала загальну ємність пристрою, навіть коли вона ділиться між кількома ResourceClaims або DeviceRequests. Це дуже схоже на те, як планувальник дозволяє Podʼам і контейнерам ділитися виділеними ресурсами на вузлах; в цьому випадку він дозволяє їм ділитися виділеними ресурсами на пристроях.

Ця функція розширює підтримку сценаріїв, де драйвер пристрою може керувати ресурсами **всередині** пристрою та на основі кожного процесу — наприклад, виділення певної кількості памʼяті (наприклад, 8 ГіБ) з віртуального GPU, або встановлення обмежень пропускної здатності на віртуальні мережеві інтерфейси, виділені конкретним Podʼам. Це має на меті забезпечити безпечне та ефективне спільне використання ресурсів.

### Обмеження DistinctAttribute

Ця функція також вводить нове обмеження: `DistinctAttribute`, яке є доповненням до наявного обмеження `MatchAttribute`.

Основна мета `DistinctAttribute` полягає в тому, щоб запобігти багаторазовому виділенню одного й того ж базового пристрою в межах одного ResourceClaim, що може статися, оскільки ми виділяємо частки (або підмножини) пристроїв. Це обмеження забезпечує, щоб кожне виділення посилалося на окремий ресурс, навіть якщо вони належать до одного й того ж класу пристроїв.

Це корисно для таких випадків, як виділення мережевих пристроїв, що підключаються до різних підмереж, щоб розширити покриття або забезпечити резервування в різних зонах відмов.

## Як використовувати споживчу ємність?

`DRAConsumableCapacity` була представлена як альфа-функція в Kubernetes 1.34. [Функціональна можливість](/docs/reference/command-line-tools-reference/feature-gates/) `DRAConsumableCapacity` має бути увімкнена в kubelet, kube-apiserver, kube-scheduler і kube-controller-manager.

```bash
--feature-gates=...,DRAConsumableCapacity=true
```

### Як розробник драйвера DRA

Як розробник драйвера DRA, що пише на Golang, ви можете зробити пристрій у межах ResourceSlice доступним для кількох ResourceClaims (або `devices.requests`), встановивши `AllowMultipleAllocations` на `true`.

```go
Device {
  ...
  AllowMultipleAllocations: ptr.To(true),
  ...
}
```

Додатково, ви можете визначити політику, щоб обмежити те, як кожен `DeviceRequest` повинен споживати `Capacity` кожного пристрою, визначивши поле `RequestPolicy` у `DeviceCapacity`. Приклад нижче показує, як визначити політику, яка вимагає, щоб GPU з 40 ГіБ памʼяті виділяв щонайменше 5 ГіБ на запит, при цьому кожне виділення має бути кратним 5 ГіБ.

```go
DeviceCapacity{
  Value: resource.MustParse("40Gi"),
  RequestPolicy: &CapacityRequestPolicy{
    Default: ptr.To(resource.MustParse("5Gi")),
    ValidRange: &CapacityRequestPolicyRange {
      Min: ptr.To(resource.MustParse("5Gi")),
      Step: ptr.To(resource.MustParse("5Gi")),
    }
  }
}
```

Це буде опубліковано в ResourceSlice, як частково показано нижче:

```yaml
apiVersion: resource.k8s.io/v1
kind: ResourceSlice
...
spec:
  devices:
  - name: gpu0
    allowMultipleAllocations: true
    capacity:
      memory:
        value: 40Gi
        requestPolicy:
          default: 5Gi
          validRange:
            min: 5Gi
            step: 5Gi
```

Віділений пристрій з певною часткою спожитої ємності матиме поле `ShareID`, встановлене в статусі виділення.

```go
claim.Status.Allocation.Devices.Results[i].ShareID
```

Цей `ShareID` дозволяє драйверу розрізняти різні віділення, які посилаються на **той самий пристрій або той самий статично виділений сегмент**, але походять з **різних запитів `ResourceClaim`**. Він діє як унікальний ідентифікатор для кожного спільного сегмента, дозволяючи драйверу незалежно керувати та застосовувати обмеження ресурсів для декількох споживачів.

### Як споживач

Як споживач (або користувач), ресурс пристрою можна запитати за допомогою ResourceClaim, як показано нижче:

```yaml
apiVersion: resource.k8s.io/v1
kind: ResourceClaim
...
spec:
  devices:
    requests: # для пристроїв
    - name: req0
      exactly:
        deviceClassName: resource.example.com
        capacity:
          requests: # для ресурсів, які повинні бути надані цими пристроями
            memory: 10Gi
```

Ця конфігурація забезпечує, що запитуваний пристрій може надати щонайменше 10ГіБ памʼяті.

Зокрема, **будь-який** пристрій `resource.example.com`, який має щонайменше 10ГіБ памʼяті, може бути виділений. Якщо вибрано пристрій, який не підтримує кілька виділень, виділення використовуватиме весь пристрій. Щоб відфільтрувати лише пристрої, які підтримують кілька виділень, ви можете визначити селектор, як показано нижче:

```yaml
selectors:
  - cel:
      expression: |-
        device.allowMultipleAllocations == true
```

## Інтеграція зі статусом пристроїв DRA

У спільному використанні пристроїв загальна інформація про пристрій надається через ресурсний зріз. Однак деякі деталі встановлюються динамічно після виділення. Ці дані можна передати за допомогою поля [`.status.devices`](/docs/concepts/scheduling-eviction/dynamic-resource-allocation/#resourceclaim-device-status) у ResourceClaim. Це поле публікується лише в кластерах, де увімкнено `DRAResourceClaimDeviceStatus` feature gate.

Якщо у вас є підтримка _статусу пристроїв_, драйвер може надати додаткову інформацію про пристрій, виходячи за межі `ShareID`. Одним із особливо корисних випадків є віртуальні мережі, де драйвер може включити призначену IP-адресу(и) у статус. Це цінно як для операцій мережевих служб, так і для усунення несправностей.

Ви можете знайти більше інформації, переглянувши нашу запис: [KubeCon Japan 2025 — Reimagining Cloud Native Networks: The Critical Role of DRA](https://sched.co/1x71v).

## Що ви можете зробити далі?

* **Перегляньте проєкт [CNI DRA Driver](https://github.com/kubernetes-sigs/cni-dra-driver)** для прикладу інтеграції DRA в мережі Kubernetes. Спробуйте інтегруватися з мережевими ресурсами, такими як `macvlan`, `ipvlan` або смарт NIC.
* Увімкніть функціональну можливість `DRAConsumableCapacity` та експериментуйте з віртуалізованими або роздільними пристроями. Визначте свої робочі навантаження з _споживаною ємністю_ (наприклад: дробова пропускна здатність або памʼять).
* Дайте нам знати вашу думку:
  * ✅ Що спрацювало добре?
  * ⚠️ Що не спрацювало?

  Якщо ви зіткнулися з проблемами, які потрібно виправити, або можливостями для вдосконалення, будь ласка, [створіть новий тікет](https://github.com/kubernetes/enhancements/issues) і посилайтеся та пошліться на [KEP-5075](https://github.com/kubernetes/enhancements/issues/5075) там, або звʼяжіться з нами через [Slack (#wg-device-management)](https://kubernetes.slack.com/archives/C0409NGC1TK).

### Висновок

Підтримка споживчої ємності покращує можливості спільного використання пристроїв DRA, дозволяючи ефективне спільне використання пристроїв між просторами імен, між запитами та адаптуючи їх до фактичних потреб кожного Podʼа. Це також надає драйверам можливість забезпечувати обмеження ємності, покращує точність планування та відкриває нові випадки використання, такі як обізнаність про пропускну здатність мережі та спільне використання пристроїв у багатокористувацькому середовищі.

Спробуйте це, експериментуйте зі споживаними ресурсами та допоможіть сформувати майбутнє динамічного виділення ресурсів у Kubernetes!

### Додатково ознайомтеся з

* [Документація DRA в Kubernetes](/docs/concepts/scheduling-eviction/dynamic-resource-allocation/)
* [KEP для DRA Partitionable Devices](https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling/4815-dra-partitionable-devices)
* [KEP для DRA Device Status](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/4817-resource-claim-device-status)
* [KEP для DRA Consumable Capacity](https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling/5075-dra-consumable-capacity)
* [Kubernetes 1.34 Release Notes](https://www.kubernetes.dev/resources/release/#kubernetes-v134)