Модуль 7.1: Архітектура AKS та управління вузлами

Складність: [MEDIUM] | Час на виконання: 2 год | Передумови: Основи Azure, Архітектурні патерни хмар

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

У вересні 2023 року фінтех-компанія на Azure Kubernetes Service (AKS) пережила збій, який зупинив усі сервіси майже на чотири години. Причиною був не баг у коді, а архітектурне рішення: всі додатки — від критичних платежів до фонових звітів — працювали в одному системному пулі вузлів. Коли Azure розпочав планове обслуговування одного з фізичних серверів, вузол почав зливати (drain) поди. Решта два вузли не витримали навантаження, почалася ланцюгова реакція витіснення подів, і весь кластер “впав”. Збитки оцінили у $2.6 мільйона.

Цей урок жорсткий, але простий: AKS дає вам керований “мозок” Kubernetes, але архітектурні рішення щодо серверів, зон доступності та стратегій оновлення — це ваша відповідальність. Помилка тут створює “картковий будинок”, який завалиться при першому ж збої.

У цьому модулі ви дізнаєтеся, як насправді влаштований AKS. Ви зрозумієте різницю між системними та користувацькими пулами вузлів, дізнаєтеся, як Availability Zones захищають вас від збоїв дата-центрів, як каналы оновлень тримають кластер актуальним без сюрпризів та як Entra ID замінює небезпечні файли сертифікатів на сучасне управління доступом.

Control Plane AKS: Що робить Microsoft (і що робите ви)

Коли ви створюєте AKS, Microsoft бере на себе площину управління (API-сервер, etcd, scheduler). Ви ніколи не бачите ці сервери і не платите за них окремо (у базовому тарифі).

Ваші рішення щодо Control Plane:

Standard Tier: обов’язковий для продакшну. Дає 99.95% SLA та підтримку великих кластерів.
Free Tier: без гарантій аптайму. Тільки для тестів.
Upgrade Channel: ви вирішуєте, як швидко Google буде оновлювати версію Kubernetes.

Системні пули vs Користувацькі пули

Це головне правило надійності в AKS: ніколи не запускайте свої додатки на системних вузлах.

System Pool: Тільки для критичних сервісів Kubernetes (DNS, метрики, тунелі до хмари). Має бути мінімум 3 вузли у 3 різних зонах.
User Pool: Для ваших додатків. Ви можете створювати багато пулів із різними типами серверів (напр. один пул із GPU для ML, інший — на Spot-машинах для економії).

Availability Zones: Виживання при катастрофах

Регіон Azure зазвичай має 3 зони доступності. Це окремі дата-центри з незалежним живленням.

Якщо ви розподілите вузли по всіх 3 зонах, падіння одного дата-центра вимкне лише 1/3 вашої потужності.
Нюанс: Диски Azure Disk прив’язані до конкретної зони. Якщо под переїде в іншу зону — він не зможе підключити свій диск. Для цього треба використовувати Azure Files або спеціальні правила планування.

Ephemeral OS Disks: Швидкість та безпека

За замовчуванням диски серверів зберігаються у хмарі як окремі ресурси. Ephemeral OS Disks використовують локальну пам’ять самого сервера.

Плюс: Сервери завантажуються за 20 секунд замість 90.
Плюс: Безкоштовно (входить у ціну ВМ).
Безпека: При кожному перезапуску сервер отримує абсолютно чисту ОС, що видаляє будь-яке “сміття” або шкідливий код.

Entra ID (Azure AD) та RBAC

Більше ніяких kubeconfig файлів із паролями, що ніколи не згорають.

Користувачі логіняться в кластер під своїми робочими акаунтами.
Ви даєте права в Kubernetes прямо через портал Azure (напр. роль “AKS Writer”).
Кожна дія логується в Azure Activity Log: ви завжди знаєте, хто саме видалив под.

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

Помилка	Чому це стається	Як виправити
Все в одному пулі	Спроба зекономити час	Створюйте окремий `User` пул для додатків
Free Tier для продакшну	”Навіщо платити $73/міс?”	Без SLA Microsoft не несе відповідальності за “падіння” API-сервера
Всі вузли в одній зоні	Забули вказати `--zones 1 2 3`	Завжди розподіляйте вузли по всіх доступних зонах регіону
Ручні зміни в MC_ групі	Бажання підправити мережу в порталі	AKS затре ваші зміни автоматично. Використовуйте тільки `az aks` або Bicep/Terraform

Тест

1. Чому не варто запускати додатки на системних пулах вузлів?

Тому що ваш додаток може спожити весь процесор або пам’ять вузла, через що “впаде” CoreDNS. Якщо впаде DNS — весь кластер перестане працювати, бо поди не зможуть знайти один одного.

2. У чому перевага Azure RBAC для Kubernetes?

Ви можете керувати правами доступу до кластера так само, як і до баз даних чи віртуальних машин — через групи в Entra ID. Вам не потрібно створювати сотні маніфестів RoleBinding всередині кластера.

Практична вправа: Створення промислового кластера

Створіть групу в Entra ID для адмінів кластера.
Напишіть Bicep шаблон, який створює AKS із:
- Типом Standard.
- Системним пулом (3 вузли).
- Користувацьким пулом із автомасшабуванням (3-10 вузлів).
- Увімкненим Azure RBAC.
Розгорніть кластер і залогіньтеся через az aks get-credentials.
Перевірте, що вузли розподілені між 3 зонами доступності.

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

Переходьте до Модуля 7.2: Просунуті мережі AKS — ми порівняємо Azure CNI, Kubenet та нову мережу на базі Cilium, щоб зрозуміти, яка найкраще підійде для вашого проекту.