Поради щодо динамічного розподілу ресурсів адміністратором кластера

На цій сторінці описано найкращі практики налаштування кластера Kubernetes із використанням динамічного розподілу ресурсів (DRA). Ці інструкції призначені для адміністраторів кластерів.

DRA координується через ряд різних API. Використовуйте інструменти авторизації (такі як RBAC або інше рішення), щоб контролювати доступ до правильних API залежно від ролі вашого користувача.

Загалом, доступ до DeviceClasses і ResourceSlices має бути обмеженим, тільки для адміністраторів і драйверів DRA. Операторам кластерів, які будуть розгортати Podʼи з запитами, знадобиться доступ до API ResourceClaim і ResourceClaimTemplate; обидва ці API обмежуються просторами імен.

Розгортання та обслуговування драйверів DRA

Драйвери DRA — це сторонні застосунки, які працюють на кожному вузлі кластера для взаємодії з апаратним забезпеченням цього вузла та власними компонентами DRA Kubernetes. Процедура встановлення залежить від обраного драйвера, але, ймовірно, він буде розгорнутий як DaemonSet на всіх або на вибраних вузлах (за допомогою селекторів вузлів або подібних механізмів) у кластері.

Використовуйте драйвери з безперебійним оновленням, якщо це можливо

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

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

Якщо ви не можете використовувати безперебійні оновлення, під час простою драйвера для оновлень ви можете помітити, що:

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

Переконайтеся, що драйвер DRA виставляє пробу життєздатності, і використовуйте її.

Ваш драйвер DRA, ймовірно, впроваджує gRPC-сокет для перевірки стану як частину порад щодо створення драйверів DRA. Найпростіший спосіб використати цей gRPC-сокет — налаштувати його як пробу життєздатності для DaemonSet, що розгортає ваш драйвер DRA. Документація вашого драйвера або інструменти розгортання можуть вже включати це, але якщо ви створюєте свою конфігурацію окремо або не запускаєте свій драйвер DRA як pod Kubernetes, переконайтеся, що ваші інструменти оркестрації перезапускають драйвер DRA при невдалих перевірках стану цього gRPC-сокета. Це мінімізує будь-які випадкові простої драйвера DRA і надасть йому більше можливостей для самовідновлення, зменшуючи затримки планування або час усунення несправностей.

Під час очищення вузла вимикайте драйвер якомога пізніше

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

Відстежуйте та налаштовуйте компоненти для більшого навантаження, особливо у великомасштабних середовищах

Компонент панелі управління kube-scheduler та внутрішній контролер ResourceClaim, який координується компонентом kube-controller-manager виконують основну роботу під час планування Podʼів із заявками на основі метаданих, що зберігаються в API DRA. У порівнянні з Podʼами, що плануються без DRA, кількість викликів API-сервера, памʼяті та використання процесора, необхідних для цих компонентів, збільшується для Podʼів, що використовують заявки DRA. Крім того, локальні компоненти вузлів, такі як драйвер DRA та kubelet, використовують API DRA для розподілу запитів на апаратне забезпечення під час створення пісочниці Podʼа. Особливо в масштабних середовищах, де кластери мають багато вузлів та/або розгортають багато робочих навантажень, які інтенсивно використовують заявки на ресурси, визначені DRA, адміністратор кластера повинен налаштувати відповідні компоненти, щоб передбачити збільшення навантаження.

Наслідки неправильно налаштованих компонентів можуть мати прямий або каскадний вплив, викликаючи різні симптоми під час життєвого циклу Podʼа. Якщо параметри QPS та Burst компонента kube-scheduler занадто низькі, планувальник може швидко визначити підходящий вузол для Podʼа, але знадобиться більше часу, щоб привʼязати Pod до цього вузла. З DRA під час планування Podʼа параметри QPS та Burst у конфігурації client-go в kube-controller-manager є критичними.

Конкретні значення для налаштування вашого кластера залежать від різних факторів, таких як кількість вузлів/Podʼів, швидкість створення Podʼів, плинність, навіть у середовищах без DRA; див. README SIG Scalability про пороги масштабованості Kubernetes для отримання додаткової інформації. У масштабних тестах, проведених на кластері з увімкненим DRA з 100 вузлами, задіяними 720 довгоживучими Podʼами (90% насичення) та 80 Podʼами з плинністю (10% плинності, 10 разів), зі швидкістю створення завдань QPS 10, QPS kube-controller-manager можна було встановити на рівні 75, а Burst — 150, щоб досягти еквівалентних метрик для розгортань без DRA. На цьому нижньому рівні було помічено, що обмежувач швидкості на стороні клієнта спрацьовував достатньо, щоб захистити API-сервер від вибухового сплеску, але був достатньо високим, щоб не вплинути на SLO запуску Podʼів. Хоча це гарна відправна точка, ви можете отримати краще уявлення про те, як налаштувати різні компоненти, які найбільше впливають на продуктивність DRA для вашого розгортання, відстежуючи такі метрики. Для отримання додаткової інформації про всі стабільні метрики в Kubernetes див. Довідник з метрик Kubernetes.

Метрики kube-controller-manager

Наступні метрики детально аналізують внутрішній контролер ResourceClaim, який управляється компонентом kube-controller-manager.

  • Швидкість додавання до черги завдань: стежить за sum(rate(workqueue_adds_total{name="resource_claim"}[5m])) , щоб оцінити, як швидко елементи додаються до контролера ResourceClaim.
  • Глибина черги завдань: стежить за sum(workqueue_depth{endpoint="kube-controller-manager", name="resource_claim"}), щоб виявити будь-які затримки в контролері ResourceClaim.
  • Тривалість виконання черги завдань: стежить за histogram_quantile(0.99, sum(rate(workqueue_work_duration_seconds_bucket{name="resource_claim"}[5m])) by (le)), щоб зрозуміти швидкість, з якою контролер ResourceClaim обробляє роботу.

Якщо ви спостерігаєте низьку швидкість додавання до черги завдань, високу глибину черги завдань та/або високу тривалість виконання черги завдань, це свідчить про те, що контролер не працює оптимально. Розгляньте можливість налаштування таких параметрів, як QPS, burst і конфігурації ЦП/памʼяті.

Якщо ви спостерігаєте високу швидкість додавання до черги завдань, високу глибину черги завдань, але розумну тривалість виконання черги завдань, це вказує на те, що контролер справляється з роботою, але паралелізм може бути недостатнім. Паралелізм закодований у контролері, тому як адміністратор кластера ви можете налаштувати це, зменшивши QPS створення Podʼів, щоб швидкість додавання до черги завдань ResourceClaim була більш керованою.

Метрики kube-scheduler

Наступні показники планувальника є показниками високого рівня, що агрегують продуктивність усіх запланованих Podʼів, а не тільки тих, що використовують DRA. Важливо зазначити, що на кінцеві показники впливає продуктивність kube-controller-manager при створенні ResourceClaims з ResourceClainTemplates у розгортаннях, які інтенсивно використовують ResourceClainTemplates.

  • Тривалість роботи планувальника від початку до кінця: відстежує histogram_quantile(0.99, sum(increase(scheduler_pod_scheduling_sli_duration_seconds_bucket[5m])) by (le)).
  • Затримка алгоритму планувальника: відстежує histogram_quantile(0.99, sum(increase(scheduler_scheduling_algorithm_duration_seconds_bucket[5m])) by (le)).

Метрики kubelet

Коли Pod, привʼязаний до вузла, повинен задовольнити ResourceClaim, kubelet викликає методи NodePrepareResources та NodeUnprepareResources драйвера DRA. Ви можете спостерігати цю поведінку з точки зору kubelet за допомогою наступних метрик.

  • Kubelet NodePrepareResources: відстежує histogram_quantile(0.99, sum(rate(dra_operations_duration_seconds_bucket{operation_name="PrepareResources"}[5m])) by (le)).
  • Kubelet NodeUnprepareResources: відстежує histogram_quantile(0.99, sum(rate(dra_operations_duration_seconds_bucket{operation_name="UnprepareResources"}[5m])) by (le)).

Операції DRA kubeletplugin

Драйвери DRA реалізують інтерфейс пакунка kubeletplugin, який відображає власні метрики для базових операцій gRPC NodePrepareResources та NodeUnprepareResources. Ви можете спостерігати цю поведінку з погляду внутрішнього kubeletplugin за допомогою наступних метрик.

  • Операція DRA kubeletplugin gRPC NodePrepareResources: спостерігає за histogram_quantile(0.99, sum(rate(dra_grpc_operations_duration_seconds_bucket{method_name=~".*NodePrepareResources"}[5m])) by (le)).
  • Операція DRA kubeletplugin gRPC NodeUnprepareResources: спостерігає за histogram_quantile(0.99, sum(rate(dra_grpc_operations_duration_seconds_bucket{method_name=~".*NodeUnprepareResources"}[5m])) by (le)).

Що далі

Змінено August 08, 2025 at 6:12 PM PST: sync upstream (e6aacb5400)