Модуль 10.6: Мультихмарний провіженінг з Cluster API

Складність: [COMPLEX] | Час на виконання: 3 год | Передумови: Управління мультихмарним флотом (Модуль 10.5), Custom Resources у Kubernetes, основи Infrastructure as Code

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

На початку 2024 року фінтех-компанія з 28 кластерами Kubernetes в AWS, Azure та в офісі потрапила в кризу. Їхня матриця версій виглядала як фільм жахів: 6 кластерів на 1.28, 9 на 1.29, 8 на 1.30 та 2 на 1.27 (яка вже не отримувала оновлень безпеки). Кожен кластер створювався по-своєму: хтось використовував eksctl, хтось — Terraform, хтось — скрипти Azure CLI, а офісні кластери — kubeadm. Оновлення одного кластера займало у інженера 2-4 дні, бо кожна система мала свою процедуру, свій стан та свої помилки.

Коли прийшов час оновлюватися на 1.32, команда підрахувала, що це займе 56-112 людино-годин. У них було всього 6 інженерів. Математика не сходилася. Тим часом старі кластери збирали критичні вразливості щодня.

Cluster API (CAPI) створений саме для цієї проблеми. Замість використання десятка різних інструментів, CAPI дає єдиний, Kubernetes-нативний API для створення та оновлення кластерів у будь-якій хмарі. Ви описуєте бажаний кластер у YAML-файлі, а контролери CAPI самі роблять так, щоб реальність відповідала опису. Оновлення 28 кластерів перетворюється на зміну версії в 28 файлах і спостереження за автоматичним процесом.

У цьому модулі ви вивчите, як працює Cluster API, як його провайдери (CAPA для AWS, CAPZ для Azure, CAPG для Google) спілкуються з хмарами, як керувати всім життєвим циклом кластера декларативно та як масштабувати CAPI для потреб великої компанії.

Як працює Cluster API

CAPI ставиться до кластерів так само, як Kubernetes ставиться до подів: як до ресурсів, якими керують контролери. У вас є керуючий кластер (management cluster), на якому працюють контролери CAPI, і вони створюють та лікують робочі кластери (workload clusters) у цільовій інфраструктурі.

Основні ресурси:

Cluster: головний об’єкт, що описує мережу та загальні налаштування.
Machine: опис одного віртуального сервера.
MachineDeployment: аналог Deployment для серверів (масштабування вузлів).
MachineHealthCheck: автоматична детекція та заміна “хворих” вузлів.

Провайдери інфраструктури: CAPA, CAPZ, CAPG

Кожна хмара має свого провайдера, який перекладає команди CAPI на мову API провайдера.

1. CAPA (AWS)

Підтримує два режими:

Managed: створення кластерів Amazon EKS.
Unmanaged: встановлення чистого Kubernetes на віртуальні машини EC2.

2. CAPZ (Azure)

Дозволяє керувати AKS кластерами або створювати власні кластери на базі Azure VMs.

Життєвий цикл кластера

Декларативне оновлення

Головна перевага CAPI. Ви міняєте version: v1.31.0 на version: v1.32.0 у маніфесті ControlPlane.

CAPI створює новий сервер із новою версією.
Додає його в кластер.
Поступово видаляє старі сервери (Rolling Upgrade). Увесь процес відбувається автоматично і без перерви в роботі ваших додатків.

MachineHealthCheck: Самовідновлення

Якщо сервер у кластері “завис” або видає помилки на диску, MachineHealthCheck помітить це через 5 хвилин, видалить несправний сервер і запустить новий такий самий. Жодного ручного втручання не потрібно.

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

Помилка	Чому це стається	Як виправити
Керуючий кластер у тій же хмарі	Спроба зекономити ресурси	Якщо ваша хмара “впаде”, ви не зможете лікувати її кластери. Тримайте керуючий кластер окремо
Немає бекапів etcd керуючого кластера	”Це ж просто панель управління”	Втрата etcd керуючого кластера означає втрату управління ВСІМ флотом. Робіть бекапи в S3 кожні 6 годин
Ручні правки на робочих кластерах	”Треба швидко підправити вузол”	CAPI автоматично затре ваші зміни при наступному циклі перевірки. Міняйте тільки шаблони
Відсутність MachineHealthCheck	Спадщина традиційного підходу	Завжди налаштовуйте автоматичні перевірки здоров’я вузлів

Тест

1. Що станеться з моїми додатками, якщо керуючий кластер CAPI вимкнеться?

Нічого поганого. Ваші робочі кластери (workload clusters) продовжать працювати, поди будуть приймати трафік. Ви просто не зможете створювати нові кластери, масштабувати існуючі вузли або робити оновлення версій, поки не відновите керуючий кластер.

2. У чому різниця між MachineDeployment та MachinePool?

MachineDeployment створює по одному об’єкту Machine на кожен сервер (CAPI керує кожним сервером окремо). MachinePool використовує нативні механізми хмари (напр. ASG в AWS або VMSS в Azure), делегуючи масштабування самому хмарному провайдеру. MachinePool швидший та економніший для керованих сервісів типу EKS/AKS.

Практична вправа: Життєвий цикл через YAML

Ініціалізуйте керуючий кластер (можна через kind) за допомогою clusterctl init.
Згенеруйте маніфест для нового кластера EKS або AKS.
Розгорніть кластер простою командою kubectl apply -f cluster.yaml.
Змініть кількість реплік у MachineDeployment і подивіться, як у хмарі з’являються нові сервери.
Симулюйте оновлення версії, змінивши поле version, та простежте за процесом заміни серверів (Rolling update).

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

Ви навчитеся автоматично створювати інфраструктуру, тепер час з’єднати сервіси між цими кластерами. Переходьте до Модуля 10.7: Мультихмарний Service Mesh (Istio Multi-Cluster) — ми вивчимо, як налаштувати спільну мережу та безпеку (mTLS) між кластерами в різних хмарах.