Kubernetes v1.33: Нові можливості динамічного розподілу ресурсів
Динамічне виділення ресурсів (DRA) у Kubernetes швидко розвивається з моменту свого альфа-дебюту у версії v1.26. Після суттєвого перероблення у v1.31 основні функції перейшли в бета-версію у v1.32, а v1.33 забезпечує подальшу стабілізацію, оскільки спільнота активно готується до загальної доступності у v1.34. У цій статті розглядаються останні бета-промоції та нововведення альфа-версії, надаються технічні інсайти та експертні думки, а також аналізуються реальні випадки використання, показники продуктивності та шлях до загальної доступності.
Передумови: Еволюція динамічного виділення ресурсів
Традиційні плагіни пристроїв покладаються на kubelet для виявлення та реклами спеціалізованого обладнання (ГПУ, FPGA, NIC) через статичні назви ресурсів. DRA замінює цю модель на більш розширену групу API resource.k8s.io, вводячи CRD ResourceClaim та ResourceClaimTemplate у v1beta1 (з оновленням до v1beta2 у v1.33). Драйвери реєструються через gRPC-інтерфейс з Динамічним контролером ресурсів Kubelet, що забезпечує детальне виділення, динамічну перенастроювання пристроїв та події життєвого циклу, що контролюються драйверами.
Функції, що перейшли в бета-версію у v1.33
- Статус ResourceClaim, що контролюється драйверами (
status.driver): Драйвери тепер можуть додавати власну інформацію про стан та топологію в кожен ResourceClaim. Наприклад, плагіни Mellanox NIC повідомляють про швидкість з’єднання, локальність PCI-шини та стан PF/VF, що дозволяє планувальнику приймати рішення з урахуванням NUMA.
Нові альфа-функції у v1.33
- Роздільні пристрої: Драйвери пристроїв рекламують логічні “частини” (наприклад, профілі vGPU або накладення FPGA). Під час виділення фізичний пристрій перенастроюється — через драйвери, які відкривають OCI-хуки — для відповідності вимогам навантаження. Лабораторні тести показують до 40% підвищення використання для спільних кластерів AI-інференсу.
- Забруднення та толерантність пристроїв: Оператори кластеру можуть забруднювати обладнання, яке знижене в продуктивності або на обслуговуванні (
effect=NoSchedule|NoExecute). Поди повинні оголосити толерантності для зв’язку. Цей механізм інтегрується з існуючими потоками евакуації та забезпечує плавний перехід у разі збоїв обладнання. - Списки пріоритетних пристроїв: Навантаження можуть вказувати кілька профілів пристроїв у порядку пріоритету — наприклад, один високопродуктивний ГПУ або два середніх. Планувальник оцінює альтернативи послідовно, використовуючи алгоритми зворотного пошуку у фреймворку планувальника для максимізації використання кластера.
- Обмеження доступу адміністратора: Використання поля
adminAccessтепер обмежується за допомогою міток простору імен (resource.k8s.io/admin-access='true'). Лише облікові записи служб з цією міткою можуть створювати ResourceClaims з підвищеними правами, запобігаючи експлуатації ескалації привілеїв.
Підготовка до загальної доступності
З виходом v1.33 з новим API v1beta2, UX спрощено: за замовчуванням класи ресурсів, стандартизовані коди помилок та покращена виявленість API через kubectl explain. Команди SIG Node та SIG API Machinery уточнили правила RBAC для обмеження доступу до драйверів і запитів. Драйвери тепер підтримують безперервні оновлення, зберігаючи стан запитів під час переходів між версіями, що зменшує плинність у виробничих кластерах.
Розгляд продуктивності та масштабованості
У мікро-тестах, проведених CNCF, динамічний контролер ресурсів DRA додає менше 5% навантаження на ЦП та < 20 MiB пам'яті на 1,000 пристроїв — масштабуючись лінійно з кількістю пристроїв. Піковий QPS запису Etcd для операцій CRD ResourceClaim становить близько 800 записів/с на контрольному вузлі з трьох вузлів за замовчуванням. Для оптимізації оператори повинні налаштувати --min-request-timeout та використовувати виділені вузли контрольної площини для навантажень з інтенсивним введенням/виведенням.
Інтеграція з екосистемою Cloud Native
DRA гармонійно поєднується з containerd та CRI-O через стандартизовані інтерфейси плагінів. Драйвери ГПУ, такі як nvidia-container-toolkit, оновлюються для підтримки API ResourceClaim. Телеметрія надається через метрики Prometheus (kubelet_dra_allocations_total, resource_claim_duration_seconds) та інтегрується з панелями Grafana для моніторингу стану пристроїв у реальному часі. Kubeflow Pipelines та Argo workflows тепер можуть націлюватися на конкретні розділи прискорювачів, що дозволяє багатокористувацьким AI/ML навантаженням працювати на спільних кластерах.
Реальні випадки використання та впровадження
Фінансові компанії використовують DRA для динамічного розділення FPGA для алгоритмів торгівлі з низькою затримкою. Оператори телекомунікацій, які впроваджують функції 5G, використовують розділення NIC для виділення SR-IOV VF за запитом. У CERN вчені проводять HPC-симуляції на змішаних флотах NVIDIA A100 та V100, спираючись на списки пріоритетних пристроїв для максимізації пропускної здатності, коли A100 обмежені.
Дорожня карта та внесок спільноти
Мета етапу v1.34 — досягти повного статусу GA, забезпечуючи DRA за замовчуванням на нових кластерах. Усі альфа-функції v1.33 — роздільні пристрої, забруднення та толерантність, пріоритетні списки та доступ адміністратора — заплановані для переходу в бета-версію. Майбутні вдосконалення включають багатокористувацький QoS, динамічне зливання пристроїв для поетапних оновлень та плагіни планувальника для кастомних політик виділення.
Що далі?
Оскільки DRA наближається до GA, користувачі повинні почати активувати функцію DynamicResourceAllocation у тестових середовищах, перевірити сумісність драйверів та переглянути політики RBAC. Слідкуйте за майбутніми пропозиціями покращень Kubernetes (KEPs) щодо QoS, відновлення на основі знімків ResourceClaims та спільного використання запитів між просторами імен.
Як долучитися
Приєднуйтесь до каналу Slack WG Device Management (шукайте #wg-device-management) та відвідуйте щотижневі зустрічі спільноти в часи, що охоплюють США/ЄС та ЄС/АПАЦ. Переглядайте відкриті KEPs та проблеми на GitHub у репозиторії kubernetes/enhancements під міткою dra. Нові учасники завжди ласкаво просимо допомогти з оновленнями документації, автоматизацією тестування або вдосконаленням інтеграції з планувальником.