# Планувальник Kubernetes

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

---

<!-- overview -->

У Kubernetes _планування_ означає забезпечення того, що <a class='glossary-tooltip' title='Pod є групою контейнерів, що запущені у вашому кластері.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/workloads/pods/' target='_blank' aria-label='Podʼи'>Podʼи</a> призначаються відповідним <a class='glossary-tooltip' title='Вузол — це робоча машина в Kubernetes.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/architecture/nodes/' target='_blank' aria-label='вузлам'>вузлам</a>, щоб їх можна було запустити за допомогою <a class='glossary-tooltip' title='Агент, запущений на кожному вузлі кластера. Забезпечує запуск і роботу контейнерів у Podʼах.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/reference/command-line-tools-reference/kubelet' target='_blank' aria-label='Kubelet'>Kubelet</a>.

<!-- body -->

## Огляд планування {#scheduling}

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

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

## kube-scheduler

[kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) є стандартним планувальником для Kubernetes і працює як частина <a class='glossary-tooltip' title='Шар оркестрування контейнерів, який надає API та інтерфейси для виявлення, розгортання та управління життєвим циклом контейнерів.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/reference/glossary/?all=true#term-control-plane' target='_blank' aria-label='панелі управління'>панелі управління</a>. kube-scheduler розроблено так, що, якщо ви хочете і вам треба, ви можете написати власний компонент планування і використовувати його замість стандартного.

Kube-scheduler вибирає оптимальний вузол для запуску нових або ще не запланованих Podʼів. Оскільки контейнери в Podʼах, і самі Podʼи, можуть мати різні вимоги, планувальник фільтрує будь-які вузли, які не відповідають конкретним потребам планування Podʼа. Крім того, через API можна вказати вузол для Podʼа при його створенні, але це робиться тільки у виняткових випадках.

У кластері Вузли, які відповідають вимогам планування для Podʼа, називаються _feasible_ (придатними) вузлами. Якщо жоден з вузлів не підходить, Pod залишається незапланованим до тих пір, поки планувальник не зможе розмістити його.

Планувальник знаходить придатні Вузли для Podʼів, а потім виконує набір функцій для оцінки таких Вузлів і вибирає Вузол з найвищим рейтингом серед придатних для запуску Podʼа. Планувальник потім повідомляє сервер API про це рішення в процесі, який називається _binding_ (привʼязкою).

Фактори, які потрібно враховувати при прийнятті рішень про планування, включають індивідуальні та загальні вимоги до ресурсів, обмеження апаратного та програмного забезпечення / політики, (анти)спорідненість (affinity), розташування даних, взаємовплив між робочими навантаженнями та інше.

### Вибір вузла в kube-scheduler {#kube-scheduler-implementation}

kube-scheduler вибирає вузол для Podʼа в два етапи:

1. Фільтрація.
1. Оцінювання.

На етапі _фільтрації_ визначається набір Вузлів, на яких можна розмістити Pod. Наприклад, фільтр PodFitsResources перевіряє, чи має Вузол-кандидат достатньо доступних ресурсів, щоб задовольнити конкретні вимоги до ресурсів Podʼа. Після цього етапу список вузлів містить придатні вузли; часто їх буде більше одного. Якщо список порожній, цей Pod (поки що) неможливо запланувати.

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

На останньому етапі kube-scheduler призначає Pod вузлу з найвищим рейтингом. Якщо є більше одного вузла з однаковими рейтингами, kube-scheduler вибирає один з них випадковим чином.

Є два підтримуваних способи налаштування поведінки фільтрації та оцінювання планувальника:

1. [Політики планування](/docs/reference/scheduling/policies) дозволяють налаштувати _Предикати_ для фільтрації та _Пріоритети_ для оцінювання.
2. [Профілі планування](/docs/reference/scheduling/config/#profiles) дозволяють налаштувати втулки, які реалізують різні етапи планування, включаючи: `QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit` та інші. Ви також можете налаштувати kube-scheduler для запуску різних профілів.

## Що далі

* Дізнайтеся про [налаштування продуктивності планувальника](/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)
* Дізнайтеся про [обмеження розподілу топології Podʼа](/docs/concepts/scheduling-eviction/topology-spread-constraints/)
* Прочитайте [довідку](/docs/reference/command-line-tools-reference/kube-scheduler/) для kube-scheduler
* Прочитайте [посилання на конфігурацію kube-scheduler (v1)](/docs/reference/config-api/kube-scheduler-config.v1/)
* Дізнайтеся про [налаштування кількох планувальників](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)
* Дізнайтеся про [політики управління топологією](/docs/tasks/administer-cluster/topology-manager/)
* Дізнайтеся про [накладні витрати Podʼа](/docs/concepts/scheduling-eviction/pod-overhead/)
* Дізнайтеся про планування Podʼів, які використовують томи в:
  * [Підтримка топології томів](/docs/concepts/storage/storage-classes/#volume-binding-mode)
  * [Відстеження місткості сховища](/docs/concepts/storage/storage-capacity/)
  * [Обмеження томів для конкретного вузла](/docs/concepts/storage/storage-limits/)