# Запуск у кількох зонах

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

---

<!-- overview -->

Ця сторінка описує запуск Kubernetes у кількох зонах відмов.

<!-- body -->

## Контекст {#background}

Kubernetes створено так, що один кластер Kubernetes може працювати у кількох зонах відмов, зазвичай там, де ці зони вписуються в логічну групу, яку називають _регіоном_. Основні постачальники хмар визначають регіон як набір зон відмов (також називають _зонами доступності_), які надають однаковий набір функцій: в межах регіону кожна зона пропонує ті самі API та сервіси.

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

## Поведінка панелі управління {#control-plane-behavior}

Усі [компоненти панелі управління](/docs/concepts/architecture/#control-plane-components) підтримують роботу як пул взаємозамінних ресурсів, реплікованих для кожного компонента.

При розгортанні панелі управління кластера розміщуйте репліки компонентів панелі управління в різних зонах відмов. Якщо доступність важлива, виберіть принаймні три зони відмов і реплікуйте кожен окремий компонент панелі управління (API-сервер, планувальник, etcd, менеджер контролерів кластера) принаймні в трьох зонах відмов. Якщо ви використовуєте менеджер хмарного контролера, вам також слід повторити це у всіх вибраних вами зонах відмови.


<div class="alert alert-info" role="note"><h4 class="alert-heading">Примітка:</h4>Kubernetes не забезпечує міжзонну стійкість для точок доступу сервера API. Ви можете використовувати різні методи для підвищення доступності сервера API кластера, включаючи круговий огляд DNS, записи SRV або стороннє рішення для балансування навантаження з перевіркою працездатності.</div>


## Поведінка вузла {#node-behavior}

Kubernetes автоматично розподіляє Podʼи для робочих ресурсів (таких як <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> чи <a class='glossary-tooltip' title='StatefulSet керує розгортанням і масштабуванням групи обʼєктів Pod з постійним сховищем та постійними ідентифікаторами для кожного обʼєкта Pod.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/workloads/controllers/statefulset/' target='_blank' aria-label='StatefulSet'>StatefulSet</a>) по різних вузлах кластера. Це розподілення допомагає зменшити вплив відмов.

При запуску вузлів kubelet на кожному вузлі автоматично додає <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> до обʼєкта вузла, який представляє цей конкретний kubelet в API Kubernetes. Ці мітки можуть включати [інформацію про зону](/docs/reference/labels-annotations-taints/#topologykubernetesiozone).

Якщо ваш кластер охоплює кілька зон або регіонів, ви можете використовувати мітки вузла разом з [обмеженнями розподілу топології для Podʼів](/docs/concepts/scheduling-eviction/topology-spread-constraints/), щоб керувати тим, як Podʼи розподіляються по вашому кластеру серед доменів відмови: регіони, зони, і навіть конкретні вузли. Ці підказки дозволяють <a class='glossary-tooltip' title='Компонент панелі управління, що відстежує створені Podʼи, які ще не розподілені по вузлах, і обирає вузол, на якому вони працюватимуть.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/reference/generated/kube-scheduler/' target='_blank' aria-label='планувальнику'>планувальнику</a> розміщувати Podʼи для забезпечення кращої очікуваної доступності, зменшуючи ризик того, що пошкодження вашого навантаження вплине на весь робочий процес.

Наприклад, ви можете встановити обмеження, щоб забезпечити, що 3 репліки StatefulSet працюють у різних зонах, коли це є можливим. Ви можете визначити це декларативно не вказуючи явно, які зони доступності використовуються для кожного робочого навантаження.

### Розподіл вузлів по зонах {#distributing-nodes-across-zones}

Ядро Kubernetes не створює вузли за вас; вам потрібно це зробити самостійно, або використовувати інструмент, такий як [Cluster API](https://cluster-api.sigs.k8s.io/), щоб керувати вузлами від вашого імені.

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

## Ручне призначення зон для Podʼів {#manually-zone-assignment-for-pods}

Ви можете застосовувати [обмеження селектора вузла](/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector) до Podʼів, які ви створюєте, а також до шаблонів Podʼів в робочих ресурсах таких як Deployment, StatefulSet або Job.

## Доступ до ресурсів зберігання для зон {#storage-access-for-zones}

При створенні постійних томів, Kubernetes автоматично додає мітки зони до будь-яких PersistentVolumes, які повʼязані з конкретними зонами. Потім <a class='glossary-tooltip' title='Компонент панелі управління, що відстежує створені Podʼи, які ще не розподілені по вузлах, і обирає вузол, на якому вони працюватимуть.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/reference/generated/kube-scheduler/' target='_blank' aria-label='планувальник'>планувальник</a> переконується, через свій предикат `NoVolumeZoneConflict`, що Podʼи, які вимагають певного постійного тому, розміщуються тільки в тій самій зоні, що й цей том.

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

Ви можете вказати <a class='glossary-tooltip' title='StorageClass надає можливість адміністраторам описати різні доступні типи сховищ.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/storage/storage-classes' target='_blank' aria-label='StorageClass'>StorageClass</a> для PersistentVolumeClaims, який вказує домени відмов (зони), які може використовувати сховище в цьому класі. Щоб дізнатися, як налаштувати StorageClass, який опікується доменами відмов або зонами, див. [Дозволені топології](/docs/concepts/storage/storage-classes/#allowed-topologies).

## Мережа {#networking}

Сам по собі Kubernetes не містить мережі, яка знається на зонах. Ви можете використовувати [мережевий втулок](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) для налаштування мережі кластера, і це мережеве рішення може мати елементи, специфічні для зони. Наприклад, якщо ваш постачальник хмари підтримує Сервіси з `type=LoadBalancer`, балансувальник може переспрямовувати трафік лише до Podʼів, які працюють в тій же зоні, що й елемент балансування навантаження, який обробляє ці зʼєднання. Перевірте документацію вашого постачальника хмари для отримання деталей.

Для власних або для розгортань на локальних обчислювальних ресурсах застосовуються подібні міркування. Поведінка <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> та <a class='glossary-tooltip' title='Обʼєкт API, який управляє зовнішнім доступом до служб в кластері, зазвичай HTTP.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/services-networking/ingress/' target='_blank' aria-label='Ingress'>Ingress</a>, включаючи обробку
різних зон відмов, різняться залежно від того, як саме налаштований ваш кластер.

## Відновлення після відмов {#fault-recovery}

При налаштуванні кластера можливо вам також доведеться розглядати можливість та способи відновлення обслуговування, якщо всі зони відмов у регіоні вийдуть з ладу одночасно. Наприклад, чи ви покладаєтесь на те, що принаймні один вузол може виконувати Podʼи в зоні? Переконайтеся, що будь-які роботи з ремонту, критичні для кластера, не покладаються на те, що у вашому кластері є принаймні один справний вузол. Наприклад: якщо всі вузли несправні, вам може знадобитися запустити роботу з ремонту з особливим <a class='glossary-tooltip' title='Основний обʼєкт, що складається з трьох обовʼязкових властивостей: key, value, та effect. Toleration (дозвіл) дозволяє розміщення Podʼів на вузлах чи групах вузлів, які мають відповідні taint.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/scheduling-eviction/taint-and-toleration/' target='_blank' aria-label='Toleration'>Toleration</a>, щоб ремонт міг завершити роботу, щоб принаймні один вузол був в робочому стані.

Kubernetes не має відповіді на це виклик; однак це те, що варто враховувати.

## Що далі

Щоб дізнатися, як планувальник розміщує Podʼи в кластері, дотримуючись налаштованих обмежень, відвідайте розділ [Планування та Виселення](/docs/concepts/scheduling-eviction/).