Групове планування Podʼів: Розлад та пріоритети

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

Типи режимів розладу

API підтримує два режими розладу: Single та All. Стандартний режим — Single.

Single

Режим Single вказує планувальнику розглядати всі Podʼи в групі як окремі сутності, дозволяючи незалежний розлад окремого пода з PodGroup.

All

Режим All підкреслює семантику "все або нічого" для розладу. Він вказує планувальнику, що всі поди з PodGroup повинні отримати сигнал розладу одночасно.

CompositePodGroup

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

API підтримує два режими розладу для CompositePodGroups:

• Single: дозволяє окремим дочірнім групам у межах CompositePodGroup отримати розлад незалежно під час витіснення.
• All: забезпечує семантику розладу "все або нічого" для всієї ієрархії CompositePodGroup. Якщо будь-який Pod, що міститься в ієрархії нижче цього CompositePodGroup, має бути витіснений, усі Podʼи з усієї ієрархії мають бути витіснені.

Якщо не вказано, стандартний режим — Single.

Пріоритет групи Podʼів

PodGroup використовує ту ж концепцію PriorityClass, що й окремі Podʼи. Після створення одного або кількох PriorityClasses, ви можете створити PodGroup, яка вказує одне з цих імен PriorityClass у своїй специфікації. Контролер допуску пріоритету використовує поле priorityClassName і заповнює ціле значення пріоритету. Якщо клас пріоритету не знайдено, PodGroup відхиляється. Коли priorityClassName не встановлено для PodGroup, Kubernetes шукає стандартне значення (PriorityClass з globalDefault, встановленим у true). Якщо немає PriorityClass з globalDefault, встановленим у true, PodGroup без priorityClassName має пріоритет нуль.

Пріоритет PodGroup є авторитетним пріоритетом для всіх подів у групі під час подій витіснення з урахуванням навантаження. Це значення також використовується для впорядкування PodGroup у черзі планування. Якщо пріоритети окремих подів, що формують цю PodGroup, відрізняються від пріоритету PodGroup, PodGroup не буде запланована з помилкою all pods in a single pod group should have the same priority as the pod group (усі поди в одній групі подів повинні мати такий самий пріоритет, як і сама група подів).

Коли увімкнено функціональну можливість PodGroupPreemptionPolicy, PodGroup також має поле preemptionPolicy. Це поле також береться з PriorityClass. Воно є авторитетним полем для всіх подів у групі та визначає, чи може PodGroup виконувати витіснення подів і груп подів з нижчим пріоритетом, щоб звільнити місце для себе. Коли функціональну можливість увімкнено, усі Podʼи в PodGroup повинні мати той самий preemptionPolicy, що й PodGroup. Інакше PodGroup не буде запланована з помилкою all pods in a single pod group should have the same preemption policy as the pod group's preemption policy (усі поди в одній групі подів повинні мати ту саму політику витіснення, що й політика витіснення цієї групи подів). Коли PodGroup має preemptionPolicy: Never, вона не виконуватиме витіснення з урахуванням робочого навантаження. Якщо функціональну можливість вимкнено, усі Podʼи, що формують PodGroup, повинні мати однаковий preemptionPolicy. Інакше PodGroup не буде запланована з помилкою all pods in a single pod group should have the same preemption policy (усі поди в одній групі подів повинні мати однакову політику витіснення).

Наступний YAML є прикладом конфігурації PodGroup, яка використовує PriorityClass high-priority, що відповідає цілому значенню пріоритету 1000000. Контролер допуску пріоритету перевіряє специфікацію та визначає пріоритет PodGroup як 1000000.

apiVersion: scheduling.k8s.io/v1beta1
kind: PodGroup
metadata:
  namespace: ns-1
  name: job-1
spec:
  priorityClassName: high-priority

Пріоритет CompositePodGroup

API CompositePodGroup також має поля priorityClassName та priority, і їх визначення виконується так само, як і для PodGroups, через контролер допуску пріоритету.

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

Значення пріоритету також використовується для впорядкування кореневих CompositePodGroups в активній черзі планування.

PreemptionPolicy у CompositePodGroup

API CompositePodGroup також має поле preemptionPolicy, і його визначення виконується точно так само, як і для API PodGroup.

Значення preemptionPolicy кореневого CompositePodGroup визначає, чи може бути викликане витіснення з урахуванням навантаження для розміщення його Podʼів під час планування, якщо це необхідно:

• політика PreemptLowerPriority дозволяє витісняти жертв з нижчим пріоритетом;
• політика Never вимикає витіснення з урахуванням навантаження для цього кореневого CompositePodGroup.

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

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

Що далі

• Дізнайтеся про алгоритм витіснення з урахуванням навантаження.
• Дізнайтеся про Workload API.
• Дізнайтеся про будівельні блоки планування та бібліотеку workloadbuilder, зокрема про будівельний блок режиму розладу.