Workload API

• 1: Групове планування Podʼів: Розлад та пріоритети
• 2: Політики планування PodGroup
• 3: Топологічно-орієнтоване планування робочих навантажень

apiVersion: scheduling.k8s.io/v1alpha2
kind: Workload
metadata:
  name: training-job-workload
  namespace: some-ns
spec:
  controllerRef:
    apiGroup: batch
    kind: Job
    name: training-job
  podGroupTemplates:
  - name: workers
    schedulingPolicy:
      gang:
        # gang може бути запланована тільки в тому випадку, якщо одночасно можуть працювати 4 пода.
        minCount: 4
    priorityClassName: high-priority # Застосовується лише з функціональною можливістю WorkloadAwarePreemption
    disruptionMode: PodGroup # Застосовується лише з функціональною можливістю WorkloadAwarePreemption

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

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

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

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

Pod

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

PodGroup

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

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

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

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

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

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

Що далі

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

2 - Політики планування PodGroup

Кожна 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

Встановлення політик через PodGroupTemplates

Під час використання Workload API, ви визначаєте політики планування всередині PodGroupTemplates. Контролер робочого навантаження копіює політику з шаблону в кожну створену PodGroup, роблячи PodGroup самодостатньою. Зміни в шаблонах Workload впливають лише на новостворені PodGroup, а не на наявні.

Для автономних PodGroup (створених без Workload) ви встановлюєте spec.schedulingPolicy безпосередньо на самій PodGroup.

Що далі

• Дізнайтеся про PodGroup API для того щоб зрозуміти, як політики застосовуються під час виконання.
• Дізнайтеся про Workload API, який визначає PodGroupTemplates.
• Прочитайте про планування PodGroup.
• Прочитайте про алгоритм групового планування.

3 - Топологічно-орієнтоване планування робочих навантажень

Топологічно-орієнтоване планування робочих навантажень (Topology-Aware Scheduling, TAS) є функцією Workload API, яка оптимізує розміщення Podʼів у межах кластера.

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

Топологічно-орієнтоване планування з політикою gang

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

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

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

Топологічно-орієнтоване планування з політикою basic

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

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

Якщо до PodGroup додаються нові Podʼи, де деякі Podʼи вже заплановані, планувальник діятиме так само, як у випадку політики gang — змушуючи нові Podʼи розміститися в тому ж домені, якщо є достатньо ресурсів (у протилежному випадку нові Podʼи залишаться в стані очікування).

Налаштування API: обмеження планування

Кожна PodGroup (або PodGroupTemplate) може опціонально оголосити поле schedulingConstraints, яке інтерпретується алгоритмом планування PodGroup на основі розміщення. Якщо обмеження визначені в PodGroupTemplate, вони будуть скопійовані до вказаних PodGroup.

Починаючи з версії Kubernetes v1.36, API підтримує топологічні обмеження.

Топологічне обмеження

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

Ось приклад PodGroup, налаштованої з топологічним обмеженням:

apiVersion: scheduling.k8s.io/v1alpha2
kind: PodGroup
metadata:
  name: example-podgroup
spec:
  schedulingPolicy:
    gang:
      minCount: 4
  schedulingConstraints:
    topology:
      - key: topology.example.com/rack

Що далі

• Дізнайтеся про політики груп Pod.
• Дізнайтеся про втулки, повʼязані з топологічно-орієнтованим плануванням
• Прочитайте про алгоритм групового планування.