Модуль 1.4: Екосистема Cloud Native

Складність: [ШВИДКО] — орієнтація, а не глибоке занурення

Час на проходження: 25-30 хвилин

Передумови: Модуль 3 (Що таке Kubernetes?)

Що ви зможете зробити

Після цього модуля ви зможете:

Орієнтуватися в ландшафті CNCF та пояснювати, які категорії інструментів існують
Співставляти типові проблеми (спостережуваність, безпека, мережа) з інструментами, які їх вирішують
Пояснювати процес “випуску” (graduation) CNCF та що він означає для зрілості інструменту
Визначати 5-6 інструментів, з якими ви найчастіше стикатиметеся на першій роботі з Kubernetes

Чому це важливо

Kubernetes не існує ізольовано. Він є центром величезної екосистеми проєктів, інструментів та практик. Розуміння цієї екосистеми допоможе вам:

Знати, які інструменти існують для різних завдань
Розуміти описи вакансій та обговорення в команді
Планувати свій шлях навчання
Уникати “винайдення велосипеда”

Ви не будете вивчати ці інструменти тут — лише дізнаєтеся про їхнє існування та призначення.

Історія з життя: Катастрофа розробки на основі резюме

Середня e-commerce компанія вирішила мігрувати свій монолітний застосунок на Kubernetes. Провідний архітектор, прагнучи використовувати найсучасніші технології, наказав негайно впровадити складний Service Mesh, експериментальну розподілену базу даних стадії Sandbox та передову мережу на базі eBPF.

Результат: Команда провела шість місяців, борючись з інфраструктурою замість міграції застосунку. База даних Sandbox втратила дані під час незначного оновлення, а Service Mesh спричинив незрозумілі затримки (latency), оскільки ніхто в команді не мав достатнього досвіду для налаштування проксі-серверів.

Урок: Ландшафт CNCF — це меню, а не список покупок. Впроваджуйте інструменти лише тоді, коли ви стикаєтеся з конкретною проблемою, для вирішення якої вони були створені.

Ландшафт CNCF

Cloud Native Computing Foundation (CNCF) хостить та керує проєктами cloud native. Їхній ландшафт включає понад 1000 проєктів:

┌─────────────────────────────────────────────────────────────┐
│                ЛАНДШАФТ CNCF (Спрощено)                     │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌─────────────────────────────────────────────────────┐   │
│  │              ЗАВЕРШЕНІ ПРОЄКТИ                      │   │
│  │  (Готові до продакшну, широко впроваджені)          │   │
│  │  ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌──────────┐  │   │
│  │  │Kubernetes│ │  Helm   │ │Prometheus│ │containerd│  │   │
│  │  └─────────┘ └─────────┘ └─────────┘ └──────────┘  │   │
│  │  ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌──────────┐  │   │
│  │  │ Fluentd │ │  Envoy  │ │  Jaeger │ │  Vitess  │  │   │
│  │  └─────────┘ └─────────┘ └─────────┘ └──────────┘  │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
│  ┌─────────────────────────────────────────────────────┐   │
│  │             ІНКУБАЦІЙНІ ПРОЄКТИ                     │   │
│  │  (Зростаюче впровадження, стають зрілими)           │   │
│  │  ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌──────────┐  │   │
│  │  │  Argo   │ │ Cilium  │ │ Falco   │ │Kustomize │  │   │
│  │  └─────────┘ └─────────┘ └─────────┘ └──────────┘  │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
│  ┌─────────────────────────────────────────────────────┐   │
│  │             ПРОЄКТИ "ПІСОЧНИЦІ"                     │   │
│  │  (Рання стадія, експериментальні)                   │   │
│  │  Сотні проєктів...                                  │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Категорії інструментів

Без паніки: Ландшафт CNCF налічує понад 1000 проєктів. Вам не потрібно знати їх усі. На вашій першій роботі з Kubernetes ви, ймовірно, будете щодня використовувати 5-6 інструментів. Мета тут — знати, які категорії існують, щоб коли хтось скаже “нам потрібна сервісна сітка” або “налаштуйте спостережуваність”, ви розуміли, про що йдеться.

1. Оркестрація (Ядро)

Інструмент	Що він робить
Kubernetes	Оркестрація контейнерів (центр усього)
Helm	Менеджер пакетів для K8s (як apt/yum для K8s)
Kustomize	Конфігурація K8s без використання шаблонів

2. Середовище виконання контейнерів

Зупиніться та подумайте: Якщо Kubernetes лише оркеструє контейнери, то хто насправді запускає процеси контейнерів на робочому вузлі?

Інструмент	Що він робить
containerd	Стандартне для галузі середовище виконання контейнерів
CRI-O	Полегшене середовище виконання для K8s

3. Мережа

Інструмент	Що він робить
Cilium	CNI з мережею та безпекою на базі eBPF
Calico	Популярний CNI для мережевих політик
Flannel	Проста оверлейна мережа
Istio	Сервісна сітка (управління трафіком, безпека)
Linkerd	Полегшена сервісна сітка
Envoy	Сервіс-проксі (забезпечує роботу багатьох сервісних сіток)

Компроміс: Сучасні CNI, як-от Cilium, пропонують неймовірну продуктивність та можливості безпеки завдяки eBPF, але вони потребують сучасних ядер Linux та глибших навичок налагодження мережі порівняно з простішими варіантами, такими як Flannel.

4. Спостережуваність (Observability)

Інструмент	Що він робить
Prometheus	Збір метрик та сповіщення
Grafana	Візуалізація та дашборди
Jaeger	Розподілене трасування
Fluentd/Fluent Bit	Збір та пересилання логів
Loki	Агрегація логів (у стилі Prometheus)
OpenTelemetry	Уніфікований фреймворк для спостережуваності

Компроміс: Запуск власного стека Prometheus та Grafana забезпечує повну приватність даних та дозволяє уникнути витрат на оплату хмарних сервісів за обсяг даних, але це потребує часу інженерів на підтримку самої інфраструктури спостережуваності при масштабуванні.

5. CI/CD та GitOps

Інструмент	Що він робить
ArgoCD	Безперервна доставка за принципом GitOps
Flux	Набір інструментів GitOps
Tekton	CI/CD конвеєри, нативні для K8s

Компроміс: ArgoCD та робочі процеси GitOps забезпечують відмінну безпеку та можливість аудиту, динамічно затягуючи зміни стану з репозиторію, але вони потребують зміни парадигми для розробників, які звикли до того, що інструменти CI (як Jenkins) просто “пушать” код на сервер.

6. Безпека

Інструмент	Що він робить
Falco	Моніторинг безпеки під час виконання
Trivy	Сканування контейнерів на вразливості
OPA/Gatekeeper	Забезпечення дотримання політик
cert-manager	Управління сертифікатами

7. Зберігання даних

Інструмент	Що він робить
Rook	Оркестрація сховища (Ceph на K8s)
Longhorn	Розподілене блочне сховище
Velero	Резервне копіювання та аварійне відновлення

Приклад: Проєктування базового стека

Уявіть, що вас найняли першим DevOps-інженером у стартап. У них є простий веб-застосунок, API та база даних. Ось як ви могли б логічно обрати інструменти з екосистеми для побудови їхнього першого продакшн-стека:

Оркестрація: Керований Kubernetes (EKS/GKE), щоб уникнути операційного кошмару самостійного управління панеллю управління (control plane).
Пакування: Helm. Ви пишете стандартний Helm чарт, щоб розробники могли легко розгортати нові мікросервіси, не вивчаючи внутрішню структуру Kubernetes.
CI/CD: GitHub Actions для створення образу контейнера та ArgoCD для затягування змін у кластер (GitOps).
Спостережуваність: Prometheus для системних метрик, Loki для логів застосунків та Grafana для візуалізації всього в одному місці.
Безпека: Trivy для автоматичного сканування образів у GitHub Actions перед їх відправкою в реєстр.

Зверніть увагу на те, чого тут немає: Жодної складної сервісної сітки, жодного розподіленого трасування чи кастомного оркестратора сховища. Ви зберегли все простим, зосередившись виключно на надійній доставці та базовій видимості.

Як вони поєднуються між собою

┌─────────────────────────────────────────────────────────────┐
│                  СТЕК CLOUD NATIVE                          │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  ВАШ ЗАСТОСУНОК                                     │   │
│  │  (Мікросервіси, API тощо)                           │   │
│  └───────────────────────┬─────────────────────────────┘   │
│                          │                                  │
│  ┌───────────────────────┼─────────────────────────────┐   │
│  │  РІВЕНЬ ПЛАТФОРМИ     │                             │   │
│  │  ┌─────────────┐ ┌────┴────┐ ┌─────────────┐       │   │
│  │  │   CI/CD     │ │ Сервісна│ │ Спостережу- │       │   │
│  │  │  (ArgoCD)   │ │  сітка  │ │ ваність     │       │   │
│  │  └─────────────┘ │ (Istio) │ │ (Prometheus)│       │   │
│  │                  └─────────┘ └─────────────┘        │   │
│  └───────────────────────┬─────────────────────────────┘   │
│                          │                                  │
│  ┌───────────────────────┼─────────────────────────────┐   │
│  │  KUBERNETES           │                             │   │
│  │  ┌─────────────┐ ┌────┴────┐ ┌─────────────┐       │   │
│  │  │   Helm/     │ │Наванта- │ │   Сервіси   │       │   │
│  │  │ Kustomize   │ │ження    │ │  (Мережа)   │       │   │
│  │  └─────────────┘ │ (Pods)  │ │             │       │   │
│  │                  └─────────┘ └─────────────┘        │   │
│  └───────────────────────┬─────────────────────────────┘   │
│                          │                                  │
│  ┌───────────────────────┼─────────────────────────────┐   │
│  │  ІНФРАСТРУКТУРА       │                             │   │
│  │  ┌─────────────┐ ┌────┴────┐ ┌─────────────┐       │   │
│  │  │ Обчислення  │ │  CNI    │ │  Сховище    │       │   │
│  │  │  (Вузли)    │ │(Cilium) │ │   (Rook)    │       │   │
│  │  └─────────────┘ └─────────┘ └─────────────┘        │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Що вам дійсно потрібно знати

Для сертифікації та більшості робіт зосередьтеся на:

Обов’язково знати

Kubernetes — сама платформа
Helm — управління пакетами
Kustomize — управління конфігурацією
kubectl — інструмент командного рядка

Варто знати (концептуально)

Prometheus/Grafana — моніторинг
Концепції Service Mesh — управління трафіком
Концепції CNI — як працює мережа Pod
Container runtime — containerd, CRI

Корисно знати (не обов’язково глибоко)

ArgoCD/Flux — GitOps
Реалізації Istio/Linkerd — сервісні сітки
OPA/Gatekeeper — політики
Falco/Trivy — сканування безпеки

Дорожня карта Cloud Native

CNCF пропонує офіційний шлях навчання:

┌─────────────────────────────────────────────────────────────┐
│                ДОРОЖНЯ КАРТА CLOUD NATIVE                   │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  1. КОНТЕЙНЕРИЗАЦІЯ                                         │
│     Вивчіть Docker, розберіться з образами та контейнерами  │
│                          │                                  │
│                          ▼                                  │
│  2. CI/CD                                                   │
│     Автоматизовані конвеєри збірки та розгортання           │
│                          │                                  │
│                          ▼                                  │
│  3. ОРКЕСТРАЦІЯ                                             │
│     Kubernetes для управління контейнерами в масштабі       │
│                          │                                  │
│                          ▼                                  │
│  4. СПОСТЕРЕЖУВАНІСТЬ                                       │
│     Метрики, логи, трасування для розуміння систем          │
│                          │                                  │
│                          ▼                                  │
│  5. СЕРВІСНА СІТКА                                          │
│     Розширене управління трафіком та безпека                │
│                          │                                  │
│                          ▼                                  │
│  6. РОЗПОДІЛЕНА БАЗА ДАНИХ                                  │
│     Управління даними у форматі Cloud Native                │
│                                                             │
└─────────────────────────────────────────────────────────────┘

KubeDojo зосереджується на кроці 3 (Оркестрація) з глибиною, необхідною для сертифікації.

Чи знали ви?

Ландшафт CNCF налічує понад 1000 проєктів. Ви не можете вивчити їх усі. Зосередьтеся на тому, чого вимагає ваша робота.
Більшість компаній використовують ~10-20 проєктів CNCF. А не сотні. Спеціалізація краща за поверхневе знання всього.
Сам Kubernetes містить близько 2 мільйонів рядків коду. Плюс ще мільйони в проєктах екосистеми. Саме тому сертифікації зосереджені на практичному використанні, а не на внутрішніх деталях.
Нові проєкти приєднуються до CNCF щомісяця. Ландшафт постійно розвивається. Основні навички K8s залишаються стабільними; інструментарій навколо нього змінюється.

Зупиніться та подумайте: Чому компанія може обрати проєкт стадії “Incubating” замість “Graduated”?

Рівні зрілості екосистеми

Етапи проєктів CNCF:

┌──────────┐
│ SANDBOX  │ ─── Рання стадія, експериментально.
└────┬─────┘     Може бути не готовим до продакшну.
     │
     ▼
┌──────────┐
│INCUBATING│ ─── Зростаюче впровадження.
└────┬─────┘     Формування спільноти.
     │
     ▼
┌──────────┐
│ GRADUATED│ ─── Перевірено в продакшні.
└──────────┘     Широко впроваджено, стабільно.

Для продакшну надавайте перевагу проєктам Graduated. Для навчання та експериментів досліджуйте Incubating і навіть Sandbox.

Швидкий довідник: Категорії інструментів

Коли вам потрібно…	Розгляньте…
Управління пакетами	Helm, Kustomize
Моніторинг	Prometheus + Grafana
Логування	Fluentd + Loki
Трасування	Jaeger, Tempo
Сервісна сітка	Istio, Linkerd
GitOps	ArgoCD, Flux
Забезпечення політик	OPA, Kyverno
Сканування безпеки	Trivy, Falco
Управління секретами	Vault, Sealed Secrets
Сертифікати	cert-manager
Бекапи	Velero
Локальна розробка	kind, minikube

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

Помилка	Чому це трапляється	Як цього уникнути
Ігнорування рівнів зрілості CNCF	Команди бачать блискучий новий інструмент у фазі Sandbox і впроваджують його в продакшн, сподіваючись на миттєві вигоди.	Використовуйте проєкти Graduated або Incubating для продуктивних навантажень. Зарезервуйте інструменти Sandbox для експериментальних лабораторій.
Пропуск спостережуваності до моменту інциденту	Увага зосереджена суто на запуску застосунку. Моніторинг та логування сприймаються як завдання “другої фази”.	Розгортайте Prometheus, Grafana та Fluentd разом із вашим першим продакшн-застосунком. Ви не можете виправити те, чого не бачите.
Вибір інструментів на основі хайпу в блогах, а не можливостей команди	Допис у блозі вихваляє складну сервісну сітку, і команда впроваджує її, не маючи достатньої інженерної зрілості для управління нею.	Підбирайте інструмент відповідно до ваших реальних проблем та рівня навичок команди. Не впроваджуйте Istio, якщо у вас лише 3 мікросервіси.
Прив’язка до постачальника через власні розширення	Хмарні провайдери пропонують “прості рішення”, які тісно пов’язують ваші маніфести Kubernetes з їхньою специфічною інфраструктурою.	Покладайтеся на відкриті стандарти та проєкти CNCF (такі як Helm та стандартний Ingress), щоб зберегти переносимість навантажень між хмарами.
Надмірне ускладнення стека на ранніх етапах	Спроба впровадити всю “Дорожню карту Cloud Native” до того, як перший застосунок буде запущений.	Почніть з простого. Використовуйте керований Kubernetes, базовий CI/CD та основну спостережуваність. Додавайте сервісні сітки або GitOps лише тоді, коли цього вимагатиме масштаб.
Нехтування скануванням безпеки в CI/CD	Віра в те, що запуск контейнерів повністю ізолює застосунки, ігноруючи вразливості в самому образі контейнера.	Інтегруйте такі інструменти, як Trivy, у ваш конвеєр збірки, щоб блокувати потрапляння образів із критичними вразливостями в реєстр.
Забування про бекапи постійного сховища	Припущення, що оскільки застосунок має високу доступність у Kubernetes, дані автоматично резервуються.	Впроваджуйте рішення для бекапу, яке “розуміє” кластер, наприклад Velero, щоб робити знімки як постійних томів, так і стану Kubernetes.
Сприйняття Kubernetes як магічної пігулки	Припущення, що Kubernetes автоматично виправить погану архітектуру застосунку.	Переконайтеся, що застосунок справді є cloud-native (без збереження стану, горизонтально масштабований), перш ніж мігрувати його. Поганий моноліт залишиться поганим монолітом і в K8s.

Контрольні запитання

Рівень 1: Базові концепції

CTO вашої компанії хоче переконатися, що основні інструменти для вашої нової платформи керуються нейтральною стороною, а не контролюються одним постачальником, який може раптово змінити ліцензію. Вона запитує вас, яка організація керує Kubernetes та пов’язаними проєктами. Що ви їй відповісте?

Відповідь
Ви повинні пояснити, що Kubernetes та його екосистема керуються Cloud Native Computing Foundation (CNCF). CNCF — це нейтральна щодо постачальників організація, частина Linux Foundation, створена спеціально для розміщення та управління проєктами з відкритим кодом у сфері cloud native. Така структура гарантує, що жодна компанія не зможе одноосібно диктувати напрямок розвитку проєкту або довільно змінювати його ліцензування. Покладаючись на управління CNCF, ви гарантуєте довгострокову стабільність та справді відкриту екосистему для інфраструктури вашої платформи.
Вашій команді потрібно розгорнути один і той самий застосунок у трьох різних середовищах (Dev, Staging, Prod). Наразі розробники копіюють та вставляють “сирі” YAML-файли, що призводить до розбіжностей у конфігурації. Вам потрібен спосіб параметризувати ці розгортання. Які два різні підходи екосистеми вирішують це?

Відповідь
Ви можете вирішити це за допомогою Helm або Kustomize, які використовують різні підходи до однієї проблеми. Helm діє як менеджер пакетів, що використовує двигун шаблонів; ви визначаєте змінні у файлі `values.yaml`, на основі яких генеруються фінальні маніфести. Kustomize, навпаки, не використовує шаблони та покладається на "патчі"; ви зберігаєте базовий набір валідних YAML-файлів і застосовуєте шари (overlays), які змінюють базу для кожного конкретного середовища. Обидва інструменти ефективно усувають потребу в копіюванні YAML-файлів, зберігаючи чисті конфігурації для кожного середовища.
Ви оцінюєте новий інструмент для впровадження політик у вашому кластері. Веб-сайт проєкту виглядає дуже професійно, але перевіривши ландшафт CNCF, ви бачите, що він вказаний як проєкт стадії “Sandbox”. Ваш технічний лідер хоче розгорнути його в продакшн-кластері завтра. Що ви порадите?

Відповідь
Ви повинні наполегливо порадити не розгортати його в продакшні, пояснивши, що "Sandbox" — це найперша стадія зрілості CNCF, призначена для експериментальних проєктів. Проєкти Sandbox ще не продемонстрували широкого впровадження, стабільності в продакшні або довгострокового управління спільнотою. Через цю ранню стадію проєкт може бути покинутий, зазнати масштабних несумісних змін або привнести критичні невиправлені помилки у ваше середовище. Замість цього варто порекомендувати пошукати проєкт стадії "Incubating" або "Graduated", який вирішує ту саму проблему, або спочатку ретельно протестувати інструмент Sandbox у середовищі розробки.

Рівень 2: Прикладна екосистема

Ваша мікросервісна архітектура зросла до 50 різних сервісів. Ви спостерігаєте випадкові тайм-аути між сервісами, але оскільки вони спілкуються напряму, ви не бачите, де саме мережевий трафік зазнає невдачі або затримується. Який тип інструменту вам потрібно впровадити?

Відповідь
Вам потрібно впровадити сервісну сітку (Service Mesh), таку як Istio або Linkerd. Service Mesh додає проксі-сервер (наприклад, Envoy) поруч із кожним контейнером застосунку, перехоплюючи весь мережевий трафік між сервісами. Це забезпечує прозору спостережуваність, дозволяючи відстежувати запити, вимірювати затримку та точно визначати, яке з'єднання між сервісами переривається за тайм-аутом. Крім того, Service Mesh надає ці потужні мережеві переваги без необхідності вносити будь-які зміни в код застосунку.
Аудитор з безпеки вказує на те, що образи ваших контейнерів можуть містити застарілі бібліотеки з відомими вразливостями, але ваша команда наразі сканує лише вихідний код. Вам потрібен спосіб автоматично сканувати скомпільовані образи контейнерів перед їх розгортанням у Kubernetes. Який інструмент найкраще підходить для цього?

Відповідь
Trivy є найбільш підходящим інструментом екосистеми для цього сценарію. Trivy — це комплексний та простий у використанні сканер вразливостей, спеціально розроблений для образів контейнерів, файлових систем та Git-репозиторіїв. Інтегрувавши Trivy у ваш CI/CD конвеєр, ви зможете автоматично зупиняти збірку, якщо в шарах контейнера будуть виявлені критичні CVE (Common Vulnerabilities and Exposures). Це гарантує, що вразливі образи будуть виявлені та заблоковані задовго до того, як вони потраплять у реєстр або ваш кластер Kubernetes.
На вузлах вашого Kubernetes постійно закінчується місце на диску. Під час дослідження ви розумієте, що логи контейнерів записуються на локальний диск і ніколи не очищаються, що ускладнює пошук несправностей, оскільки логи втрачаються, якщо вузол виходить з ладу. Яку комбінацію інструментів варто впровадити для вирішення цієї проблеми?

Відповідь
Вам слід впровадити стек агрегації логів, використовуючи такі інструменти, як Fluentd (або Fluent Bit) та Loki. Fluent Bit працює як DaemonSet для ефективного збору логів з кожного вузла та контейнера в кластері, пересилаючи їх до централізованого бекенда. Потім Loki може ефективно зберігати ці логи, а Grafana надасть інтерфейс для їх запиту та візуалізації. Така архітектура відокремлює логи від ефемерних вузлів, забезпечуючи їх збереження та централізований пошук несправностей навіть після повного виходу вузлів з ладу.

Рівень 3: Архітектурні сценарії

Ваша компанія вирішила перейти на підхід GitOps. Поточний процес передбачає запуск kubectl apply за допомогою Jenkins з використанням облікових даних, що зберігаються в Jenkins, що стало кошмаром для безпеки та управління змінами. Як інструмент екосистеми може вирішити це?

Відповідь
Вам слід впровадити інструмент безперервної доставки GitOps, такий як ArgoCD або Flux. Замість того, щоб "пушити" зміни з зовнішнього CI-сервера, ці інструменти працюють безпосередньо всередині кластера Kubernetes і постійно затягують бажаний стан із Git-репозиторію. Це принципово усуває потребу в зберіганні облікових даних кластера в зовнішній системі, такій як Jenkins, що значно покращує безпеку. Крім того, якщо хтось вручну змінить ресурс у кластері, контролер GitOps виявить це відхилення (drift) і автоматично поверне його до стану, визначеного в Git.
Ви розгортаєте базу даних зі станом (stateful) у Kubernetes. Поди працюють нормально, але коли Под переноситься на інший вузол, усі його дані втрачаються, оскільки він використовував тимчасове локальне сховище. Якого компонента екосистеми CNCF та типу проєкту не вистачає?

Відповідь
Вам не вистачає хмарного оркестратора сховища, такого як Rook або Longhorn. Хоча Kubernetes може підключати томи, йому потрібен бекенд сховища, який може реплікувати дані між вузлами та забезпечувати постійне блочне сховище незалежно від того, де працює Под. Такі інструменти, як Rook (що керує Ceph), перетворюють локальні диски ваших вузлів Kubernetes на стійкий розподілений кластер сховища. Це гарантує, що коли ваш под бази даних буде перенесений на новий вузол, він зможе негайно знову підключитися до своїх постійних даних через мережу без будь-яких втрат.

Практична вправа: Створіть свій стек

Завдання: Спроєктуйте теоретичний стек cloud native для конкретного сценарію, використовуючи ландшафт CNCF.

Сценарій: Ви проєктуєте інфраструктуру для фінтех-стартапу, що стрімко зростає. Їм потрібна висока безпека, чіткі логи аудиту, надійні метрики та автоматизоване розгортання.

Інструкції:

Перейдіть на landscape.cncf.io.
Оберіть по одному інструменту для кожної категорії нижче, які, на вашу думку, підходять для цього сценарію.
Задокументуйте свій вибір та обґрунтуйте його одним реченням.

Критерії успіху:

Я обрав Container Runtime.
Я обрав стек для спостережуваності (Метрики та Логування).
Я обрав інструмент GitOps/CI/CD.
Я визначив інструмент для безпеки/забезпечення політик.
Я перевірив, що принаймні 3 з моїх обраних інструментів мають статус “Graduated”.
Я написав обґрунтування одним реченням для кожного вибору на основі обмежень сценарію.

Підсумок

Екосистема Cloud Native включає:

Основна оркестрація: Kubernetes, Helm, Kustomize Спостережуваність: Prometheus, Grafana, Jaeger, Fluentd Мережа: Cilium, Calico, Istio, Envoy Безпека: Falco, Trivy, OPA CI/CD: ArgoCD, Flux, Tekton

Ключові моменти:

CNCF хостить понад 1000 проєктів
Вам не потрібно вчити їх усі
Зосередьтеся на тому, чого вимагає ваша сертифікація/робота
Проєкти Graduated є найбільш стабільними
Kubernetes — це фундамент; усе інше будується на ньому

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

Модуль 1.5: Від моноліту до мікросервісів — розуміння еволюції архітектури застосунків.