Модуль 3.3: Хмарні нативні патерни
Складність:
[MEDIUM]- Архітектурні концепціїЧас на виконання: 30-35 хвилин
Передумови: Модуль 3.2 (Екосистема CNCF)
Що ви зможете робити
Розділ «Що ви зможете робити»Після завершення цього модуля ви зможете:
- Пояснити архітектуру service mesh та коли вона додає цінність порівняно зі звичайною мережею Kubernetes
- Порівняти шаблони serverless, service mesh та GitOps за варіантами використання та компромісами
- Визначити який архітектурний шаблон відповідає даному виклику розподілених систем
- Оцінити накладні витрати проти переваг впровадження шаблонів, як service mesh або event-driven архітектура
Чому цей модуль важливий
Розділ «Чому цей модуль важливий»Окрім базових концепцій, cloud native включає патерни для вирішення складних проблем — service mesh для комунікації мікросервісів, serverless для подієво-орієнтованих навантажень, GitOps для автоматизації розгортання. KCNA перевіряє ваше розуміння цих архітектурних патернів.
Service Mesh
Розділ «Service Mesh»┌─────────────────────────────────────────────────────────────┐│ SERVICE MESH │├─────────────────────────────────────────────────────────────┤│ ││ Проблема: Мікросервісам потрібно: ││ • Комунікація між сервісами ││ • Балансування навантаження ││ • Безпека (mTLS) ││ • Спостережуваність (трейси, метрики) ││ • Управління трафіком (canary, повтори) ││ ││ Без service mesh: ││ ───────────────────────────────────────────────────────── ││ Кожен сервіс реалізує це сам = дублювання ││ ││ З service mesh: ││ ───────────────────────────────────────────────────────── ││ Інфраструктурний шар обробляє це прозоро ││ ││ ┌─────────────────────────────────────────────────────┐ ││ │ ПЛОЩИНА УПРАВЛІННЯ │ ││ │ (Istio/Linkerd control plane) │ ││ │ Конфігурація, сертифікати, політики │ ││ └─────────────────────────────────────────────────────┘ ││ │ ││ │ налаштовує ││ ▼ ││ ┌─────────────────────────────────────────────────────┐ ││ │ ПЛОЩИНА ДАНИХ │ ││ │ │ ││ │ ┌───────────────┐ ┌───────────────┐ │ ││ │ │ Сервіс A │ │ Сервіс B │ │ ││ │ │ ┌───────────┐ │ │ ┌───────────┐ │ │ ││ │ │ │ App │ │ │ │ App │ │ │ ││ │ │ └───────────┘ │ │ └───────────┘ │ │ ││ │ │ ┌───────────┐ │ │ ┌───────────┐ │ │ ││ │ │ │ Sidecar │ │←────→│ │ Sidecar │ │ │ ││ │ │ │ (Envoy) │ │ │ │ (Envoy) │ │ │ ││ │ │ └───────────┘ │ │ └───────────┘ │ │ ││ │ └───────────────┘ └───────────────┘ │ ││ │ │ ││ │ Весь трафік проходить через sidecar │ ││ └─────────────────────────────────────────────────────┘ ││ │└─────────────────────────────────────────────────────────────┘Переваги Service Mesh
Розділ «Переваги Service Mesh»| Функція | Опис |
|---|---|
| mTLS | Автоматичне шифрування між сервісами |
| Управління трафіком | Canary релізи, A/B тестування |
| Повтори/Таймаути | Автоматичний повтор зі зворотним відступом |
| Circuit breaking | Швидкий збій коли сервіс недоступний |
| Спостережуваність | Автоматичні метрики, трейси, логи |
| Контроль доступу | Авторизація між сервісами |
Популярні Service Mesh
Розділ «Популярні Service Mesh»| Mesh | Ключові характеристики |
|---|---|
| Istio | Багатофункціональний, використовує Envoy, складний |
| Linkerd | Легковаговий, простий, CNCF graduated |
| Cilium | На основі eBPF, без sidecar |
Serverless / FaaS
Розділ «Serverless / FaaS»┌─────────────────────────────────────────────────────────────┐│ SERVERLESS │├─────────────────────────────────────────────────────────────┤│ ││ Що таке serverless? ││ ───────────────────────────────────────────────────────── ││ • Запуск коду без управління серверами ││ • Оплата лише коли код виконується ││ • Автоматичне масштабування (включно до нуля) ││ ││ Типи: ││ ││ FaaS (Function as a Service): ││ ───────────────────────────────────────────────────────── ││ Подія → Функція виконується → Результат ││ ││ ┌─────────┐ ┌─────────────┐ ┌─────────┐ ││ │ Подія │ ──→ │ Функція │ ──→ │Результат│ ││ │(HTTP, │ │(Ваш код) │ │ │ ││ │ Черга, │ │ │ │ │ ││ │ Таймер) │ └─────────────┘ └─────────┘ ││ └─────────┘ ││ ││ Приклад: Обробка завантаженого зображення ││ 1. Зображення завантажено в S3 (подія) ││ 2. Функція запущена ││ 3. Функція змінює розмір зображення ││ 4. Функція зберігає результат ││ ││ Serverless у Kubernetes: ││ ───────────────────────────────────────────────────────── ││ • Knative: Serverless на Kubernetes ││ • OpenFaaS: Функції на Kubernetes ││ • KEDA: Подієво-орієнтоване автомасштабування ││ │└─────────────────────────────────────────────────────────────┘Характеристики Serverless
Розділ «Характеристики Serverless»| Аспект | Опис |
|---|---|
| Без управління серверами | Платформа керує інфраструктурою |
| Автомасштабування | Масштабується вгору з навантаженням, вниз до нуля |
| Подієво-орієнтований | Запускається подіями |
| Оплата за використання | Тарифікація за виконання |
| Без стану | Функції не зберігають стан |
| Короткоживучий | Функції мають обмеження часу |
GitOps
Розділ «GitOps»┌─────────────────────────────────────────────────────────────┐│ GITOPS │├─────────────────────────────────────────────────────────────┤│ ││ Git = Єдине джерело істини ││ ││ Традиційний CI/CD: ││ ───────────────────────────────────────────────────────── ││ Git → CI → Build → Push до кластера ││ ││ GitOps: ││ ───────────────────────────────────────────────────────── ││ Git ← Pull ← Агент у кластері ││ ││ ┌─────────────────────────────────────────────────────┐ ││ │ │ ││ │ ┌──────────┐ ┌──────────────┐ │ ││ │ │ Git │ │ Kubernetes │ │ ││ │ │ Repo │←─── Агент витягує──│ Кластер │ │ ││ │ │(бажаний) │ │ (фактичний) │ │ ││ │ └──────────┘ └──────────────┘ │ ││ │ │ │ │ ││ │ │ │ │ ││ │ └──── Агент узгоджує ────────────┘ │ ││ │ (робить фактичний = бажаний) │ ││ │ │ ││ └─────────────────────────────────────────────────────┘ ││ ││ Інструменти GitOps: ││ • Argo CD (CNCF Graduated) ││ • Flux (CNCF Graduated) ││ ││ Переваги: ││ • Декларативний (Git зберігає бажаний стан) ││ • Аудитований (історія Git = журнал змін) ││ • Оборотний (git revert = відкат) ││ • Безпечний (кластер витягує, не потрібні push-права) ││ │└─────────────────────────────────────────────────────────────┘Принципи GitOps
Розділ «Принципи GitOps»| Принцип | Опис |
|---|---|
| Декларативний | Бажаний стан у Git |
| Версійований | Git забезпечує історію |
| Автоматизований | Зміни застосовуються автоматично |
| Аудитований | Git log = аудиторський слід |
Патерни автомасштабування
Розділ «Патерни автомасштабування»┌─────────────────────────────────────────────────────────────┐│ ПАТЕРНИ АВТОМАСШТАБУВАННЯ │├─────────────────────────────────────────────────────────────┤│ ││ HORIZONTAL POD AUTOSCALER (HPA) ││ ───────────────────────────────────────────────────────── ││ Масштабування на основі метрик (CPU, памʼять, власні) ││ [Pod][Pod] → [Pod][Pod][Pod][Pod] ││ ││ VERTICAL POD AUTOSCALER (VPA) ││ ───────────────────────────────────────────────────────── ││ Налаштування запитів/лімітів ресурсів ││ [100m CPU] → [500m CPU] ││ ││ CLUSTER AUTOSCALER ││ ───────────────────────────────────────────────────────── ││ Додавання/видалення вузлів на основі очікуючих Podʼів ││ [Node 1][Node 2] → [Node 1][Node 2][Node 3] ││ ││ KEDA (Kubernetes Event-Driven Autoscaler) ││ ───────────────────────────────────────────────────────── ││ Масштабування за зовнішніми подіями ││ • Повідомлення в черзі ││ • Зʼєднання з базою даних ││ • Власні метрики ││ • Масштабування до нуля! ││ │└─────────────────────────────────────────────────────────────┘Оператори та CRD
Розділ «Оператори та CRD»┌─────────────────────────────────────────────────────────────┐│ ОПЕРАТОРИ │├─────────────────────────────────────────────────────────────┤│ ││ Що таке Оператор? ││ ───────────────────────────────────────────────────────── ││ Програмне забезпечення, що розширює Kubernetes для ││ управління складними застосунками ││ "Знання людського оператора, закодовані" ││ ││ Як це працює: ││ ───────────────────────────────────────────────────────── ││ ││ 1. Custom Resource Definition (CRD): ││ Визначає новий тип ресурсу ││ kind: PostgresCluster ││ ││ 2. Custom Resource (CR): ││ Екземпляр CRD ││ "Я хочу кластер Postgres з 3 вузлів" ││ ││ 3. Оператор (Контролер): ││ Спостерігає за CR, виконує дії ││ Створює Podʼи, Serviceʼи, PVC за потребою ││ ││ ┌─────────────────────────────────────────────────────┐ ││ │ │ ││ │ Ви пишете: Оператор створює: │ ││ │ ────────────── ───────────────── │ ││ │ kind: PostgresCluster • StatefulSet │ ││ │ spec: • Service │ ││ │ replicas: 3 • PVCs │ ││ │ version: 14 • ConfigMaps │ ││ │ • Secrets │ ││ │ • Обробляє бекапи │ ││ │ • Обробляє відмовостійкість│ ││ │ │ ││ └─────────────────────────────────────────────────────┘ ││ ││ Популярні оператори: ││ • Prometheus Operator ││ • cert-manager ││ • Strimzi (Kafka) ││ • PostgreSQL Operators ││ │└─────────────────────────────────────────────────────────────┘Патерни мультитенантності
Розділ «Патерни мультитенантності»┌─────────────────────────────────────────────────────────────┐│ МУЛЬТИТЕНАНТНІСТЬ │├─────────────────────────────────────────────────────────────┤│ ││ Запуск кількох орендарів на одному кластері ││ ││ НА ОСНОВІ ПРОСТОРІВ ІМЕН: ││ ───────────────────────────────────────────────────────── ││ ┌─────────────────────────────────────────────────────┐ ││ │ Кластер │ ││ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ ││ │ │ NS: team-a │ │ NS: team-b │ │ NS: team-c │ │ ││ │ │ [Pods] │ │ [Pods] │ │ [Pods] │ │ ││ │ └─────────────┘ └─────────────┘ └─────────────┘ │ ││ └─────────────────────────────────────────────────────┘ ││ ││ Ізоляція через: ││ • RBAC (хто може отримати доступ до чого) ││ • ResourceQuotas (обмеження ресурсів на простір імен) ││ • NetworkPolicies (мережева ізоляція) ││ • LimitRanges (типові ліміти ресурсів) ││ ││ КЛАСТЕР НА ОРЕНДАРЯ: ││ ───────────────────────────────────────────────────────── ││ Найсильніша ізоляція, вища вартість ││ ││ ВІРТУАЛЬНІ КЛАСТЕРИ: ││ ───────────────────────────────────────────────────────── ││ Інструменти як vCluster створюють ізольовані ││ "віртуальні" кластери. Сильніша ізоляція ніж простори ││ імен, менша ніж окремі кластери ││ │└─────────────────────────────────────────────────────────────┘Чи знали ви?
Розділ «Чи знали ви?»-
Sidecar поступово зникають — Service mesh, такі як Cilium, використовують eBPF для уникнення sidecar контейнерів. Istio тепер підтримує “ambient mesh” без sidecar.
-
GitOps придумав Weaveworks — Термін та практика були популяризовані Weaveworks, творцями Flux.
-
Оператори мають модель зрілості — Від базового встановлення (рівень 1) до автопілота (рівень 5), що вимірює можливості автоматизації.
-
KEDA — CNCF Graduated — Kubernetes Event-Driven Autoscaler став graduated проєктом, що показує важливість подієво-орієнтованих патернів.
Поширені помилки
Розділ «Поширені помилки»| Помилка | Чому це шкодить | Правильне розуміння |
|---|---|---|
| Service mesh для простих застосунків | Додає непотрібну складність | Використовуйте коли складність мікросервісів це виправдовує |
| Плутати serverless та контейнери | Різні моделі | Serverless = подієво-запускається, масштабується до нуля |
| Push-based CD як GitOps | Це не справжній GitOps | GitOps = кластер витягує з Git |
| Оператори для простих застосунків | Надмірне проектування | Використовуйте оператори для складних stateful застосунків |
Тест
Розділ «Тест»-
Що таке service mesh?
Відповідь
Інфраструктурний шар, який обробляє комунікацію між сервісами. Він забезпечує mTLS, управління трафіком, спостережуваність та повтори прозоро через sidecar проксі або eBPF, без зміни коду застосунку. -
Яка різниця між площиною управління та площиною даних у service mesh?
Відповідь
Площина управління керує конфігурацією, сертифікатами та політиками. Площина даних складається з проксі (sidecar, як Envoy), які обробляють фактичний мережевий трафік між сервісами. -
Чим GitOps відрізняється від звичайного CI/CD?
Відповідь
У GitOps агент у кластері витягує бажаний стан з Git та узгоджує його. Git є джерелом істини. Традиційний CI/CD надсилає зміни до кластера ззовні. -
Що таке Оператор у Kubernetes?
Відповідь
Програмне забезпечення, що розширює Kubernetes для управління складними застосунками. Воно використовує Custom Resource Definitions (CRD) для визначення нових типів ресурсів та контролери, що автоматизують операційні задачі як бекапи, масштабування та відмовостійкість. -
Для чого використовується KEDA?
Відповідь
Kubernetes Event-Driven Autoscaler. Він масштабує навантаження на основі зовнішніх подій, таких як довжина черги, метрики бази даних або власні джерела. Може масштабуватися до нуля, на відміну від стандартного HPA.
Підсумок
Розділ «Підсумок»Service Mesh:
- Обробляє комунікацію між сервісами
- mTLS, управління трафіком, спостережуваність
- Площина управління + площина даних (sidecar)
- Приклади: Istio, Linkerd, Cilium
Serverless:
- Запуск коду без управління серверами
- Подієво-орієнтований, масштабування до нуля
- Оплата за виконання
- Kubernetes: Knative, OpenFaaS, KEDA
GitOps:
- Git = джерело істини
- Агент витягує та узгоджує
- Аудитований, оборотний
- Інструменти: Argo CD, Flux
Оператори:
- Розширюють Kubernetes через CRD
- Автоматизують управління складними застосунками
- Кодифікують операційні знання
Наступний модуль
Розділ «Наступний модуль»Модуль 3.4: Основи спостережуваності - Розуміння трьох стовпів спостережуваності: метрики, логи та трейси.