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

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

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

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

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

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

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

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

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

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

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

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

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

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

     Планувальник намагається зробити PodGroup запланованою, запускаючи точку розширення PodGroupPostFilter. Точка розширення PodGroupPostFilter втулка DefaultPreemption виконує витіснення з урахуванням навантаження. Якщо будь-який втулок, що реалізує точку розширення PodGroupPostFilter, повертає Success, жодні інші втулки для точки розширення PodGroupPostFilter не виконуються.

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

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

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

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

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

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

2. Перевіряє, чи відповідають заплановані Podʼи критеріям планування групи (наприклад, minCount для групового планування), викликаючи точку розширення PlacementFeasible після оцінки кожного Podʼа в групі на основі сукупних результатів планування. Якщо для будь-якого Podʼа повертається статус Success, PodGroup вважається можливою для планування. Якщо алгоритм обробляє всі Podʼи без досягнення статусу Success, або якщо під час цього циклу не заплановано жодного Podʼа, 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 відхиляється, якщо ця умова не виконується.

Ієрархічне планування з CompositePodGroups

Коли функціональну можливість CompositePodGroup та групу API scheduling.k8s.io/v1alpha3 увімкнено, планувальник розширює цикл планування PodGroup для підтримки багаторівневих ієрархій груп.

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

Виконання циклу ієрархічного планування

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

Щойно кореневий CompositePodGroup задовольняє ієрархічний кворум, він потрапляє в активну чергу планування, з якої його може витягнути цикл планування. Потік циклу планування для CompositePodGroups виглядає наступним чином:

1. Уніфікований знімок кластера та перевірка: Планувальник робить знімок ресурсів кластера, щоб відобразити останній спостережений стан кластера. Він перевіряє, що форма ієрархії груп, витягнутої з черги, збігається зі знімком ієрархії, та перевіряє узгодженість конфігурації ієрархії (таку як однакові .spec.schedulerName та пріоритет серед Podʼів-членів).

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

2. Генерація кандидатів на розміщення зверху вниз: На кожному рівні ієрархії, перед оцінкою дочірніх груп, планувальник викликає втулки PlacementGeneratePlugin, щоб згенерувати кандидатів на розміщення (підмножини вузлів) для групи, що оцінюється.

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

3. Рекурсивна симуляція піддерева та перевірка можливості: Планувальник оцінює кожного кандидата на розміщення для CompositePodGroup, тимчасово припускаючи це розміщення у знімку кластера та рекурсивно плануючи його дочірні групи:

   • Рекурсивний обхід: Планувальник обходить дочірні групи в попередньо відсортованому порядку, викликаючи себе рекурсивно від CompositePodGroup вниз до кінцевих обʼєктів PodGroup. Для кожного кінцевого PodGroup планувальник запускає алгоритм планування розміщення, обмежений кандидатом на розміщення батьківської групи, щоб зробити попередні призначення Podʼів у памʼяті.
   • Перевірки можливості: Після оцінки кожної дочірньої групи планувальник викликає втулки PlacementFeasible, щоб визначити, чи може політика планування батьківської групи все ще бути виконана:
     • Якщо обмеження політики залишаються досяжними (або вже задоволені), планувальник продовжує оцінювати наступні дочірні групи.
     • Якщо обмеження політики більше не можуть бути задоволені, планувальник негайно перериває оцінку цього CompositePodGroup та скасовує всі попередні призначення Podʼів у памʼяті, зроблені для цієї групи.
   • Відкат симуляції: Після симуляції кандидата на розміщення (незалежно від успіху чи невдачі) планувальник скасовує попередні резервування вузлів, зроблені під час цієї симуляції, перед оцінкою наступного кандидата на розміщення.

4. Оцінка розміщення та фіксація піддерева: Після того, як усі кандидати на розміщення для CompositePodGroup були оцінені:

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

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

     Якщо серед усіх згенерованих кандидатів не знайдено жодного можливого розміщення, весь CompositePodGroup вважається незапланованим.

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

   В іншому випадку весь CompositePodGroup вважається незапланованим.

Обмеження

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

Крім того, оскільки планувальник оцінює ієрархії груп за допомогою жадібного підходу:

• Знаходження дійсного розміщення не гарантується у всіх випадках, навіть якщо воно існує в кластері.
• Навіть коли планувальник успішно знаходить дійсне розміщення для ієрархії CompositePodGroup, це розміщення не гарантовано є оптимальним по всьому кластеру.

Умови PodGroup

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

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

PodGroupInitiallyScheduled

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

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

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

Після того, як стан встановлено в True, він ніколи не змінюється.

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

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

Стани CompositePodGroup

API CompositePodGroup також надає поле status.conditions.

Однак у v1.37 планувальник не заповнює це поле.

Що далі

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