Щоб скористатися цією функцією, вам (або адміністратору кластера) потрібно увімкнути функціональну можливість GenericWorkload для всіх відповідних компонентів у вашому кластері.
Перегляньте Увімкнення або вимкнення функціональних можливостей для отримання додаткової інформації.
Кожна PodGroup повинна оголосити політику планування у своєму полі spec.schedulingPolicy. Ця політика визначає, як планувальник обробляє колекцію Podʼів у групі.
Поле schedulingPolicy підтримує два типи політик: basic та gang. Ви повинні вказати лише одну.
basicПолітика basic вказує планувальнику оцінювати всі Pod за принципом «наскільки це можливо». На відміну від політики gang, PodGroup, що використовує політику basic, вважається реалізованою незалежно від того, скільки її Podʼів на даний момент підлягають плануванню.
Основною причиною використання політики basic є організація Podʼів у групу для кращої спостережуваності та управління, при цьому вони все одно оцінюються разом у рамках єдиного атомарного циклу планування PodGroup.
Ця політика підходить для груп, які не потребують одночасного запуску, але логічно належать до одного цілого, або для створення можливості для обмежень на рівні групи, які не передбачають розміщення за принципом «все або нічого».
schedulingPolicy:
basic: {}
gangПолітика gang забезпечує планування «все або нічого». Це необхідно для сильно звʼязаних робочих навантажень, де частковий запуск призводить до блокувань або втрати ресурсів.
Цю політику можна використовувати для Jobs або будь-якого іншого пакетного процесу, де всі працівники повинні працювати одночасно, щоб зробити прогрес.
Політика gang вимагає параметра minCount, який визначає мінімальну кількість Podʼів, які повинні бути заплановані одночасно, щоб група була прийнятною:
schedulingPolicy:
gang:
# Кількість Podʼів, які повинні бути заплановані одночасно
# для того, щоб група була прийнята.
minCount: 4
Під час використання Workload API, ви визначаєте політики планування всередині PodGroupTemplates. Контролер робочого навантаження копіює політику з шаблону в кожну створену PodGroup, роблячи PodGroup самодостатньою. Зміни в шаблонах Workload впливають лише на новостворені PodGroup, а не на наявні.
Для автономних PodGroup (створених без Workload) ви встановлюєте spec.schedulingPolicy безпосередньо на самій PodGroup.
Щоб скористатися цією функцією, вам (або адміністратору кластера) потрібно увімкнути функціональну можливість CompositePodGroup для всіх відповідних компонентів у вашому кластері.
Перегляньте Увімкнення або вимкнення функціональних можливостей для отримання додаткової інформації.
Коли увімкнено функціональну можливість CompositePodGroup та групу API scheduling.k8s.io/v1alpha3 групи API, CompositePodGroupTemplates у Workload та обʼєкти CompositePodGroup також оголошують політику планування.
У той час як політика планування в PodGroup керує колекцією окремих Podʼів, політика планування CompositePodGroup керує її безпосередніми дочірніми групами (які можуть бути як обʼєктами CompositePodGroup, так і PodGroup).
Подібно до PodGroups, поле spec.schedulingPolicy обʼєкта CompositePodGroup підтримує два типи:
basic: дочірні групи в межах CompositePodGroup оцінюються та приймаються незалежно.gang: забезпечує багаторівневе планування "все або нічого" для дочірніх груп. CompositePodGroup є реалізованою лише якщо принаймні minGroupCount дочірніх груп можуть бути заплановані одночасно.schedulingPolicy:
gang:
# Мінімальна кількість дочірніх груп, які повинні бути заплановані
# одночасно, щоб ця складова група була прийнята.
minGroupCount: 2
Під час використання Workload API, політики планування для CompositePodGroups визначаються всередині CompositePodGroupTemplates. Контролери робочого навантаження копіюють schedulingPolicy, вказану в шаблонах, у кожен CompositePodGroup, створений під час виконання. На відміну від кінцевих PodGroupTemplates, де minCount можна оновлювати, minGroupCount у CompositePodGroupTemplate є незмінним.