Модуль 3.1: Хмарні нативні принципи
Складність:
[MEDIUM]- Архітектурні концепціїЧас на виконання: 30-35 хвилин
Передумови: Частина 2 (Оркестрація контейнерів)
Що ви зможете робити
Розділ «Що ви зможете робити»Після завершення цього модуля ви зможете:
- Пояснити визначення cloud native від CNCF та його основні принципи
- Порівняти cloud native застосунки з традиційними монолітними архітектурами
- Визначити принципи twelve-factor app та як вони застосовуються до навантажень Kubernetes
- Оцінити чи відповідає дизайн застосунку найкращим практикам cloud native
Чому цей модуль важливий
Розділ «Чому цей модуль важливий»Хмарні нативні технології — це більше, ніж просто контейнери. Це набір принципів для побудови масштабованих, стійких застосунків. Іспит KCNA перевіряє ваше розуміння того, що робить застосунок справді “хмарним нативним”. Цей модуль охоплює фундаментальні концепції.
Що таке Cloud Native?
Розділ «Що таке Cloud Native?»┌─────────────────────────────────────────────────────────────┐│ ВИЗНАЧЕННЯ CLOUD NATIVE │├─────────────────────────────────────────────────────────────┤│ ││ Визначення CNCF: ││ ───────────────────────────────────────────────────────── ││ "Хмарні нативні технології дають змогу організаціям ││ створювати та запускати масштабовані застосунки ││ в сучасних, динамічних середовищах, таких як ││ публічні, приватні та гібридні хмари." ││ ││ Ключові характеристики: ││ • Контейнери ││ • Service mesh ││ • Мікросервіси ││ • Незмінна інфраструктура ││ • Декларативні API ││ ││ Cloud Native ≠ "Працює в хмарі" ││ ───────────────────────────────────────────────────────── ││ Можна запускати cloud native застосунки on-premises ││ Можна запускати не-cloud-native застосунки в хмарі ││ ││ Cloud native = спроектовано для хмарних середовищ ││ │└─────────────────────────────────────────────────────────────┘Застосунок 12 факторів
Розділ «Застосунок 12 факторів»Методологія 12-Factor App є фундаментальною для cloud native:
┌─────────────────────────────────────────────────────────────┐│ 12 ФАКТОРІВ │├─────────────────────────────────────────────────────────────┤│ ││ 1. КОДОВА БАЗА ││ Одна кодова база у системі контролю версій ││ Багато розгортань (dev, staging, prod) ││ ││ 2. ЗАЛЕЖНОСТІ ││ Явно оголошуйте та ізолюйте залежності ││ Ніколи не покладайтесь на системні пакети ││ ││ 3. КОНФІГУРАЦІЯ ││ Зберігайте конфігурацію в середовищі ││ Не в коді (ConfigMaps/Secrets!) ││ ││ 4. ДОПОМІЖНІ СЕРВІСИ ││ Ставтесь до допоміжних сервісів як до підключених ││ ресурсів. БД, кеш, черга = URL, не особливі випадки ││ ││ 5. ЗБІРКА, РЕЛІЗ, ЗАПУСК ││ Суворо розділяйте етапи збірки та запуску ││ Build → Release (збірка + конфіг) → Run ││ ││ 6. ПРОЦЕСИ ││ Запускайте застосунок як процеси без стану ││ Стан зберігається у допоміжних сервісах, не в памʼяті ││ │└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐│ 12 ФАКТОРІВ (продовження) │├─────────────────────────────────────────────────────────────┤│ ││ 7. ПРИВʼЯЗКА ДО ПОРТІВ ││ Експортуйте сервіси через привʼязку до портів ││ Застосунок автономний, обслуговує HTTP ││ ││ 8. КОНКУРЕНТНІСТЬ ││ Масштабуйте через модель процесів ││ Запускайте більше екземплярів, не більші екземпляри ││ ││ 9. ОДНОРАЗОВІСТЬ ││ Максимізуйте стійкість швидким запуском/зупинкою ││ Може бути запущено/зупинено в будь-який момент ││ ││ 10. ПАРИТЕТ DEV/PROD ││ Тримайте dev, staging, production схожими ││ Однакові інструменти, однакові залежності ││ ││ 11. ЛОГИ ││ Ставтесь до логів як до потоків подій ││ Пишіть у stdout, нехай платформа збирає ││ ││ 12. АДМІНІСТРАТИВНІ ПРОЦЕСИ ││ Запускайте адмін-задачі як одноразові процеси ││ Міграції, скрипти як окремі Jobs ││ │└─────────────────────────────────────────────────────────────┘12 факторів у контексті Kubernetes
Розділ «12 факторів у контексті Kubernetes»| Фактор | Реалізація в Kubernetes |
|---|---|
| Кодова база | Образи контейнерів з Git |
| Залежності | Образи контейнерів містять залежності |
| Конфігурація | ConfigMaps та Secrets |
| Допоміжні сервіси | Services вказують на бази даних |
| Збірка/Реліз/Запуск | CI/CD пайплайни |
| Процеси | Podʼи не зберігають стан |
| Привʼязка до портів | Порти контейнерів |
| Конкурентність | Горизонтальне масштабування (replicas) |
| Одноразовість | Швидкий запуск контейнерів |
| Паритет dev/prod | Однакові образи скрізь |
| Логи | Stdout → агрегація логів |
| Адмін-процеси | Jobs та CronJobs |
Мікросервісна архітектура
Розділ «Мікросервісна архітектура»┌─────────────────────────────────────────────────────────────┐│ МОНОЛІТ vs МІКРОСЕРВІСИ │├─────────────────────────────────────────────────────────────┤│ ││ МОНОЛІТ: ││ ───────────────────────────────────────────────────────── ││ ┌─────────────────────────────────────────────────────┐ ││ │ Єдиний застосунок │ ││ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ ││ │ │ UI │ │ Замов- │ │ Оплата │ │Доставка │ │ ││ │ │ │ │ лення │ │ │ │ │ │ ││ │ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │ ││ │ Спільна база даних │ ││ └─────────────────────────────────────────────────────┘ ││ ││ • Одне розгортання ││ • Зміни впливають на все ││ • Масштабується весь застосунок ││ ││ МІКРОСЕРВІСИ: ││ ───────────────────────────────────────────────────────── ││ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ││ │ UI │ │ Замов- │ │ Оплата │ │Доставка │ ││ │ Сервіс │ │ лення │ │ Сервіс │ │ Сервіс │ ││ │ БД │ │ БД │ │ БД │ │ БД │ ││ └─────────┘ └─────────┘ └─────────┘ └─────────┘ ││ ↑ ↑ ↑ ↑ ││ └────────────┴─────┬──────┴────────────┘ ││ │ ││ API Gateway ││ ││ • Незалежне розгортання ││ • Зміна лише одного сервісу ││ • Масштабування окремих сервісів ││ │└─────────────────────────────────────────────────────────────┘Характеристики мікросервісів
Розділ «Характеристики мікросервісів»| Характеристика | Опис |
|---|---|
| Єдина відповідальність | Кожен сервіс робить одну справу добре |
| Незалежне розгортання | Розгортайте без впливу на інших |
| Децентралізовані дані | Кожен сервіс володіє своїми даними |
| Технологічна незалежність | Використовуйте найкращий інструмент для кожного сервісу |
| Ізоляція збоїв | Один збій не руйнує все |
| Командна відповідальність | Невеликі команди володіють сервісами |
Незмінна інфраструктура
Розділ «Незмінна інфраструктура»┌─────────────────────────────────────────────────────────────┐│ НЕЗМІННА ІНФРАСТРУКТУРА │├─────────────────────────────────────────────────────────────┤│ ││ ЗМІННА (Традиційна): ││ ───────────────────────────────────────────────────────── ││ Сервер → SSH → Оновити пакети → Змінити конфігурацію ││ ││ Проблема: сервери розходяться з часом ("сніжинки") ││ "Але працює на сервері A!" — не працює на сервері B ││ ││ НЕЗМІННА (Cloud Native): ││ ───────────────────────────────────────────────────────── ││ Потрібна зміна? → Зібрати новий образ → Розгорнути ││ новий контейнер → Видалити старий ││ ││ ┌─────────┐ ┌─────────┐ ││ │ v1.0 │ → │ v1.1 │ (новий контейнер) ││ │ Running │ │ Running │ ││ └─────────┘ └─────────┘ ││ ↓ ││ Видалено ││ ││ Переваги: ││ • Відтворювані розгортання ││ • Легкий відкат (просто запустіть стару версію) ││ • Без дрейфу конфігурації ││ • Краще тестування (однаковий образ скрізь) ││ │└─────────────────────────────────────────────────────────────┘Декларативний vs Імперативний підхід
Розділ «Декларативний vs Імперативний підхід»┌─────────────────────────────────────────────────────────────┐│ ДЕКЛАРАТИВНИЙ vs ІМПЕРАТИВНИЙ │├─────────────────────────────────────────────────────────────┤│ ││ ІМПЕРАТИВНИЙ: "Як це зробити" ││ ───────────────────────────────────────────────────────── ││ kubectl run nginx --image=nginx ││ kubectl scale deployment nginx --replicas=3 ││ kubectl expose deployment nginx --port=80 ││ ││ • Покрокові команди ││ • Ви вказуєте дії ││ • Немає запису бажаного стану ││ ││ ДЕКЛАРАТИВНИЙ: "Що ви хочете" ││ ───────────────────────────────────────────────────────── ││ apiVersion: apps/v1 ││ kind: Deployment ││ spec: ││ replicas: 3 ││ template: ││ spec: ││ containers: ││ - name: nginx ││ image: nginx ││ ││ kubectl apply -f deployment.yaml ││ ││ • Описуєте бажаний стан ││ • Kubernetes сам визначає як ││ • Контроль версій (GitOps!) ││ ││ Cloud native = Декларативний ││ │└─────────────────────────────────────────────────────────────┘Проектування для збоїв
Розділ «Проектування для збоїв»┌─────────────────────────────────────────────────────────────┐│ ПРОЕКТУВАННЯ ДЛЯ ЗБОЇВ │├─────────────────────────────────────────────────────────────┤│ ││ Припущення cloud native: ││ ───────────────────────────────────────────────────────── ││ "Все зламається. Плануйте це." ││ ││ Патерни: ││ ││ 1. НАДЛИШКОВІСТЬ ││ Запускайте кілька реплік ││ Якщо одна впаде, інші обробляють трафік ││ ││ 2. ПЕРЕВІРКИ СТАНУ ││ Liveness: "Чи живий контейнер?" ││ Readiness: "Чи може приймати трафік?" ││ Kubernetes перезапускає нездорові контейнери ││ ││ 3. АВТОМАТИЧНИЙ ВИМИКАЧ (CIRCUIT BREAKER) ││ Якщо сервіс B збоїть, припиніть його викликати ││ Швидкий збій, не чекайте таймаутів ││ ││ 4. ПОВТОР ЗІ ЗВОРОТНИМ ВІДСТУПОМ ││ Повторюйте невдалі запити ││ Чекайте довше між кожним повтором ││ ││ 5. ПЛАВНА ДЕГРАДАЦІЯ ││ Якщо сервіс рекомендацій впав ││ Покажіть загальні рекомендації замість помилки ││ │└─────────────────────────────────────────────────────────────┘Чи знали ви?
Розділ «Чи знали ви?»-
12 факторів зʼявились у Heroku — Створено розробниками Heroku у 2011 році на основі їхнього досвіду запуску мільйонів застосунків.
-
Більше ніж 12 факторів — Деякі пропонують додаткові фактори: API-first, телеметрію, автентифікацію та авторизацію.
-
Мікросервіси не завжди кращі — Вони додають складність (мережа, налагодження, розгортання). Починайте просто, розділяйте коли потрібно.
-
Netflix став піонером багатьох патернів — Circuit breakers (Hystrix), виявлення сервісів (Eureka) та API gateway (Zuul) зʼявились під час хмарної подорожі Netflix.
Поширені помилки
Розділ «Поширені помилки»| Помилка | Чому це шкодить | Правильне розуміння |
|---|---|---|
| ”Cloud native = у хмарі” | Пропускаєте архітектурні принципи | Cloud native — це про ЯК ви будуєте |
| Починати з мікросервісів | Надмірне проектування | Починайте з моноліту, розділяйте коли потрібно |
| Зберігати стан у контейнерах | Втрата даних при перезапуску | Використовуйте зовнішні сховища стану |
| Імперативне управління | Важко відтворити/аудитувати | Використовуйте декларативний YAML |
Тест
Розділ «Тест»-
Що таке cloud native за визначенням CNCF?
Відповідь
Технології, що дають змогу будувати масштабовані застосунки в динамічних середовищах (публічні, приватні, гібридні хмари). Ключові елементи: контейнери, service mesh, мікросервіси, незмінна інфраструктура, декларативні API. -
Що означає “ставтесь до допоміжних сервісів як до підключених ресурсів”?
Відповідь
Принцип 12 факторів: бази даних, кеші, черги повідомлень повинні бути доступні через URL/рядок підключення. Перехід з локального MySQL на AWS RDS має вимагати лише зміни значення конфігурації. -
Чому декларативний підхід кращий за імперативний?
Відповідь
Декларативні специфікації описують бажаний стан, контролюються версіями, відтворювані та піддаються аудиту. Kubernetes узгоджує фактичний стан з бажаним. Імперативні команди не залишають запису і їх важче відтворити. -
Що таке незмінна інфраструктура?
Відповідь
Ніколи не модифікуйте працюючу інфраструктуру. Натомість створюйте нові образи та замінюйте старі контейнери. Переваги: відтворюваність, легкий відкат, відсутність дрейфу конфігурації, послідовне тестування. -
Що означає “проектування для збоїв”?
Відповідь
Припускайте, що все зламається, і плануйте відповідно: запускайте кілька реплік, впроваджуйте перевірки стану, використовуйте circuit breakers, повторюйте зі зворотним відступом, деградуйте плавно. Система повинна витримувати збої компонентів.
Підсумок
Розділ «Підсумок»Cloud Native — це:
- Контейнери + мікросервіси + автоматизація
- Спроектовано для масштабування та стійкості
- Не просто “працює в хмарі”
Застосунок 12 факторів:
- Кодова база, залежності, конфігурація
- Допоміжні сервіси, збірка/реліз/запуск, процеси
- Привʼязка до портів, конкурентність, одноразовість
- Паритет dev/prod, логи, адмін-процеси
Ключові принципи:
- Мікросервіси: Невеликі, незалежні сервіси
- Незмінна інфраструктура: Замінюйте, не модифікуйте
- Декларативний: Описуйте що, а не як
- Проектування для збоїв: Очікуйте та обробляйте збої
Наступний модуль
Розділ «Наступний модуль»Модуль 3.2: Екосистема CNCF - Розуміння Cloud Native Computing Foundation та її ландшафту.