# Kubernetes v1.37: Оновлення DRA

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

---

Kubernetes 1.37 вже тут, а [Динамічне виділення ресурсів (DRA)](/docs/concepts/scheduling-eviction/dynamic-resource-allocation/) продовжує розвиватися, виходячи за межі своїх початкових можливостей! У цьому випуску підтримка розширених ресурсів DRA переходить у статус GA — це важлива віха, до якої команда прагнула протягом трьох послідовних випусків. Ще кілька функцій переходять у статус бета-версії або GA. Нова серія альфа-функцій доповнює цей випуск.

Що нового для DRA у Kubernetes 1.37?

## Що стабільне у версії 1.37? {#whats-stable-in-137}

[Підтримка розширених ресурсів DRA](https://www.kubernetes.dev/resources/keps/5004) досягла стадії GA. Це механізм, що дозволяє драйверам DRA задовольняти запити, зроблені через традиційний API розширених ресурсів, наприклад, `example.com/gpu` у специфікації Pod, без необхідності окремого втулок пристрою поруч з драйвером DRA. Імʼя розширеного ресурсу може бути встановлено безпосередньо на DeviceClass, а Podʼи, що його запитують, зіставляються з пристроєм через DRA без необхідності ResourceClaim у робочому навантаженні.

З моменту прийняття KEP у версії 1.34 проєкт розвивався стабільно. Альфа-версія з’явилася у 1.35, бета — у 1.36, а зараз доступна стабільна версія. Саме це дозволяє операторам кластерів поступово впроваджувати DRA. Наявні робочі навантаження, створені для роботи з розширеними ресурсами, продовжують працювати без змін, тоді як логіка розподілу ресурсів на серверній стороні переходить на DRA.

[Статус ResourceClaim із можливими стандартизованими даними мережевого інтерфейсу](https://www.kubernetes.dev/resources/keps/4817/) додає поле `Devices` до `ResourceClaim.Status`, дозволяючи драйверам DRA повідомляти статус по пристроях, включаючи для мережевих пристроїв — імʼя інтерфейсу, MAC-адресу та IP-адреси. Це дає користувачам та контролерам видимість стану пристрою, яка раніше була невидимою після налаштування пристрою в Podʼі, і робить можливим створення таких речей, як мережеві сервіси, що покладаються на повідомлені IP пристроїв.

[DRA: taint та toleration пристроїв](https://www.kubernetes.dev/resources/keps/5055/) тепер стабільні; драйвери DRA можуть позначати пристрої як tainted, щоб вони пропускалися при плануванні нових Podʼів, а адміністратори кластерів можуть застосовувати ті самі taint в масштабах кластера через `DeviceTaintRule`, без переконфігурації драйверів. Podʼи, що вже використовують tainted пристрій, можуть бути витіснені автоматично, якщо їхній ResourceClaim явно не толерує цей taint. Це відображає позначки taint та toleration вузлів, дозволяючи операторам виводити окремий пристрій на обслуговування або позначати його як деградований, не порушуючи роботу решти кластера.

[Стандартизований атрибут пристрою numaNode](https://github.com/kubernetes/enhancements/issues/6072) стандартизує `resource.kubernetes.io/numaNode` як спільну назву атрибуту, щоб пристрої від різних драйверів можна було порівняти на тому самому NUMA-вузлі, замість того щоб кожен драйвер вигадував власну назву для цього. Це потрапило безпосередньо у стабільну версію у 1.37, оскільки це KEP іменування/реєстрації без функціональної можливості чи зміни поведінки in-tree.

## Функції, переведені у beta {#feature-promoted-to-beta}

[Підтримка ResourceClaim для робочих навантажень](https://www.kubernetes.dev/resources/keps/5729) переходить у beta з функціональною можливістю `DRAWorkloadResourceClaims`, яка стандартно залишається вимкненою. У кластері з увімкненою цією функцією, Workload та PodGroups можуть посилатися на ResourceClaims безпосередньо, так що один claim може бути спільним для цілої групи Podʼів. Це замість обмеження claims до 256 Podʼів через старий ліміт резервування на Podʼах.

[DRA Device Attributes Downward API](https://www.kubernetes.dev/resources/keps/5304/) спрямований на підтримку впровадження пристроїв у VM KubeVirt. Драйвери заповнюють поле `Metadata` при підготовці claim, а фреймворк записує його у JSON-файл, змонтований у контейнер через CDI, дозволяючи робочим навантаженням безпосередньо читати PCI-адресу пристрою, MAC-адресу та інші атрибути замість потреби в спеціальних контролерах для спостереження та перетворення ResourceClaims та ResourceSlices.

## Alfa-функції {#alpha-features}

[Типи-списки для атрибутів](https://www.kubernetes.dev/resources/keps/5491) перейшло у другу альфа у v1.37, дозволяючи атрибуту пристрою містити більше одного значення замість одного скаляра, як процесор, що суміжний більш ніж з одним PCIe root. Це робить можливим зіставлення або розрізнення пристроїв на основі перекриваючихся чи неперекриваючихся наборів значень, тоді як  атрибути з одним значенням продовжують працювати як раніше.

[Запити розподілюваних ресурсів вузла](https://www.kubernetes.dev/resources/keps/5517) перейшла до Alpha 2. Функція дозволяє планувальнику та kubelet обробляти CPU, памʼять та схожі ресурси вузла, керовані DRA, так само, як звичайні запити ресурсів, щоб вузол не перепідписувався, а користувачам більше не треба дублювати той самий запит як у ResourceClaim, так і у специфікації пода.

[Видимість доступності ресурсів](https://www.kubernetes.dev/resources/keps/5677) перейшла до другої альфа у Kubernetes 1.37. Користувачі створюють ResourcePoolStatusRequest для отримання моментального знімка доступності. Для оновлення — видаляють і перестворюють запит; це не API безперервного моніторингу.

[DRA: Опціональні операції з вузлами](https://www.kubernetes.dev/resources/keps/5945) дозволяє драйверу пропускати виклики kubelet `prepare` та `unprepare` для виділень, які не потребують жодної настройки на вузлі. Це дає змогу уникнути зайвої залежності від драйвера у випадках, коли йому дійсно немає чого робити на локальному рівні.

[Похідні атрибути](https://www.kubernetes.dev/resources/keps/6080) — нова функція, що дозволяє використовувати [CEL](/docs/reference/using-api/cel/) вирази для зіставлення пристроїв на основі власних користувацьких правил. Раніше парування пристроїв від різних вендорів (наприклад, GPU/TPU та NIC на тому самому NUMA-вузлі) працювало лише тоді, коли обидва драйвери використовували точну назву атрибуту. Якщо один використовував `numa`, а інший `numaNode`, планувальник не міг їх поєднати. Тепер ви можете легко поєднувати ці відмінності самі у своєму маніфесті, тобто не потрібно чекати, поки постачальники обладнання домовляться про стандартизовані імена атрибутів. Окрім виправлення відмінностей у назвах, CEL також можна використовувати для складніших сценаріїв, як-от виділення конкретного ID з довгого монолітного топологічного рядка, або групування пристроїв у власні рівні продуктивності на основі їх доступної ємності.

[DRA Device Compatibility Groups](https://www.kubernetes.dev/resources/keps/5963) дозволяє драйверам тегувати розділи пристрою, як MIG проти vGPU профілів на тому самому GPU, з групами сумісності, щоб планувальник відхиляв несумісні комбінації на етапі планування замість того, щоб драйвер падав під час підготовки вузла. Це контролюється функціональною можливістю `DRADeviceCompatibilityGroups`, стандартно вимкнена.

[Точка розширення PreQueueingHint](https://www.kubernetes.dev/resources/keps/6132) з’явилася у версії 1.37 у стадії альфа-тестування. Події DRA ResourceClaim раніше запускали повне сканування кожного пода, який не можна було запланувати, що при великому масштабуванні вимагало обчислювальних витрат порядку O(N²). Тепер втулок DRA використовує індекс Pod Informer, щоб обмежити це лише тими подами, яких це насправді стосується, скорочуючи шлях повторного постановки в чергу до O(1) і, за попередніми тестами, приблизно подвоюючи пропускну здатність планування. Керується функціональною можливістю `SchedulerPreQueueingHints`.

[DRA Consumable Capacity](https://www.kubernetes.dev/resources/keps/5075) тепер підтримує дробові значення в CapacityRequestPolicyRange, що дозволяє більш точно запитувати та виділяти ресурси для пристроїв з дробовими ресурсами. Це підвищує гнучкість для робочих навантажень, які потребують тонкого розподілу ресурсів. Покращення контролюється функціональною можливістю `DRAFractionalCapacityRange`, яка перебуває на стадії Beta у версії 1.37.

## Що далі {#whats-next}

DRA продовжує вдосконалюватися з кожним новим випуском. Декілька функцій, які наразі перебувають на стадії альфа- та бета-тестування, планується впровадити в наступних версіях, а спільнота продовжує працювати над продуктивністю, масштабованістю та надійністю DRA. У версії Kubernetes 1.38 очікується черговий амбітний набір функцій DRA.

## Як долучитися {#getting-involved}

Хорошою початковою точкою є приєднання до [Slack-каналу](https://kubernetes.slack.com/archives/C0409NGC1TK) та [зустрічей](https://docs.google.com/document/d/1qxI87VqGtgN7EAJlqVfxx86HGKEAc2A3SKru8nJHNkQ/edit?tab=t.0#heading=h.tgg8gganowxq) WG Device Management, які відбуваються у часових слотах, зручних для US/EU та EU/APAC.

Не всі ідеї покращень поки що зареєстровані в тікетах, тож звертайтеся до нас, якщо хочете допомогти або маєте власні ідеї! У нас є робота на всіх рівнях — від складних змін у ядрі до покращень зручності використання в `kubectl`, які можуть бути корисними для новачків.

## Подяки {#acknowledgments}

Наступним власникам KEP вдалося додати або перевести функцію у релізі 1.37 (у алфавітному порядку):

* Alay Patel ([alaypatel07](https://github.com/alaypatel07))
* Byonggon Chun ([bg-chun](https://github.com/bg-chun))
* Gaurav Ghildiyal ([gauravkghildiyal](https://github.com/gauravkghildiyal))
* Jiefeng Xu ([jiefeng-xu](https://github.com/jiefeng-xu))
* John A. Hull ([johnahull](https://github.com/johnahull))
* Jon Huhn ([nojnhuh](https://github.com/nojnhuh))
* Lionel Jouin ([LionelJouin](https://github.com/LionelJouin))
* Patrick Ohly ([pohly](https://github.com/pohly))
* Praveen Krishna ([pravk03](https://github.com/pravk03))
* Shingo Omura ([everpeace](https://github.com/everpeace))
* Troy Chiu ([troychiu](https://github.com/troychiu))

Це було б неможливо без допомоги рецензентів та осіб, які затверджували зміни. Тож величезне спасибі всім, хто долучився до створення цього релізу — як великими, так і дрібними зусиллями. Коли достатньо очей, усі помилки стають очевидними, і в цьому релізі їх було чимало, але завдяки пильному нагляду та турботі про вдосконалення все вдалося виправити. Завдяки вам усім DRA став кращим у цьому циклі.