# Витіснення з урахуванням робочого навантаження

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

---

<!-- overview -->







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


Витіснення з урахуванням робочого навантаження (Workload-aware preemption) вводить механізм витіснення, спеціально розроблений для PodGroups. Коли PodGroup не може бути запланована, планувальник використовує логіку витіснення, яка намагається зробити можливим планування цієї PodGroup. Цей підхід використовується виключно під час планування PodGroup і замінює стандартний механізм витіснення для подів із зазначеної PodGroup.

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

Ця функція залежить від [Групового планування](/docs/concepts/scheduling-eviction/gang-scheduling/) та [Workload API](/docs/concepts/workloads/workload-api/). Переконайтеся, що у кластері увімкнено функціональні можливості [`GenericWorkload`](/docs/reference/command-line-tools-reference/feature-gates/#GenericWorkload) та [`GangScheduling`](/docs/reference/command-line-tools-reference/feature-gates/#GangScheduling), а також <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/v1alpha2`

<!-- body -->

## Як це працює {#how-it-works}

Процес витіснення з урахуванням робочого навантаження дотримується тих самих принципів, що й [стандартне витіснення](/docs/concepts/scheduling-eviction/pod-priority-preemption/#preemption), з кількома відмінностями:

1. Домен по всьому кластеру: Замість оцінки витіснення вузол за вузлом, планувальник оцінює весь кластер як єдиний домен. Він обирає набір жертв на кількох вузлах, які можна видалити, щоб звільнити достатньо місця для планування PodGroup.

2. Ієрархія важливості жертв: Планувальник визначає, які одиниці витіснення (окремі поди або PodGroups) є більш критичними і повинні бути захищені від витіснення, використовуючи сувору ієрархію:
   * Пріоритет: Одиниці з вищим пріоритетом завжди важливіші.
   * Тип робочого навантаження: PodGroups вважаються важливішими за окремі поди з тим самим пріоритетом.
   * Розмір групи (PodGroups): Якщо обидві одиниці є PodGroups, та, що має більше членів (більший розмір), вважається важливішою.
   * Час запуску: Одиниці, які були запущені раніше, є важливішими.

3. Пріоритет і режим розладу групи подів: Планувальник враховує конкретний [пріоритет і режим розладу](/docs/concepts/workloads/workload-api/disruption-and-priority/) PodGroup для оцінки того, чи можна витісняти її поди під час подій витіснення.


<div class="alert alert-info" role="note"><h4 class="alert-heading">Примітка:</h4>Під час планування одного пода застосовується стандартне витіснення подів. Починаючи з версії 1.36, коли планувальник виконує стандартне витіснення для одного пода і намагається витіснити под, що належить до PodGroup, він <strong>не</strong> враховує поля <code>priority</code> або <code>disruptionMode</code> цієї PodGroup.</div>


## Що далі

* Дізнайтеся більше про [Пріоритети і розлади групи подів](/docs/concepts/workloads/workload-api/disruption-and-priority/).
* Дізнайтеся більше про [Workload API](/docs/concepts/workloads/workload-api/).
* Дізнайтеся більше про [Планування груп подів](/docs/concepts/scheduling-eviction/gang-scheduling/).