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

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

Контекст

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

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

Поведінка панелі управління

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

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

Поведінка вузла

Kubernetes автоматично розподіляє Podʼи для робочих ресурсів (таких як Deployment чи StatefulSet) по різних вузлах кластера. Це розподілення допомагає зменшити вплив відмов.

При запуску вузлів kubelet на кожному вузлі автоматично додає мітки до обʼєкта вузла який представляє цей конкретний kubelet в API Kubernetes. Ці мітки можуть включати інформацію про зону.

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

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

Розподіл вузлів по зонах

Ядро Kubernetes не створює вузли за вас; вам потрібно це зробити самостійно, або використовувати інструмент, такий як Cluster API, щоб керувати вузлами від вашого імені.

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

Ручне призначення зон для Podʼів

Ви можете застосовувати обмеження селектора вузла до Podʼів, які ви створюєте, а також до шаблонів Podʼів в робочих ресурсах таких як Deployment, StatefulSet або Job.

Доступ до ресурсів зберігання для зон

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

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

Ви можете вказати StorageClass для PersistentVolumeClaims, який вказує домени відмов (зони), які може використовувати сховище в цьому класі. Щоб дізнатися, як налаштувати StorageClass, який опікується доменами відмов або зонами, див. Дозволені топології.

Мережа

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

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

Відновлення після відмов

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

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

Що далі

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