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

LLMS index: [llms.txt](/llms.txt)

---

<div class="feature-state-notice feature-alpha" title="Функціональна можливість: GenericWorkload">
              <span class="feature-state-name">СТАН ФУНКЦІОНАЛУ:</span> 
              <code>Kubernetes v1.35 [alpha]</code>(стандартно вимкнено)</div>


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

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

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

Ця функція залежить від [Workload API](/docs/concepts/workloads/workload-api/). Переконайтеся, що у кластері увімкнено функціональну можливість [`GenericWorkload`](/docs/reference/command-line-tools-reference/feature-gates/#GenericWorkload) та <a class='glossary-tooltip' title='Набір повʼязаних шляхів в API Kubernetes.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/overview/kubernetes-api/#api-groups-and-versioning' target='_blank' aria-label='групу API'>групу API</a> `scheduling.k8s.io/v1alpha1`.

<!-- body -->

## Цикл планування PodGroup {#podgroup-scheduling-cycle}

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

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

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

2. **Пошук можливих розміщень:** Планувальник запускає [алгоритм планування PodGroup](#podgroup-scheduling-algorithm), щоб знайти дійсні розміщення на вузлах для Podʼів у групі.

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

   * **Success:** Якщо планувальник знаходить достатньо ресурсів та дійсні розміщення для Podʼів (наприклад, задовольняючи обмеження `minCount` для [групового планування](/docs/concepts/scheduling-eviction/gang-scheduling/)), ці Podʼи переходять безпосередньо до циклу привʼязки до обраних вузлів. Будь-які залишкові незаплановані Podʼи повертаються до черги планування, щоб чекати доступних ресурсів і приєднатися до вже запланованих Podʼів.

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

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

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

## Алгоритм планування PodGroup {#podgroup-scheduling-algorithm}

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

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

   * Якщо Pod підходить, він тимчасово призначається та резервується на обраному вузлі до завершення роботи алгоритму планування.
   * Якщо Pod не підходить, планувальник намагається здійснити витіснення, запускаючи точку розширення `PostFilter`.

2. Перевіряє, чи відповідають заплановані Podʼи критеріям планування групи (наприклад, `minCount` для [групового планування](/docs/concepts/scheduling-eviction/gang-scheduling/)) за допомогою точки розширення `Permit`. Якщо для будь-якого Podʼа повертається статус `Success`, PodGroup вважається можливою для планування. Якщо алгоритм обробляє всі Podʼи без досягнення статусу `Success`, PodGroup вважається незапланованою.

## Алгоритм планування розміщення {#placement-scheduling-algorithm}








  <div class="feature-state-notice feature-alpha" title="Функціональна можливість: TopologyAwareWorkloadScheduling">
              <span class="feature-state-name">СТАН ФУНКЦІОНАЛУ:</span> 
              <code>Kubernetes v1.36 [alpha]</code>(стандартно вимкнено)</div>


Алгоритм планування розміщення є альтернативним алгоритмом планування PodGroup, який використовує [втулки планування](/docs/reference/scheduling/config/#scheduling-plugins) для знаходження оптимального розміщення для розглянутої PodGroup. Користувачі можуть адаптувати алгоритм до своїх конкретних потреб, використовуючи та налаштовуючи втулки.

Алгоритм проходить три основні фази для даної PodGroup:

### Фаза 1: Генерація кандидатів на розміщення {#phase-1-candidate-placement-generation}

Генерує кандидатів на *розміщення* (підмножини вузлів, які теоретично можуть бути придатними для призначення PodGroup), наприклад, на основі обмежень планування PodGroup (які можуть бути визначені в обʼєкті PodGroup).

Ця фаза виконується як точка розширення: `PlacementGeneratePlugin`.

### Фаза 2: Фільтрація на рівні Podʼів і перевірка можливості {#phase-2-pod-level-filtering-and-feasibility-check}

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

### Фаза 3: Оцінка та вибір розміщення {#phase-3-placement-scoring-and-selection}

Оцінює всі можливі варіанти розміщення, щоб вибрати оптимальний домен для PodGroup.

Цей етап виконується як точка розширення: `PlacementScorePlugin`.

### Обмеження {#limitations}

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

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

* Для **різнорідних** груп Podʼів, знаходження відповідного розміщення не гарантується.

* Для груп Podʼів з **взаємозалежностями між Podʼами**, знаходження відповідного розміщення не гарантується.

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

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

## Умови PodGroup {#podgroup-conditions}

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

* `PodGroupScheduled`: повідомляє, чи була PodGroup успішно запланована.
* `DisruptionTarget`: вказує, що PodGroup буде завершена через порушення, наприклад, через витіснення.

### `PodGroupScheduled`

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

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

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

### `DisruptionTarget`

Коли планувальник витісняє PodGroup, щоб звільнити місце для PodGroup або Pod з вищим пріоритетом, ця умова встановлюється в `True` з причиною `PreemptionByScheduler`.

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

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

## Що далі

* Дізнайтеся про [Workload API](/docs/concepts/workloads/workload-api/).
* Дивіться, як [посилатися на Workload](/docs/concepts/workloads/pods/workload-reference/) у Podʼі.
* Читайте про [групове планування](/docs/concepts/scheduling-eviction/gang-scheduling/).