Модуль 10.7: Мультихмарний Service Mesh (Istio Multi-Cluster)

Складність: [COMPLEX] | Час на виконання: 3 год | Передумови: Мережі Kubernetes, основи Service Mesh, Гібридна хмарна архітектура (Модуль 10.4)

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

У жовтні 2023 року велика технологічна компанія мала два кластери Kubernetes: основний в AWS (США) та резервний у Google Cloud (Європа). Коли в регіоні AWS стався частковий збій мережі, їхній план аварійного відновлення — ручне перемикання DNS на Google Cloud — зайняв 43 хвилини. Протягом цих 43 хвилин сервіс був недоступний для 12 мільйонів користувачів. Аналіз показав, що затримка сталася через потребу в координації між трьома різними командами. Збитки оцінили у $3.8 мільйона втраченого доходу.

Після інциденту вони впровадили Istio Multi-Cluster. Тепер трафік автоматично розподіляється між хмарами. Коли сервіс в AWS стає “хворим”, Istio сам перенаправляє запити на кластер у Google Cloud — без змін у DNS, без дзвінків о 3 годині ночі і без 43-хвилинного очікування. Наступний збій у хмарі (через два місяці) пройшов непомітно для користувачів: перемикання відбулося за 8 секунд.

Цей модуль навчить вас будувати такі системи. Ви вивчите топології мультикластерного Istio, навчитеся налаштовувати спільну довіру (mTLS) між різними хмарами через SPIFFE/SPIRE, опануєте маршрутизацію з урахуванням локації (locality-aware routing) та навчитеся виправляти складні помилки зв’язку між кластерами.

Топології Istio Multi-Cluster

Є два основні способи з’єднати кластери в єдину мережу.

1. Primary-Remote

Один кластер є “головним” (Primary) — він тримає площину управління Istiod. Інші кластери (Remote) підключаються до нього.

Плюс: Легко керувати (один конфиг).
Мінус: Якщо головний кластер впаде — управління мережею в усіх кластерах зупиниться.
Для чого: сценарії Disaster Recovery (DR).

2. Multi-Primary (Рекомендовано для продакшну)

Кожен кластер має свій власний Istiod. Вони просто обмінюються інформацією про сервіси.

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

Спільна довіра: Shared Root CA

Щоб под в Amazon міг безпечно спілкуватися з подом у Google Cloud через mTLS, вони мають довіряти один одному. Для цього ви створюєте єдиний кореневий сертифікат (Root CA) для всієї компанії.

Ви генеруєте Root CA в безпечному місці (напр. Vault).
Видаєте кожному кластеру свій проміжний сертифікат (Intermediate CA), підписаний цим коренем. Результат: Будь-який сервіс у будь-якій хмарі може перевірити особу іншого сервісу.

East-West Gateway: Міст між хмарами

Стандартний Ingress (North-South) приймає трафік з інтернету. East-West Gateway — це спеціальний вхід тільки для інших кластерів вашої мережі.

Трафік іде через mTLS.
Використовується режим AUTO_PASSTHROUGH: шлюз не розшифровує дані, а лише пересилає їх на потрібний под у своєму кластері.

Locality-Aware Load Balancing

Це “розумне” балансування трафіку:

Якщо сервіс є у вашому кластері — запит іде до нього (це швидко і безкоштовно).
Якщо локальний сервіс видає помилки — Istio автоматично відправляє 10% запитів у сусідню хмару.
Якщо локальний сервіс “помер” зовсім — 100% трафіку іде в іншу хмару.

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

Помилка	Чому це стається	Як виправити
Різні Root CA	Кластери створювалися окремо	Створіть єдиний Root CA перед встановленням Istio в обох кластерах
Закритий порт 15443	Файрвол блокує East-West трафік	Відкрийте порт 15443 (mTLS) між хмарами у групах безпеки
Немає Outlier Detection	Istio не бачить, що сусід впав	Завжди налаштовуйте `outlierDetection` у DestinationRule, щоб вчасно перемикати трафік
Strict mTLS для Health Checks	Балансувальник не вміє в mTLS	Налаштуйте виключення для портів перевірки здоров’я в `PeerAuthentication`

Тест

1. Чому для мультихмарної мережі потрібен саме East-West Gateway, а не звичайний Ingress?

Тому що ми хочемо зберегти наскрізне шифрування (end-to-end mTLS) між подами в різних хмарах. Звичайний Ingress зазвичай розшифровує трафік на вході. East-West Gateway працює в режимі пропуску (passthrough), дозволяючи подам “домовитися” про безпеку самостійно.

2. Як Istio в одній хмарі дізнається про поди в іншій хмарі?

Ви створюєте Remote Secret. Це спеціальний файл, який дає право вашому Istiod читати список сервісів та подів із API іншого кластера. Це як “телефонна книга” іншої хмари.

Практична вправа: Cross-Cloud Failover

Розгорніть два кластери (simulated) і встановіть Istio в режимі Multi-Primary.
Спроектуйте DestinationRule для сервісу payments з налаштуванням localityLbSetting.
Налаштуйте outlierDetection, щоб под вимикався після 3 помилок поспіль.
Симулюйте збій у першій хмарі (напр. видаліть усі поди сервісу).
Перевірте, через скільки секунд трафік почне надходити до другої хмари.

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

Ви з’єднали сервіси, тепер час навести лад у деплоях. Переходьте до Модуля 10.8: Корпоративний GitOps та платформна інженерія — ми навчимося використовувати Backstage та ArgoCD для управління розгортаннями на сотні кластерів одночасно.