Модуль 10.5: Управління мультихмарним флотом (Azure Arc / GKE Fleet)

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

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

Наприкінці 2023 року велика торгова компанія керувала 73 кластерами Kubernetes у трьох хмарах та двох дата-центрах. Кожен кластер мав свій власний конвеєр деплою, свій моніторинг та свою команду підтримки. Коли вийшла новина про критичну вразливість в API-сервері Kubernetes (CVE-2023-5528), команді безпеки знадобилося 11 днів, щоб просто зрозуміти, які саме кластери під загрозою. На виправлення пішло 6 тижнів, і за цей час виявилося, що 9 кластерів працювали на версіях, які вже не отримували оновлень безпеки. Ніхто цього не помічав, бо не було єдиного вікна управління.

Цей інцидент показав головну проблему: у компанії були окремі кластери, але не було флоту. Кожен кластер був “домашнім улюбленцем” із власним характером. Не було централізованого реєстру, не було способу змінити правила безпеки для всіх одночасно і не було єдиного дашборда здоров’я.

Інструменти управління флотом (Fleet Management) вирішують це, дозволяючи ставитися до всієї вашої інфраструктури як до єдиного цілого. Azure Arc, Google Fleet (GKE Enterprise) та Rancher Fleet надають централізований інвентар, розповсюдження політик та єдиний GitOps на всі кластери, незалежно від того, де вони запущені.

У цьому модулі ви дізнаєтеся про реальність мультихмарності, навчитеся підключати кластери до Azure Arc та Google Fleet, налаштуєте централізований збір метрик та впровадите GitOps для управління сотнями кластерів у масштабі.

Реальність мультихмарності: Навіщо це потрібно?

Більшість компаній опиняються в мультихмарі не через стратегію, а через обставини:

Поглинання: Купили компанію, яка використовує іншу хмару.
Best-of-breed: ML-команда хоче Google Vertex AI, а основний сайт працює в AWS EKS.
Закони: Дані клієнтів із ЄС мають лежати в регіоні, який краще підтримує конкретний провайдер.

Пам’ятайте: Мультихмарність множить ваші операційні витрати у 2-3 рази. Вам потрібно більше людей, більше навчання та складніші інструменти. Використовуйте її тільки тоді, коли переваги реально переважають витрати.

Azure Arc для Kubernetes

Azure Arc — це “міст”, який підключає будь-який кластер до панелі управління Microsoft Azure.

Як це працює:

Ви ставите агент у свій кластер (напр. в EKS).
Агент встановлює вихідне з’єднання (HTTPS) з Azure. Жодних відкритих портів ззовні не потрібно.
Кластер з’являється в порталі Azure як звичайний ресурс.
Тепер ви можете застосовувати Azure Policy та Microsoft Defender до кластера в Amazon або Google.

Google Fleet (GKE Enterprise)

Google використовує концепцію “Флоту” (Fleet) — логічного об’єднання кластерів.

Fleet Features:

Config Sync: Ви кладете YAML у Git, а Google сам розкочує його на всі 50 кластерів флоту.
Policy Controller: Забороняє небезпечні дії на рівні всього флоту (на базі OPA).
Multi-Cluster Service Mesh: Дозволяє сервісам у різних хмарах спілкуватися між собою через захищений mTLS.

Централізована телеметрія

Флот без єдиного моніторингу — це набір сліпих зон. Використовуйте OpenTelemetry Collector на кожному кластері. Він має додавати мітки:

cluster.name
cluster.provider (aws/azure/gcp)
cluster.region Всі ці дані мають стікатися в єдиний Central Telemetry Hub (напр. Managed Prometheus або Grafana Cloud).

Multi-Cloud GitOps у масштабі

Для управління флотом недостатньо мати один ArgoCD. Вам потрібні ArgoCD ApplicationSets. ApplicationSet — це генератор. Він “дивиться” на ваш список кластерів у реєстрі і сам створює 50 копій вашого додатка для кожного кластера, враховуючи специфіку (напр. в AWS використовувати ECR, в Azure — ACR).

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

Помилка	Чому це стається	Як виправити
Хаотичне підключення	Реєстрація кластерів без тегів	Визначте правила іменування та обов’язкові теги (team, environment) заздалегідь
Однакова конфігурація для всіх	”Хай всюди буде стандарт”	Використовуйте патерн base/overlay: загальні правила в base, специфічні для хмари — в overlay
Ігнорування ціни трафіку	Централізовані логи дуже дорогі	Агрегуйте та фільтруйте дані прямо на кластері перед відправкою в центр
Тільки один рівень управління	Спроба керувати всім із хмари	Fleet-інструменти для політик, але специфічні речі (напр. диски) — через локальні інструменти

Тест

1. Чим архітектурно відрізняється підключення Azure Arc від прямого VPN-з'єднання?

Azure Arc не потребує VPN. Агент у кластері сам ініціює вихідне з’єднання з хмарою. Це безпечніше, бо вам не треба відкривати вхід у вашу мережу, і це працює через звичайний інтернет.

2. Навіщо використовувати ArgoCD ApplicationSets замість звичайних Applications для флоту?

Звичайний Application деплоїть один додаток в один кластер. ApplicationSet дозволяє автоматизувати деплой на сотні кластерів за шаблоном. Якщо ви додасте новий кластер у флот, ApplicationSet сам помітить це і автоматично встановить туди весь потрібний софт.

Практична вправа: Створення інвентарю флоту

Підключіть три кластери (можна симулювати через kind) до вашої системи управління (ArgoCD або Arc).
Додайте теги: provider та environment.
Налаштуйте ApplicationSet, який встановить metrics-server тільки на кластери з тегом environment: production.
Створіть дашборд, який показує сумарну кількість вузлів у всьому флоті, згруповану за хмарними провайдерами.

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

Ви навчилися керувати флотом, тепер час навчитися створювати його автоматично. Переходьте до Модуля 10.6: Мультихмарний провіженінг з Cluster API — ми вивчимо стандарт CAPI для створення та оновлення кластерів за допомогою звичайних YAML-файлів.