# Архітектура кластера

> Архітектурні концепції в основі Kubernetes.

---

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

---

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

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

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



<figure class="diagram-large ">
    <img src="/images/docs/kubernetes-cluster-architecture.svg"
         alt="Панель управління (kube-apiserver, etcd, kube-controller-manager, kube-scheduler) та кілька вузлів. Кожен вузол запускає kubelet та kube-proxy."/> <figcaption>
            <p>Схема 1. Компоненти кластера Kubernetes.</p>
        </figcaption>
</figure>

<details><summary>Про архітектуру</summary><div class="details-inner">
    <p>На схемі 1 представлено приклад еталонної архітектури кластера Kubernetes. Фактичний розподіл компонентів може змінюватися залежно від конкретних налаштувань кластера та вимог.</p>
<p>На схемі на кожному вузлі запущено компонент <a href="#kube-proxy"><code>kube-proxy</code></a>. Вам потрібен компонент мережевого проксі на кожному вузлі, щоб гарантувати, що <a class='glossary-tooltip' title='Спосіб відкрити доступ до застосунку, що запущений на декількох Podʼах у вигляді мережевої служби.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/services-networking/service/' target='_blank' aria-label='Service'>Service</a> API та повʼязані з ним дії були доступні у вашій кластерній мережі. Втім, деякі мережеві втулки надають власну, сторонню реалізацію проксі-сервера. Коли ви використовуєте такий мережевий втулок, вузлу не потрібно запускати <code>kube-proxy</code>.</p>

  </div>
</details>


## Компоненти панелі управління {#control-plane-components}

Компоненти панелі управління приймають глобальні рішення щодо кластера (наприклад, планування), а також виявляють та реагують на події в кластері (наприклад, запуск нового <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='Репліки — це копії обʼєктів Pod, які забезпечують доступність, масштабованість і стійкість до відмов за рахунок утримання ідентичних екземплярів.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/reference/glossary/?all=true#term-replica' target='_blank' aria-label='replicas'>replicas</a>` в Deployment не виконується).

Компоненти панелі управління можуть запускатися на будь-якій машині у кластері. Однак для спрощення, скрипти налаштування зазвичай запускають всі компоненти панелі управління на одній машині та не запускають контейнерів користувача на цій машині. Див. [Створення кластерів з високою доступністю за допомогою kubeadm](/docs/setup/production-environment/tools/kubeadm/high-availability/) для прикладу налаштування панелі управління, яка працює на кількох машинах.

### kube-apiserver

<p>Сервер API є компонентом <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> Kubernetes, який надає доступ до API Kubernetes. Сервер API є фронтендом для панелі управління Kubernetes.</p>
<p>Основна реалізація сервера API Kubernetes — <a href="/docs/reference/generated/kube-apiserver/">kube-apiserver</a>. kube-apiserver спроєктований для горизонтального масштабування, тобто масштабується за допомогою розгортання додаткових екземплярів. Ви можете запустити кілька екземплярів kube-apiserver та балансувати трафік між ними.</p>

### etcd

<p>Надійне та високодоступне сховище ключ-значення, яке використовується як сховище Kubernetes для всіх даних кластера.</p>
<p>Якщо ваш кластер Kubernetes використовує etcd як основне сховище, переконайтеся, що у вас є <a href="/uk/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster">план резервного копіювання</a> даних.</p>
<p>Ви можете знайти докладну інформацію про etcd в офіційній <a href="https://etcd.io/docs/">документації</a>.</p>

### kube-scheduler

<p>Компонент панелі управління, що відстежує створені <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>, і обирає вузол, на якому вони працюватимуть.</p>
<p>При виборі вузла враховуються наступні фактори: індивідуальна і колективна потреба в <a class='glossary-tooltip' title='Визначений обсяг інфраструктури, доступний для споживання (процесор, памʼять тощо).' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/reference/glossary/?all=true#term-infrastructure-resource' target='_blank' aria-label='ресурсах'>ресурсах</a>, обмеження за апаратним/програмним забезпеченням і політиками, характеристики affinity та anti-affinity, локальність даних, сумісність робочих навантажень і граничні терміни виконання.</p>

### kube-controller-manager

<p>Компонент панелі управління, який запускає процеси <a class='glossary-tooltip' title='Контролер — цикл управління, що спостерігає за загальним станом кластера через apiserver і вносить зміни в намаганні наблизити поточний стан до бажаного.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/architecture/controller/' target='_blank' aria-label='контролера'>контролера</a>.</p>
<p>За логікою, кожен <a class='glossary-tooltip' title='Контролер — цикл управління, що спостерігає за загальним станом кластера через apiserver і вносить зміни в намаганні наблизити поточний стан до бажаного.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/architecture/controller/' target='_blank' aria-label='контролер'>контролер</a> є окремим процесом. Однак для спрощення їх збирають в один бінарний файл і запускають як єдиний процес.</p>

Існує багато різних типів контролерів. Деякі приклади:

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

Наведений вище список не є вичерпним.

### cloud-controller-manager

Компонент <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> Kubernetes, що інтегрує управління логікою певної хмари. Cloud controller manager дозволяє звʼязувати ваш кластер з API хмарного провайдера та відокремлює компоненти, що взаємодіють з хмарною платформою від компонентів, які взаємодіють тільки в кластері.

cloud-controller-manager запускає лише ті контролери, які специфічні для вашого хмарного провайдера. Якщо ви використовуєте Kubernetes у себе на власних потужностях або в навчальному середовищі всередині вашого ПК, кластер не матиме cloud-controller-manager.

Як і kube-controller-manager, cloud-controller-manager обʼєднує кілька логічно незалежних циклів керування в один бінарний файл, який ви запускаєте як один процес. Ви можете масштабувати його горизонтально (запускати більше однієї копії) для покращення продуктивності або для підвищення стійкості до збоїв.

Наступні контролери можуть мати залежності від хмарного провайдера:

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

---

## Компоненти вузлів {#node-components}

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

### kubelet

<p>Агент, запущений на кожному <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> кластера. Забезпечує запуск і роботу контейнерів в Podʼах.</p>
<p><a href="/uk/docs/reference/command-line-tools-reference/kubelet/">kubelet</a> використовує специфікації PodSpecs, які надаються за допомогою різних механізмів, і забезпечує працездатність і справність усіх контейнерів, що описані у PodSpecs. kubelet керує лише тими контейнерами, що були створені Kubernetes.</p>

### kube-proxy (опційно) {#kube-proxy}

<p>kube-proxy є мережевим проксі, що запущений на кожному вузлі кластера і реалізує частину концепції Kubernetes <a class='glossary-tooltip' title='Спосіб відкрити доступ до застосунку, що запущений на декількох Podʼах у вигляді мережевої служби.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/services-networking/service/' target='_blank' aria-label='Service'>Service</a>.</p>
<p><a href="/uk/docs/reference/command-line-tools-reference/kube-proxy/">kube-proxy</a> забезпечує підтримання мережевих правил на вузлах. Ці правила обумовлюють підключення мережею до ваших Podʼів всередині чи поза межами кластера.</p>
<p>kube-proxy використовує шар фільтрації пакетів операційної системи, за його наявності. В іншому випадку kube-proxy скеровує трафік самостійно.</p>

Якщо ви використовуєте [мережевий втулок](#network-plugins), який самостійно реалізує пересилання пакетів для сервісів та надає еквівалентну поведінку kube-proxy, то вам не потрібно запускати kube-proxy на вузлах вашого кластера.

### Рушій виконання контейнерів {#container-runtime}

<p>Основний компонент, який дозволяє Kubernetes ефективно запускати контейнери. Він відповідає за керування виконанням і життєвим циклом контейнерів у середовищі Kubernetes.</p>
<p>Kubernetes підтримує середовища виконання контейнерів, такі як <a class='glossary-tooltip' title='Середовище виконання контейнера з акцентом на простоту, надійність та переносимість.' data-bs-toggle='tooltip' data-bs-placement='top' href='https://containerd.io/docs/' target='_blank' aria-label='containerd'>containerd</a>, <a class='glossary-tooltip' title='CRI-O — це легке середовище виконання контейнерів, спеціально розроблене для Kubernetes.' data-bs-toggle='tooltip' data-bs-placement='top' href='https://cri-o.io/#what-is-cri-o' target='_blank' aria-label='CRI-O'>CRI-O</a>, та будь-яку іншу реалізацію <a href="https://github.com/kubernetes/community/blob/main/contributors/devel/sig-node/container-runtime-interface.md">Kubernetes CRI (інтерфейс виконання контейнерів)</a>.</p>

## Надбудови {#addons}

Надбудови використовують ресурси Kubernetes (<a class='glossary-tooltip' title='Забезпечує запуск копії обʼєкта Pod на певному наборі вузлів у кластері.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/workloads/controllers/daemonset' target='_blank' aria-label='DaemonSet'>DaemonSet</a>, <a class='glossary-tooltip' title='Керує реплікованим застосунком у вашому кластері.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/workloads/controllers/deployment/' target='_blank' aria-label='Deployment'>Deployment</a> тощо) для реалізації функцій кластера. Оскільки вони надають функції на рівні кластера, ресурси, що належать надбудовам, розміщуються в просторі імен `kube-system`.

Вибрані застосунки описані нижче; для розширеного списку доступних надбудов дивіться [Надбудови](/docs/concepts/cluster-administration/addons/).

### DNS

Хоча інші надбудови не є строго необхідними, всі кластери Kubernetes повинні мати [кластерний DNS](/docs/concepts/services-networking/dns-pod-service/), оскільки багато прикладів залежать від нього.

Кластерний DNS — це DNS-сервер, який доповнює інші DNS-сервери у вашому середовищі та обслуговує DNS-записи для сервісів Kubernetes.

Контейнери, запущені за допомогою Kubernetes, автоматично включають цей DNS-сервер у свої DNS-запити.

### Вебінтерфейс (Dashboard) {#web-ui-dashboard}

[Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/) — це універсальний вебінтерфейс для кластерів Kubernetes. Він дозволяє користувачам керувати та розвʼязувати проблеми з застосунками, що працюють у кластері, а також з самим кластером.

### Моніторинг ресурсів контейнерів {#container-resource-monitoring}

[Моніторинг ресурсів контейнерів](/docs/tasks/debug/debug-cluster/resource-usage-monitoring/) записує загальні метрики часу для контейнерів у центральну базу даних та надає інтерфейс для перегляду цих даних.

### Логування на рівні кластера {#cluster-level-logging}

Механізм [логування на рівні кластера](/docs/concepts/cluster-administration/logging/) відповідає за збереження логів контейнерів в центральному сховищі логів з інтерфейсом пошуку та перегляду.

### Мережеві втулки {#network-plugins}

[Мережеві втулки](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins) — це програмні компоненти, які реалізують специфікацію інтерфейсу мережі контейнерів (CNI). Вони відповідають за виділення IP-адрес Podʼам та забезпечення їх звʼязку між собою у кластері.

## Варіації архітектури {#architecture-variations}

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

### Варіанти розгортання панелі управління {#control-plane-deployment-options}

Компоненти панелі управління можна розгортати кількома способами:

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

Статичні Podʼи:
: Компоненти панелі управління розгортаються як статичні Podʼи, керовані kubelet на певних вузлах. Це поширений підхід, який використовують такі інструменти, як kubeadm.

Самообслуговування:
: Панель управління працює як Podʼи у самому кластері Kubernetes, яким керують Deployments та StatefulSets або інші примітиви Kubernetes.

Керовані сервіси Kubernetes:
: Хмарні провайдери часто абстрагують панель управління, керуючи її компонентами як частиною послуги, яку вони надають.

### Розміщення робочих навантажень {#workload-placement-considerations}

Розміщення робочих навантажень, включаючи компоненти панелі управління, може варіюватися залежно від розміру кластера, вимог до продуктивності та операційних політик:

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

### Інструменти управління кластером {#cluster-management-tools}

Такі інструменти, як kubeadm, kops та Kubespray, пропонують різні підходи до розгортання та управління кластерами, кожен з яких має свій метод розташування та управління компонентами.

### Налаштування та розширюваність {#customization-and-extensibility}

Архітектура Kubernetes дозволяє значну кастомізацію:

- Власні планувальники можна розгортати паралельно зі стандартним планувальником Kubernetes або замінювати його повністю.
- API-сервери можна розширювати за допомогою CustomResourceDefinitions та API Aggregation.
- Хмарні провайдери можуть глибоко інтегруватися з Kubernetes за допомогою cloud-controller-manager.

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

## Що далі

Дізнайтеся більше про:

- [Вузли](/docs/concepts/architecture/nodes/) та [їх комунікацію](/docs/concepts/architecture/control-plane-node-communication/) з панеллю управління.
- [Контролери](/docs/concepts/architecture/controller/) Kubernetes.
- [Збирання сміття (Garbage collection)](/docs/concepts/architecture/garbage-collection/) обʼєктів кластера.
- [kube-scheduler](/docs/concepts/scheduling-eviction/kube-scheduler/), який є стандартним планувальником для Kubernetes.
- Офіційну [документацію Etcd](https://etcd.io/docs/).
- Декілька [контейнерних рушіїв](/docs/setup/production-environment/container-runtimes/) у Kubernetes.
- Інтеграцію з хмарними провайдерами за допомогою [cloud-controller-manager](/docs/concepts/architecture/cloud-controller/).
- Команди [kubectl](/docs/reference/generated/kubectl/kubectl-commands/).

---

Section pages:

- [Вузли](/uk/docs/concepts/architecture/nodes/)
- [Звʼязок між Вузлами та Панеллю управління](/uk/docs/concepts/architecture/control-plane-node-communication/)
- [Контролери](/uk/docs/concepts/architecture/controller/)
- [Лізинг](/uk/docs/concepts/architecture/leases/)
- [Cloud Controller Manager](/uk/docs/concepts/architecture/cloud-controller/)
- [Про cgroup v2](/uk/docs/concepts/architecture/cgroups/)
- [Самовідновлення Kubernetes](/uk/docs/concepts/architecture/self-healing/)
- [Збір сміття](/uk/docs/concepts/architecture/garbage-collection/)
- [Проксі змішаних версій](/uk/docs/concepts/architecture/mixed-version-proxy/)