Ласкаво просимо до серії коротких посібників з Kubernetes. Це регулярна колонка з найцікавішими питаннями, які ми отримуємо онлайн та на наших тренінгах. Відповідає експерт з Kubernetes.
Сьогоднішній експерт - Даніель Поленчик (). Даніель працює інструктором та розробником ПЗ у .
Якщо ви хочете отримати відповідь на своє запитання у наступному пості, або у .
Чи пропустили попередні пости? .
Як поєднати кластери Kubernetes у різних дата-центрах?
коротко: , а ще раджу почитати про и .
Досить часто інфраструктура реплікується та розподіляється по різних регіонах, особливо у контрольованих середовищах.
Якщо один регіон недоступний, трафік перенаправляється в інший, щоб уникнути перебоїв.
З Kubernetes можна використовувати схожу стратегію та розподіляти робочі навантаження по різних регіонах.
У вас може бути один або кілька кластерів на команду, регіон, середу або комбінацію цих елементів.
Ваші кластери можуть розміщуватися в різних хмарах та в локальному середовищі.
Але як спланувати інфраструктуру для такого географічного розкиду?
Чи потрібно створити один великий кластер на кілька хмарних середовищ по єдиній мережі?
Або завести багато маленьких кластерів та знайти спосіб контролювати та синхронізувати їх?
Один керівний кластер
Створити один кластер по єдиній мережі не так просто.
Уявіть, у вас аварія, втрачено зв'язок між сегментами кластера.
Якщо у вас один майстер-сервер, то половина ресурсів не зможуть отримувати нові команди, тому що їм не вдасться зв'язатися з майстром.
І при цьому у вас старі таблиці маршрутизації (kube-proxy не може завантажити нові) і ніяких додаткових pod'ів (kubelet не може вимагати оновлення).
Що ще гірше, якщо Kubernetes не бачить вузол, він позначає його як втрачений і розподіляє відсутні під'ї по існуючих вузлах.
У результаті pod'ів у вас вдвічі більше.
Якщо ви зробите по одному майстер-серверу на кожен регіон, будуть проблеми з алгоритмом досягнення консенсусу бази даних etcd. (прим. ред. — Насправді база даних etcd не обов'язково має перебувати на майстер-серверах. Її можна запустити в окремій групі серверів в одному регіоні. Щоправда, отримавши у своїй точку відмови кластера. Проте швидко.)
etcd використовує , щоб узгодити значення, перш ніж записати його на диск.
Тобто більшість екземплярів мають досягти консенсусу, перш ніж стан можна буде записати в etcd.
Якщо затримка між екземплярами etcd різко зростає, як у випадку з трьома екземплярами etcd у різних регіонах, потрібно багато часу, щоб узгодити значення та записати його на диск.
Це відбивається і на контролерах Kubernetes.
Менеджеру контролерів потрібно більше часу, щоб дізнатися про зміну та записати відповідь до бази даних.
А якщо контролер не один, а кілька, виходить ланцюгова реакція, і весь кластер починає працювати дуже повільно.
etcd настільки чутливий до затримки, що .
Зараз немає хороших прикладів великої мережі одного кластера.
В основному, спільнота розробників та група SIG-cluster намагаються зрозуміти, як оркеструвати кластери так само, як Kubernetes оркеструє контейнери.
Варіант 1: федерація кластерів з kubefed
Офіційна відповідь від SIG-cluster .
Вперше керувати колекцією кластерів як єдиним об'єктом намагалися за допомогою інструменту kube federation.
Початок був добрим, але в результаті kube federation так і не став популярним, тому що підтримував не всі ресурси.
Він підтримував об'єднані постачання та послуги, але, наприклад, не державніпідприємства.
Натомість зміна федерації передавалася як інструкцій і відрізнялася гнучкістю.
Уявіть собі, як можна описати поділ реплік кожного кластера у федерації з допомогою одних анотацій.
Вийшов повний безлад.
SIG-cluster виконали велику роботу після kubefed v1 і вирішили підійти до проблеми з іншого боку.
Замість анотацій вони вирішили випустити контролер, який встановлюється кластерами. Його можна налаштовувати за допомогою визначень ресурсів (Custom Resource Definition, CRD).
Для кожного ресурсу, який буде входити до федерації, у вас є визначення CRD користувача з трьох розділів:
- стандартне визначення ресурсу, наприклад, деплой;
- розділ
placement, де ви визначаєте, як ресурс розподілятиметься у федерації; - розділ
override, де для конкретного ресурсу можна перевизначити вагу та параметри із placement.
Ось приклад об'єднаного постачання з розділами placement та override.
apiVersion: types.federation.k8s.io/v1alpha1
kind: FederatedDeployment
metadata:
name: test-deployment
namespace: test-namespace
spec:
template:
metadata:
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- image: nginx
name: nginx
placement:
clusterNames:
- cluster2
- cluster1
overrides:
- clusterName: cluster2
clusterOverrides:
- path: spec.replicas
value: 5Як бачите, поставка розподілена за двома кластерами: cluster1 и cluster2.
Перший кластер поставляє три репліки, а другий вказано значення 5.
Якщо вам потрібно більше контролю над кількістю реплік, kubefed2 надає новий об'єкт ReplicaSchedulingPreference, де репліки можна розподіляти за вагою:
apiVersion: scheduling.federation.k8s.io/v1alpha1
kind: ReplicaSchedulingPreference
metadata:
name: test-deployment
namespace: test-ns
spec:
targetKind: FederatedDeployment
totalReplicas: 9
clusters:
A:
weight: 1
B:
weight: 2Структура CRD і API ще зовсім готові, й у офіційному репозиторії проекту ведеться активна робота.
Слідкуйте за kubefed2, але пам'ятайте, що для робочого середовища він поки не годиться.
Дізнайтесь більше про kubefed2 з у блозі про Kubernetes та в .
Варіант 2: об'єднання кластерів у стилі Booking.com
Розробники Booking.com не займалися kubefed v2, зате придумали Shipper — оператор для постачання на кількох кластерах, кількох регіонах та кількох хмарах.
чимось схожий на kubefed2.
Обидва інструменти дозволяють налаштовувати стратегію розгортання на кількох кластерах (які кластери використовують і скільки у них реплік).
Але Завдання Shipper - знизити ризик помилок при постачанні.
У Shipper можна визначити ряд кроків, які описують поділ реплік між попереднім та поточним деплоєм та обсяг вхідного трафіку.
Коли ви надсилаєте ресурс до кластера, контролер Shipper покроково розгортає цю зміну по всіх об'єднаних кластерах.
А ще Shipper дуже обмежений.
Наприклад, він приймає Helm-чарти як вхідні дані та не підтримує vanilla ресурси.
Загалом, Shipper працює наступним чином.
Замість стандартного постачання потрібно створити ресурс програми, що включає Helm-чарт:
apiVersion: shipper.booking.com/v1alpha1
kind: Application
metadata:
name: super-server
spec:
revisionHistoryLimit: 3
template:
chart:
name: nginx
repoUrl: https://storage.googleapis.com/shipper-demo
version: 0.0.1
clusterRequirements:
regions:
- name: local
strategy:
steps:
- capacity:
contender: 1
incumbent: 100
name: staging
traffic:
contender: 0
incumbent: 100
- capacity:
contender: 100
incumbent: 0
name: full on
traffic:
contender: 100
incumbent: 0
values:
replicaCount: 3Shipper непоганий варіант для керування кількома кластерами, але його тісний зв'язок з Helm тільки заважає.
А раптом ми всі перейдемо з Helm на або ?
Дізнайтеся більше про Shipper та його філософію у .
Якщо хочете покопатися в коді, .
Варіант 3: магічне об'єднання кластерів
Kubefed v2 і Shipper працюють з федерацією кластерів, надаючи кластерам нові ресурси через визначення визначення ресурсів.
Але раптом ви не хочете переписувати всі поставки, StatefulSets, DaemonSets і т. д. для об'єднання?
Як включити існуючий кластер до федерації, не змінюючи YAML?
, який займається робочими навантаженнями планування у кластерах.
Але замість того, щоб вигадувати новий спосіб взаємодії з кластером і обертати ресурси в користувацькі визначення, multi-cluster-scheduler впроваджується в стандартний життєвий цикл Kubernetes і перехоплює всі виклики, які створюють поди.
Кожен створюваний під відразу замінюється на пустушку.
multi-cluster-scheduler використовує , щоб перехопити виклик і створити недіючий pod-пустушку.
Вихідний pod проходить ще через один цикл планування, де після опитування всієї федерації приймається рішення про розміщення.
Нарешті, ПД поставляється в цільовий кластер.
У результаті у вас зайвий pod, який нічого не робить, просто займає місце.
Перевага в тому, що вам не довелося писати нові ресурси для об'єднання постачання.
Кожен ресурс, що створює pod, автоматично готовий до об'єднання.
Це цікаво, адже у вас раптом з'являються постачання, розподілені кількома регіонами, а ви й не помітили. Втім, це досить ризиковано, адже тут усе тримається на магії.
Але якщо Shipper намагається, в основному, пом'якшити наслідки поставок, multi-cluster-scheduler виконує загальніші завдання і, можливо, краще підходить для пакетних завдань.
Він не має просунутого механізму поступових поставок.
Більше про multi-cluster-scheduler можна дізнатися на .
Якщо хочете прочитати про multi-cluster-scheduler у дії, Admiralty має - Робочими процесами, подіями, CI та CD Kubernetes.
Інші інструменти та рішення
Поєднання кількох кластерів та управління ними – складне завдання, універсального рішення не існує.
Якщо ви хочете докладніше вивчити цю тему, ось вам кілька ресурсів:
- - Інструмент, що з'єднує оверлей-мережі різних кластерів Kubernetes.
- Роздрібна мережа Target використовує .
- Спробуйте використати IPV6 та .
- Можна використовувати service mesh, наприклад .
- Cilium, плагін інтерфейсу мережі контейнерів, пропонує яка дозволяє поєднувати кілька кластерів
Ось і все на сьогодні
Дякую, що дочитали до кінця!
Якщо ви знаєте, як ефективніше з'єднати кілька кластерів, .
Ми додамо ваш спосіб до посилань.
Особлива подяка Крісу Несбітту-Сміту () та Венсану де Сме () (інженеру з надійності в ) за те, що прочитали статтю та поділилися корисною інформацією про те, як працює федерація.
Джерело: habr.com