Групове планування PodGroup

Стандартний планувальник Kubernetes оцінює Podʼи послідовно. Коли кілька робочих навантажень, таких як завдання навчання машинного навчання, подаються одночасно, ця послідовна оцінка може призвести до блокувань ресурсів. Наприклад, два конкуруючі робочі навантаження можуть кожне запланувати підмножину своїх Podʼів, споживаючи ресурси кластера, але залишаючи жодне з робочих навантажень без достатньої кількості ресурсів для повного запуску.

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

Крім того, розгляд групи як єдиного цілого створює фундаментальну архітектуру, яка спрощує реалізацію інших функцій планування на основі груп.

Ця функція залежить від Workload API. Переконайтеся, що у кластері увімкнено функціональну можливість GenericWorkload та групу API scheduling.k8s.io/v1alpha1.

Цикл планування PodGroup

Щоб підтримати планування групи Podʼів разом, kube-scheduler використовує цикл планування PodGroup. Замість обробки Podʼів окремо та утримання їх на етапі WaitOnPermit, планувальник оцінює всю групу очікуваних Podʼів, що належать до конкретного PodGroup, колективно. Замість виконання окремих циклів планування для кожного Podʼа, він оцінює можливість для всієї групи та переходить безпосередньо до фази привʼязки до вузла.

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

1. Знімок стану кластера: Коли планувальник починає оцінювати PodGroup, він робить один знімок стану кластера, який зберігається протягом усього циклу. Це забезпечує консистентність оцінки для всієї групи та запобігає конкуренції за ресурси з іншими подіями.

2. Пошук можливих розміщень: Планувальник запускає алгоритм планування PodGroup, щоб знайти дійсні розміщення на вузлах для Podʼів у групі.

3. Атомарне рішення: Залежно від результату алгоритму, рішення про планування застосовується атомарно для всієї PodGroup.

   • Success: Якщо планувальник знаходить достатньо ресурсів та дійсні розміщення для Podʼів (наприклад, задовольняючи обмеження minCount для групового планування), ці Podʼи переходять безпосередньо до циклу привʼязки до обраних вузлів. Будь-які залишкові незаплановані Podʼи повертаються до черги планування, щоб чекати доступних ресурсів і приєднатися до вже запланованих Podʼів.

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

   • Failure: Якщо планувальник не може знайти достатньо ресурсів для забезпечення можливості планування PodGroup (наприклад, не вдається задовольнити обмеження minCount), вся PodGroup вважається незапланованою. Жоден Pod не привʼязується до вузла, але всі повертаються до черги планування. Застосовується стандартна логіка відкладеного повторного планування, що дозволяє повторити спробу пізніше.

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

Алгоритм планування PodGroup

Стандартний алгоритм планування PodGroup значною мірою покладається на базовий алгоритм планування на основі Podʼів. Він послідовно обробляє всі Pod і для кожного з них виконує наступне:

1. Знаходить можливий вузол за допомогою стандартних фаз фільтрації та оцінки для кожного Podʼа.

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

2. Перевіряє, чи відповідають заплановані Podʼи критеріям планування групи (наприклад, minCount для групового планування) за допомогою точки розширення Permit. Якщо для будь-якого Podʼа повертається статус Success, PodGroup вважається можливою для планування. Якщо алгоритм обробляє всі Podʼи без досягнення статусу Success, PodGroup вважається незапланованою.

Алгоритм планування розміщення

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

Алгоритм проходить три основні фази для даної PodGroup:

Фаза 1: Генерація кандидатів на розміщення

Генерує кандидатів на розміщення (підмножини вузлів, які теоретично можуть бути придатними для призначення PodGroup), наприклад, на основі обмежень планування PodGroup (які можуть бути визначені в обʼєкті PodGroup).

Ця фаза виконується як точка розширення: PlacementGeneratePlugin.

Фаза 2: Фільтрація на рівні Podʼів і перевірка можливості

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

Фаза 3: Оцінка та вибір розміщення

Оцінює всі можливі варіанти розміщення, щоб вибрати оптимальний домен для PodGroup.

Цей етап виконується як точка розширення: PlacementScorePlugin.

Обмеження

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

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

• Для різнорідних груп Podʼів, знаходження відповідного розміщення не гарантується.

• Для груп Podʼів з взаємозалежностями між Podʼами, знаходження відповідного розміщення не гарантується.

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

Для забезпечення послідовної роботи протягом усього циклу алгоритм вимагає, щоб усі Pod, що належать до однієї PodGroup, мали однаковий параметр .spec.schedulerName. Ця вимога перевіряється перед початком циклу, і PodGroup відхиляється, якщо ця умова не виконується.

Умови PodGroup

Після завершення циклу планування PodGroup, планувальник оновлює умови в status.conditions PodGroup:

• PodGroupScheduled: повідомляє, чи була PodGroup успішно запланована.
• DisruptionTarget: вказує, що PodGroup буде завершена через порушення, наприклад, через передчасне видалення.

PodGroupScheduled

Коли цикл планування успішний, умова встановлюється в True з причиною Scheduled. Для PodGroup з політикою gang це означає, що було розміщено принаймні minCount Podʼів.

Коли планування не вдається, умова встановлюється в False з однією з наступних причин:

• Unschedulable — групу не вдалося розмістити через обмеження ресурсів, правила спорідненості або антиспорідненості, або недостатню ємність для групи.
• SchedulerError — планування не вдалося через внутрішню помилку планувальника (наприклад, під час розбору обмежень планування, таких як nodeAffinity).

DisruptionTarget

Коли планувальник передчасно видаляє PodGroup, щоб звільнити місце для PodGroup або Pod з вищим пріоритетом, ця умова встановлюється в True з причиною PreemptionByScheduler.

Ви можете перевірити умови за допомогою:

kubectl get podgroup <name> -o jsonpath='{.status.conditions}'

Що далі

• Дізнайтеся про Workload API.
• Дивіться, як посилатися на Workload у Podʼі.
• Читайте про групове планування.