Модуль 6.1: Архітектура GKE: Standard vs Autopilot
Складність: [MEDIUM] | Час на виконання: 2 год | Передумови: Основи GCP, Архітектурні патерни хмар
Чому цей модуль важливий
Розділ «Чому цей модуль важливий»У березні 2023 року фінтех-стартап переніс свою платіжну платформу з власного Kubernetes на віртуалках у Google Kubernetes Engine (GKE). Переїзд зайняв три тижні. У перший же день роботи під навантаженням інженер помітив, що GKE автоматично оновив версію кластера з 1.26 до 1.27 у самий пік трафіку. Стара версія API, яку використовували їхні Helm-чарти, була видалена в 1.27. Результат: 14 хвилин простою платіжного шлюзу та втрата близько $340 000 у транзакціях.
Ця історія ілюструє головний нюанс GKE: Google керує величезною частиною вашої інфраструктури, але ви все одно відповідаєте за розуміння рішень, які GKE приймає за вас. Вибір між режимами Standard та Autopilot, обрання каналу оновлень та конфігурація регіональних кластерів мають прямий вплив на доступність вашого сайту та ваш рахунок за хмару.
У цьому модулі ви вивчите архітектуру GKE з нуля: як працюють площина управління та пули вузлів, чим принципово відрізняються режими Standard та Autopilot, як канали релізів (Release Channels) керують оновленнями та як приймати правильні рішення щодо топології кластера.
Фундамент архітектури GKE
Розділ «Фундамент архітектури GKE»Кожен кластер GKE складається з двох рівнів: площина управління (керується Google) та вузли (де працюють ваші програми).
Control Plane (Площина управління)
Розділ «Control Plane (Площина управління)»Це “мозок” кластера.
- Ціна: Google не бере грошей за управління в режимі Standard (один зональний кластер на акаунт — безкоштовно).
- Invisible: Ви не можете зайти на сервери API-сервера по SSH. Ви спілкуєтеся з ними тільки через
kubectl. - Auto-scaled: Google сам додає ресурси процесора та пам’яті для API-сервера, коли ваш кластер росте.
Регіональні vs Зональні кластери
Розділ «Регіональні vs Зональні кластери»Це одне з перших рішень при створенні кластера.
| Аспект | Зональний кластер | Регіональний кластер |
|---|---|---|
| Надійність (SLA) | 99.5% | 99.95% |
| Control Plane | Одна копія в одній зоні | Три копії у трьох різних зонах |
| Оновлення | ~5 хв простою API | Без простоїв (Rolling) |
| Ціна | Дешевше (менше вузлів) | Дорожче (мінімум 3 вузли) |
Важливо: В регіональному кластері параметр --num-nodes=3 означає “3 вузли на кожну зону”. Разом це буде 9 вузлів. Багато команд отримують шокуючий рахунок в кінці місяця саме через цю арифметику.
Режим Standard: Повний контроль
Розділ «Режим Standard: Повний контроль»Це класичний досвід GKE. Ви самі керуєте пулами вузлів, обираєте типи серверів та налаштовуєте масштабування. Google відповідає тільки за “мозок” кластера.
Що ви робите в Standard:
- Обираєте розмір серверів (напр.
e2-standard-4). - Керуєте оновленням ОС на серверах.
- Налаштовуєте права доступу та мережеві правила.
- Оплата: Ви платите за кожен запущений сервер, навіть якщо він пустий.
Режим Autopilot: Повне управління
Розділ «Режим Autopilot: Повне управління»Autopilot — це “serverless” режим для Kubernetes, запущений у 2021 році. Google керує всім: і площиною управління, і серверами.
Як це працює:
- Ви не створюєте пули вузлів. Ви просто деплоїте поди.
- Google сам підбирає ідеальний сервер під ваші запити.
- Оплата: Ви платите тільки за ресурси, які попросили ваші поди (CPU/RAM). Ви не платите за простій серверів.
- Безпека: Google сам налаштовує захист вузлів за найкращими практиками.
Що обрати? (Decision Framework)
Розділ «Що обрати? (Decision Framework)»Обирайте Autopilot, якщо:
Розділ «Обирайте Autopilot, якщо:»- Ви хочете мінімум операційної роботи.
- У вас невелика команда і немає окремого адміна Kubernetes.
- Ваші додатки мають чітко визначені потреби в ресурсах.
- Ви хочете платити за “корисну роботу”, а не за віртуалки.
Обирайте Standard, якщо:
Розділ «Обирайте Standard, якщо:»- Вам потрібен повний контроль над залізом (напр. специфічні GPU або ядра).
- Вам потрібні привілейовані контейнери для моніторингу або безпеки.
- Ви хочете максимально зекономити за рахунок агресивного “упаковування” подів (bin-packing).
- У вас є суворі вимоги комплаєнсу, які вимагають контролю над ОС сервера.
Типові помилки
Розділ «Типові помилки»| Помилка | Чому це стається | Як виправити |
|---|---|---|
| Зональний кластер у продакшні | Спроба зекономити | Використовуйте регіональні кластери; 99.5% SLA недостатньо для бізнесу |
| Rapid канал для критичних баз | Хочеться нових фіч | Для продакшну використовуйте канал Regular або Stable |
| Autopilot без лімітів | ”Google сам розбереться” | Autopilot вимагає resources.requests. Якщо їх не вказати, він поставить завеликі дефолти і ви переплатите |
Confusing --num-nodes | Думали, що це загальна кількість | Пам’ятайте: регіональний = N * 3 зони. Рахуйте бюджет правильно |
Тест
Розділ «Тест»1. У чому головна фінансова різниця між Standard та Autopilot?
У Standard ви платите за віртуальні машини (вузли), незалежно від того, скільки подів на них працює. В Autopilot ви платите тільки за CPU та пам’ять, які реально зарезервовані вашими подами.
2. Що станеться з API-сервером зонального кластера під час оновлення?
Він буде недоступним близько 5-10 хвилин. Ви не зможете запускати команди kubectl, але поди, що вже працюють, продовжать свою роботу.
Практична вправа: Створення двох світів
Розділ «Практична вправа: Створення двох світів»- Створіть кластер Standard із 1 вузлом у вашій зоні.
- Створіть кластер Autopilot у тому ж регіоні.
- Розгорніть один і той самий под у обидва кластери.
- Порівняйте список вузлів (
kubectl get nodes): зверніть увагу, що в Autopilot вузли з’являються самі під ваш под і мають дивні назви.
Наступний модуль
Розділ «Наступний модуль»Переходьте до Модуля 6.2: Мережа GKE (Dataplane V2 та Gateway API) — ви дізнаєтеся про eBPF, мережі без kube-proxy та навчитеся використовувати сучасний Gateway API замість старого Ingress.