Щоб скористатися цією функцією, вам (або адміністратору кластера) потрібно увімкнути функціональну можливість GenericWorkload для всіх відповідних компонентів у вашому кластері.
Перегляньте Увімкнення або вимкнення функціональних можливостей для отримання додаткової інформації.
Групове планування забезпечує, щоб група Podʼів була запланована з дотриманням принципу "все або нічого". Якщо кластер не може вмістити всю групу (або визначену мінімальну кількість Podʼів, вказується у minCount), жоден з Podʼів не привʼязується до вузла.
minCount, фактична кількість запланованих Podʼів під час виконання може опуститися нижче цього порогу, якщо діючі Podʼи згодом будуть видалені або витіснені, або якщо вимога щодо minCount збільшиться. У такому випадку планувальник розміщуватиме додаткові Podʼи лише тоді, коли сумарна кількість уже запланованих Podʼів та нових Podʼів, розміщення яких стало можливим, досягне або перевищить значення minCount.Ця функція залежить від PodGroup API. Переконайтесь, що увімкнено функціональну можливість GenericWorkload та групу API scheduling.k8s.io/v1beta1 у кластері.
Коли втулок GangScheduling увімкнено, планувальник змінює життєвий цикл Podʼів, що належать до PodGroup, для якої встановлено політику планування типу gang. Для кожної PodGroup цей процес відбувається за такими кроками:
Планувальник утримує Podʼи у фазі PreEnqueue, доки:
minCount.PodGroup не потрапляє до активної черги планування, доки не будуть виконані обидві умови.
Після досягнення кворуму планувальник намагається знайти розміщення для всіх незапланованих Podʼів у групі. Він використовує цикл планування PodGroup, щоб прийняти одне, атомарне рішення щодо планування. Втулок GangScheduling реалізує розширювану точку PlacementFeasible, яка викликається для кожного Podʼа, який оцінюється, що підлягає плануванню. Це використовується для визначення, чи задовольняє обмеження minCount, порівнюючи кількість успішно розміщених Podʼів (включно з тими, що вже були заплановані в попередніх циклах) з значенням minCount.
Якщо планувальник знаходить придатні місця для розміщення щонайменше minCount подів, він дозволяє всім їм привʼязатися до призначених їм вузлів. Якщо він не може знайти достатньо місць для задоволення вимоги minCount, жоден з подів не планується. Натомість вони переміщуються до черги подів які неможливо запланувати на вузли, щоб чекати на звільнення ресурсів кластера, що дозволяє тим часом планувати інші робочі навантаження.
Щоб скористатися цією функцією, вам (або адміністратору кластера) потрібно увімкнути функціональну можливість CompositePodGroup для всіх відповідних компонентів у вашому кластері.
Перегляньте Увімкнення або вимкнення функціональних можливостей для отримання додаткової інформації.
Коли увімкнено CompositePodGroup та scheduling.k8s.io/v1alpha3 групу API, групове планування поширює свою підтримку на CompositePodGroups.
На відміну від PodGroups, які групують Podʼи, CompositePodGroups групують дочірні групи разом - або PodGroups, або інші CompositePodGroups. CompositePodGroup визначає політику планування, яка застосовується до його дочірніх груп під час планування:
gang з полем minGroupCount, яке вказує мінімальну кількість дочірніх груп (або обʼєктів CompositePodGroup, або PodGroup), які повинні бути заплановані разом як єдиний атомарний блок.basic, яка вказує, що дочірні групи можна планувати незалежно.Політика gang корисна для багатокомпонентних робочих навантажень, які потребують планування "усе або нічого" для кількох дочірніх груп, забезпечуючи, що мінімальна кількість дочірніх груп планується разом. Прикладом робочого навантаження з такими потребами є відтворене навчання ШІ.
Політика basic може використовуватися для робочих навантажень, що складаються з кількох груп Podʼів, кожну з яких можна планувати як незалежну групу, наприклад, для робочих навантажень з висновку ШІ.
Втулок GangScheduling затримує потрапляння кореневого об’єкта CompositePodGroup до активної черги планування на етапі PreEnqueue доти, доки він не задовольнить вимоги ієрархічного кворуму. Цей кворум оцінюється знизу вгору — від кінцевих об’єктів PodGroup аж до кореневого об’єкта CompositePodGroup:
PodGroup задовольняє кворум тоді і лише тоді, коли обʼєкт PodGroup існує та може потенційно задовольнити критерії своєї політики планування:gang: принаймні minCount її складових Podʼів було створено.basic: принаймні один з її складових Podʼів було створено.CompositePodGroup задовольняє кворум тоді і лише тоді, коли обʼєкт CompositePodGroup існує та може потенційно задовольнити критерії своєї політики планування:gang: принаймні minGroupCount її безпосередніх дочірніх груп задовольняють кворум.basic: принаймні одна з її безпосередніх дочірніх груп задовольняє кворум.CompositePodGroup задовольняє кворум.Зрештою, коренева CompositePodGroup допускається до активної черги планування тоді і лише тоді, коли вона задовольняє ієрархічний кворум та існує щонайменше один Pod, що очікує на планування та належить до одного з її нащадків PodGroups.
Метод PlacementFeasible втулка GangScheduling підтримує оцінювання як для PodGroups, так і для CompositePodGroups. Він викликається циклом планування до початку оцінювання дочірніх груп та після оцінювання кожної дочірньої групи CompositePodGroup.
З урахуванням кількості дочірніх груп, які були успішно заплановані, та дочірніх груп, які ще не були оцінені в поточному циклі планування, PlacementFeasible визначає, чи обмеження політики групи все ще може бути досягнуте, дозволяючи циклу планування достроково припинити оцінювання CompositePodGroup, якщо її основна політика планування вже не може бути задоволена.