# Контролери

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

---

<!-- overview -->

У робототехніці та автоматизації _control loop (цикл керування)_ — це необмежений цикл, який регулює стан системи.

Ось один приклад control loop — термостат у кімнаті.

Коли ви встановлюєте температуру, це означає, що ви повідомляєте термостату про _бажаний стан_. Фактична температура в кімнаті — це _поточний стан_. Термостат діє так, щоб наблизити поточний стан до бажаного стану, вмикаючи чи вимикаючи відповідне обладнання.

У Kubernetes контролери — це цикли управління, які спостерігають за станом вашого <a class='glossary-tooltip' title='Набір робочих машин, що називаються вузлами, які виконують контейнеризовані застосунки. Кожен кластер має принаймні один робочий вузол.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/reference/glossary/?all=true#term-cluster' target='_blank' aria-label='кластера'>кластера</a>, а потім вносять або запитують зміни там, де це необхідно. Кожен контролер намагається наблизити поточний стан кластера до бажаного.

<!-- body -->

## Шаблон контролера {#controller-pattern}

Контролер відстежує принаймні один тип ресурсу Kubernetes. Ці <a class='glossary-tooltip' title='Сутність у системі Kubernetes, що представляє частину стану вашого кластера.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/overview/working-with-objects/#kubernetes-objects' target='_blank' aria-label='обʼєкти'>обʼєкти</a> мають поле spec, яке представляє бажаний стан. Контролер(и) для цього ресурсу відповідають за наближення поточного стану до цього бажаного стану.

Контролер може виконати дію самостійно; частіше в Kubernetes контролер надсилає повідомлення <a class='glossary-tooltip' title='Компонент панелі управління, що обслуговує API Kubernetes.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/architecture/#kube-apiserver' target='_blank' aria-label='API-серверу'>API-серверу</a>, які мають корисні побічні ефекти. Нижче ви побачите приклади цього.



### Управління через API-сервер {#control-via-api-server}

Контролер <a class='glossary-tooltip' title='Скінченне або пакетне завдання, яке виконується до завершення.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/workloads/controllers/job/' target='_blank' aria-label='Job'>Job</a> — це приклад вбудованого контролера Kubernetes. Вбудовані контролери управляють станом, взаємодіючи з API-сервером кластера.

Job — це ресурс 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>, або може кілька Podʼів, щоб виконати завдання і потім зупинитися.

(Після процесу [планування](/docs/concepts/scheduling-eviction/), обʼєкти Pod стають частиною бажаного стану для kubelet).

Коли контролер Job бачить нове завдання, він переконується, що десь у вашому кластері kubeletʼи на наборі вузлів виконують потрібну кількість Podʼів. Контролер Job не запускає жодних Podʼів або контейнерів самостійно. Замість цього контролер Job вказує API-серверу створити або видалити Podʼи. Інші компоненти <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> працюють з новою інформацією (є нові Podʼи для планування та запуску), і, нарешті, робота виконана.

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

Контролери також оновлюють обʼєкти, які їх конфігурують. Наприклад, якщо робота виконана для завдання, контролер Job оновлює обʼєкт Job, щоб позначити його як `Finished`.

(Це трошки схоже на те, як деякі термостати вимикають світловий індикатор, щоб сповістити, що ваша кімната тепер має температуру, яку ви встановили).

### Безпосереднє управління {#direct-control}

На відміну від Job, деякі контролери повинні вносити зміни в речі за межами вашого кластера.

Наприклад, якщо ви використовуєте control loop, щоб переконатися, що у вашому кластері є достатньо <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>, то цей контролер потребує щось поза поточним кластером, щоб налаштувати нові вузли при необхідності.

Контролери, які взаємодіють із зовнішнім станом, отримують свій бажаний стан від API-сервера, а потім безпосередньо спілкуються з зовнішньою системою для наближення поточного стану до бажаного.

(Фактично є [контролер](https://github.com/kubernetes/autoscaler/) що горизонтально масштабує вузли у вашому кластері).

Важливим тут є те, що контролер вносить певні зміни, щоб досягти вашого бажаного стану, а потім повідомляє поточний стан назад на API-сервер вашого кластера. Інші control loop можуть спостерігати за цим звітами та виконувати вже свої дії.

У прикладі з термостатом, якщо в кімнаті дуже холодно, то інший контролер може також увімкнути обігрівач для захисту від морозу. У кластерах Kubernetes панель управління опосередковано працює з інструментами управління IP-адресами, службами сховища, API хмарних провайдерів та іншими службами, розширюючи [Kubernetes](/docs/concepts/extend-kubernetes/) для їх виконання.

## Бажаний стан порівняно з поточним {#desired-vs-current}

Kubernetes має хмарний вигляд систем і здатний обробляти постійні зміни.

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

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

## Дизайн {#design}

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

Корисно мати прості контролери, а не один великий набір взаємозалежних циклів управління. Контролери можуть виходити з ладу, тому Kubernetes спроєктовано з урахуванням цього.


<div class="alert alert-info" role="note"><h4 class="alert-heading">Примітка:</h4><p>У деяких контролерах може бути кілька контролерів, які створюють або оновлюють один і той же тип обʼєкта. За лаштунками контролери Kubernetes переконуються, що вони звертають увагу лише на ресурси, повʼязані з їх контрольним ресурсом.</p>
<p>Наприклад, ви можете мати ресурси Deployments і Jobs; обидва ці ресурси створюють Podʼи. Контролер Job не видаляє Podʼи, які створив ваш Deployment, оскільки є інформація (<a class='glossary-tooltip' title='Позначає обʼєкти атрибутами ідентифікації, які мають значення і є важливими для користувачів.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/overview/working-with-objects/labels' target='_blank' aria-label='мітки'>мітки</a>) яку контролери можуть використовувати для розрізнення цих Podʼів.</p>
</div>


## Способи використання контролерів {#running-controllers}

Kubernetes постачається з набором вбудованих контролерів, які працюють всередині
<a class='glossary-tooltip' title='Компонент панелі управління, який запускає процеси контролера.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/reference/command-line-tools-reference/kube-controller-manager/' target='_blank' aria-label='kube-controller-manager'>kube-controller-manager</a>. Ці вбудовані контролери забезпечують важливі основні функції.

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

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

## Що далі

* Прочитайте про [панель управління Kubernetes](/docs/concepts/architecture/#control-plane-components)
* Дізнайтеся про деякі з основних [обʼєктів Kubernetes](/docs/concepts/overview/working-with-objects/)
* Дізнайтеся більше про [API Kubernetes](/docs/concepts/overview/kubernetes-api/)
* Якщо ви хочете написати свій власний контролер, див. [Розширювані шаблони Kubernetes](/docs/concepts/extend-kubernetes/#extension-patterns) та репозиторій [sample-controller](https://github.com/kubernetes/sample-controller).