Ця стаття була опублікована більше року тому. Старіші статті можуть містити застарілу інформацію. Перевірте, чи інформація на цій сторінці не втратила актуальності з моменту її публікації.

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

Автор Sunyanan Choochotkaew (IBM), Lionel Jouin (Ericsson Software Technology) John Belamaric (Google) | Перекладач(і) Андрій Головін |

Динамічне виділення ресурсів (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

Ось короткий огляд того, що ви отримуєте в кластері з увімкненою функціональною можливістю DRAConsumableCapacity.

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

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

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

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

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

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

Обмеження DistinctAttribute

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

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

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

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

DRAConsumableCapacity була представлена як альфа-функція в Kubernetes 1.34. Функціональна можливість DRAConsumableCapacity має бути увімкнена в kubelet, kube-apiserver, kube-scheduler і kube-controller-manager.

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

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

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

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

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

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, як частково показано нижче:

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, встановлене в статусі виділення.

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

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

Як споживач

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

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

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

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

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

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

У спільному використанні пристроїв загальна інформація про пристрій надається через ResourceSlice. Однак деякі деталі встановлюються динамічно після виділення. Ці дані можна передати за допомогою поля .status.devices у ResourceClaim. Це поле публікується лише в кластерах, де увімкнено функціональну можливість DRAResourceClaimDeviceStatus.

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

Ви можете знайти більше інформації, переглянувши наш запис: KubeCon Japan 2025 - Reimagining Cloud Native Networks: The Critical Role of DRA.

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

  • Перегляньте проєкт CNI DRA Driver для прикладу інтеграції DRA в мережі Kubernetes. Спробуйте інтегруватися з мережевими ресурсами, такими як macvlan, ipvlan або смарт NIC.

  • Увімкніть функціональну можливість DRAConsumableCapacity та експериментуйте з віртуалізованими пристроями або пристроями, що розділяються на розділи. Визначте свої робочі навантаження зі споживчою ємністю (наприклад: дробова пропускна здатність або памʼять).

  • Дайте нам знати вашу думку:

    • ✅ Що спрацювало добре?
    • ⚠️ Що не спрацювало?

    Якщо ви зіткнулися з проблемами, які потрібно виправити, або можливостями для вдосконалення, будь ласка, створіть новий тікет і пошліться в ньому на KEP-5075, або звʼяжіться з нами через Slack (#wg-device-management).

Висновок

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

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

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

Змінено November 08, 2026 at 1:47 AM PST: Update content/uk/blog/_posts/2025/dra-consumable-capacity.md (1be3ce372c)