Модуль 8.3: Мережева взаємодія між кластерами та регіонами

Складність: [COMPLEX] | Час на виконання: 3 год | Передумови: Просунуті хмарні мережі (Модуль 8.2), знання Kubernetes Services та Ingress

Чому цей модуль важливий

Липень 2022 року. Велика компанія з надання послуг таксі. Піковий трафік вечора п’ятниці.

Платформна команда розгорнула другий кластер Kubernetes у новому регіоні, щоб зменшити затримку для користувачів східного узбережжя. План був ідеальним: розділення трафіку через DNS, 10% Canary на новий регіон, поступове нарощування. Але вони не врахували сервіс-дискавері. Сервіс оплати в новому кластері мав викликати сервіс виявлення шахрайства, який працював тільки в оригінальному кластері. Команда жорстко прописала внутрішній ClusterIP сервісу шахрайства в налаштуваннях. Але ClusterIP не працюють між кластерами.

Швидке виправлення було жахливим: створили ExternalName сервіс, що вказував на балансувальник хмари, який гнав трафік через піринг. Затримка зросла з 12 мс до 89 мс. Таймаут оплати був 100 мс. Кожен п’ятий запит почав відпадати по таймауту, що система сприймала як “перевірка пройдена”. Кількість фейкових транзакцій зросла на 340% за вихідні, перш ніж це помітили.

Мережа між кластерами — це проблема, про яку ніхто не думає, доки не з’являється другий кластер. Тоді вона стає найгострішою проблемою. Цей модуль навчить вас моделей, інструментів та патернів для надійного зв’язку подів у різних кластерах та регіонах. Ви дізнаєтеся про різницю між плоскими та острівними мережами, навчитеся працювати з Cilium Cluster Mesh та Multi-Cluster Services API, а також розберетеся, як не збанкрутувати на Cross-AZ трафіку.

Моделі мережі: Flat vs Island

Коли у вас багато кластерів, у вас є фундаментальний вибір: поди мають бачити один одного за IP чи тільки через спеціальні “шлюзи”?

1. Flat Networking (Плоска мережа)

Кожен под у кожному кластері має унікальну, маршрутизовану IP-адресу.

Плюси: Максимальна простота для розробника. curl <pod-ip> працює між кластерами. Не потрібні складні проксі.
Мінуси: Вимагає суворого планування IP (IPAM). Не можна використовувати однакові діапазони адрес. Важко масштабувати (ліміти роутерів хмари).

2. Island Networking (Острівна мережа)

Кожен кластер — це окремий острів. IP-адреси подів можуть повторюватися в різних кластерах.

Плюси: Немає потреби в координації IP. Кластери повністю незалежні. Легше масштабувати до сотень штук.
Мінуси: Вища затримка. Кожен зв’язок між кластерами треба налаштовувати вручну через Ingress або Service Mesh.

Cilium Cluster Mesh

Cilium Cluster Mesh — це найзріліше рішення для об’єднання кластерів у єдину мережу. Він дозволяє подам бачити сервіси в інших кластерах так, ніби вони локальні.

Як це працює:

Кожен кластер має свій clustermesh-apiserver.
Агенти Cilium в одному кластері підключаються до API іншого кластера.
Global Services: Якщо ви створюєте сервіс з анотацією io.cilium/global-service: "true", Cilium сам балансує трафік між усіма копіями цього сервісу в усіх кластерах.

Multi-Cluster Services API (MCS)

Це офіційний стандарт Kubernetes для сервіс-дискавері між кластерами.

Ви робите ServiceExport у першому кластері.
Система автоматично створює ServiceImport у другому.
Ваш додаток звертається до імені my-service.namespace.svc.clusterset.local.
Це ім’я резолвиться в IP-адреси подів з УСІХ кластерів одночасно.

Глобальне балансування (Global Load Balancing)

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

Рішення	Як працює	Швидкість перемикання
DNS (Route53/Cloud DNS)	Віддає IP найближчого кластера	Повільно (залежить від TTL)
Anycast (Global Accelerator)	Одна IP на весь світ	Миттєво (< 10 сек)
Cloud CDN/Front Door	Кешує контент на межі мережі	Дуже швидко для статики

Типові помилки

Помилка	Чому це стається	Як виправити
Однакові IP подів у плоскій мережі	Забули про IPAM	Завжди виділяйте унікальні CIDR для кожного нового кластера заздалегідь
Жорсткі ClusterIP у конфігах	Працювало в одному кластері	Використовуйте DNS імена та стандарт `.clusterset.local`
Ігнорування ціни трафіку	Передача між регіонами дорога	Використовуйте `topology-aware routing`, щоб под шукав сервіс спочатку у своїй зоні/кластері
Відсутність Health Checks між кластерами	Надія на стабільність хмари	Завжди налаштовуйте активні перевірки здоров’я для всіх крос-кластерних ендпоінтів

Тест

1. Чому для великої кількості кластерів (напр. 50+) краще обирати Island модель мережі?

Тому що керувати унікальними IP-адресами для тисяч подів у плоскій мережі стає неможливо. Ви швидко вичерпаєте адресний простір хмари і впертися в ліміти таблиць маршрутизації роутерів. Island модель дозволяє кожному кластеру бути автономним.

2. Що таке 'Consumer Lag' у контексті мультикластерної мережі?

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

Практична вправа: Створення Cluster Mesh

Створіть два кластери (kind) з різними діапазонами IP для подів (напр. 10.1.0.0/16 та 10.2.0.0/16).
Встановіть Cilium в обох кластерах.
Об’єднайте їх у Mesh за допомогою команди cilium clustermesh connect.
Створіть глобальний сервіс frontend.
Зробіть запит із першого кластера і переконайтеся, що ви іноді отримуєте відповіді від подів із другого кластера.

Наступний модуль

Мережа налаштована, тепер час розібратися з правами доступу. Переходьте до Модуля 8.4: Крос-акаунт IAM та корпоративна ідентичність — ми навчимося будувати межі довіри, які не стають перешкодою для розробки.