Модуль 1.4: Глухі кути — технології, які ми пропускаємо

Складність: [ШВИДКО] — Розуміння того, чого вчити НЕ варто

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

Пререквізити: Модуль 1, Модуль 2, Модуль 3

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

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

Розпізнавати ознаки вмирання технології (занепад спільноти, зміна фокусу вендора, скорочення екосистеми)
Пояснювати, чому Docker Swarm, Mesos, rkt та інші технології програли своїм альтернативам
Оцінювати нові інструменти для контейнерів та оркестрації, перевіряючи рівень впровадження, управління та підтримку хмарними провайдерами
Уникати ставки своєї кар’єри на технології, що демонструють ознаки занепаду

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

У 2018 році роздрібний продавець зі списку Fortune 500 поставив 2,3 мільйона доларів на Apache Mesos як свою платформу для контейнерів. Вони найняли команду з 8 спеціалістів з Mesos, побудували власні фреймворки та розгорнули понад 200 сервісів. До 2020 року Mesos був фактично мертвий — Apache Foundation відправила проєкт до “горища” (архіву). Усю платформу довелося перебудовувати на Kubernetes. Два роки роботи — на смітник. А досвід інженерів у Mesos? Став нікчемним на ринку праці за одну ніч.

У технологіях знати, чого НЕ варто вчити, так само важливо, як і знати, що вчити. Цей модуль — це екскурсія кладовищем технологій. Не для того, щоб висміяти мертвих, а щоб допомогти вам розпізнати попереджувальні знаки, аби ви ніколи не поставили свою кар’єру на наступний Mesos.

Кладовище оркестрації контейнерів

Docker Swarm

Що це було: Власне рішення для оркестрації від компанії Docker.

Статус: Фактично застарілий (deprecated). Docker Desktop видалив Swarm mode у 2022 році.

Timeline:
2015: Docker Swarm запущено як конкурента K8s
2017: Docker додає підтримку K8s (визнання поразки)
2019: Docker Enterprise продано компанії Mirantis
2020: Mirantis оголошує графік виведення Swarm з експлуатації
2022: Swarm видалено з Docker Desktop

Чому він вмер:

Обмежений набір функцій порівняно з Kubernetes
Один вендор (Docker Inc.) проти керованого спільнотою Kubernetes
Не зміг зрівнятися за темпами зростання екосистеми Kubernetes
Корпоративні клієнти вимагали Kubernetes

Не вчіть: концепції Swarm, мережі Swarm, визначення сервісів Swarm

Виняток: Docker Compose все ще корисний для локальної розробки (але не для оркестрації)

Apache Mesos + Marathon

Що це було: Дворівневий планувальник ресурсів (Mesos) з оркестрацією контейнерів (Marathon).

Статус: Marathon покинутий. Mesos у режимі підтримки (maintenance mode).

Timeline:
2009: Mesos створено в Каліфорнійському університеті в Берклі
2013: Запущено Marathon для контейнерів
2016: Пік впровадження (Twitter, Airbnb, Apple)
2020: Twitter оголошує про міграцію на K8s
2021: Marathon оголошено покинутим (unmaintained)
2022: Використання Mesos фактично нульове для нових проєктів

Чому він вмер:

Складність дворівневого планування
Marathon ніколи не наздогнав Kubernetes за функціоналом
Екосистема так і не з’явилася
Ключові користувачі (Twitter) перейшли на Kubernetes

Не вчіть: архітектуру Mesos, конфігурації Marathon, фреймворки Mesosphere/D2iQ

Case Study: Cloud Foundry (для оркестрації)

Що це було: Суворо регламентована (opinionated) платформа як сервіс (PaaS), що з’явилася раніше за Kubernetes, розроблена переважно для безстатусних (stateless) додатків за методологією 12-factor apps.

Статус: Зміна фокусу. Оригінальна архітектура Diego була визнана застарілою на користь запуску Cloud Foundry безпосередньо на Kubernetes.

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

Обґрунтування: Cloud Foundry був неймовірним у своєму вузькому сценарії використання: cf push — і ваш додаток уже працює. Але сучасні додатки — це не лише безстатусні веб-сервіси. Вони включають бази даних зі станом (stateful), черги повідомлень, навантаження для штучного інтелекту та складні мережеві вимоги. Абстракція Cloud Foundry була занадто високою; вона так добре приховувала інфраструктуру, що ви не могли її підлаштувати, коли це було потрібно. Kubernetes запропонував абстракцію нижчого рівня, на якій можна було запустити будь-що, включно з базами даних та складними StatefulSet. Як результат, індустрія обрала гнучку “операційну систему для інфраструктури” (Kubernetes) замість регламентованої PaaS (Cloud Foundry). “Якщо не можеш перемогти — запускайся на них”: зрештою Cloud Foundry став рівнем поверх Kubernetes.

Не вчіть: BOSH (інструмент розгортання CF), Diego (оркестратор CF), специфічні концепції CF, які намагаються нативно замінити Kubernetes.

Кладовище середовищ виконання контейнерів

Docker як Runtime для Kubernetes

Що це було: Оригінальне середовище виконання (runtime) контейнерів для Kubernetes.

Статус: Видалено з Kubernetes у версії 1.24 (травень 2022).

Timeline:
2014-2016: Docker — єдиний спосіб запуску контейнерів у K8s
2016: Впроваджено CRI (Container Runtime Interface)
2017: containerd стає проєктом CNCF
2020: K8s оголошує про застарілість dockershim
2022: K8s 1.24 повністю видаляє dockershim

Чому його видалили:

Docker — це ціла платформа, а Kubernetes потрібен був лише runtime
containerd (runtime самого Docker) працює з Kubernetes безпосередньо
Стандартизація CRI зробила накладні витрати Docker непотрібними
Покращення безпеки та продуктивності

Не вчіть: специфічні для Docker конфігурації Kubernetes, усунення несправностей dockershim

Все ще актуально: Docker для збірки образів. Команда docker build та Dockerfiles залишаються стандартом.

┌─────────────────────────────────────────────────────────────┐
│              DOCKER ПРОТИ CONTAINERD У K8S                  │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  До K8s 1.24:                                              │
│  ┌───────────┐    ┌───────────┐    ┌───────────┐          │
│  │ Kubernetes│───►│  Docker   │───►│containerd │───► 🐳   │
│  └───────────┘    └───────────┘    └───────────┘          │
│                      Зайвий рівень                          │
│                                                             │
│  Після K8s 1.24:                                           │
│  ┌───────────┐    ┌───────────┐                           │
│  │ Kubernetes│───►│containerd │───► 🐳                    │
│  └───────────┘    └───────────┘                           │
│                      Прямо та ефективно                     │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Кладовище управління конфігураціями

Chef/Puppet/Ansible для Kubernetes

Що це було: Інструменти управління конфігураціями для керування серверами.

Статус: Неправильна парадигма для Kubernetes.

Чому вони не підходять:

Традиційне CM	Нативне для Kubernetes
Змінні (mutable) сервери	Незмінні (immutable) контейнери
SSH на сервери	Зміни через API
Конвергенція до стану	Декларування бажаного стану
Агент на кожному сервері	Агенти не потрібні
Імперативні скрипти	Декларативний YAML

Традиційний підхід (Chef/Puppet/Ansible):
1. Підключитися по SSH до сервера
2. Перевірити поточний стан
3. Застосувати зміни, щоб досягти бажаного стану
4. Сподіватися, що нічого не "з'їхало" (drift)

Kubernetes:
1. Визначити бажаний стан у YAML
2. Виконати kubectl apply
3. Kubernetes безперервно узгоджує стан
4. Самовідновлення, жодного SSH

Не вчіть: використання Ansible для управління ресурсами Kubernetes, Chef cookbooks для Kubernetes, Puppet маніфести для контейнерів

Виняток: Ansible/Terraform для підготовки (provisioning) самого кластера Kubernetes (інфраструктури), а не для управління робочими навантаженнями.

Case Study: Docker Compose для продакшену

Що це таке: Інструмент для визначення та запуску багатоконтейнерних додатків Docker за допомогою простого YAML-файлу.

Статус: Винятковий для локальної розробки, але антипатерн для розгортання в продакшені.

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

Обґрунтування: Docker Compose розрахований на одну машину. Йому бракує примітивів розподілених систем, необхідних для надійності в продакшені. Розглянемо типовий docker-compose.yml:

version: '3'
services:
  api:
    image: myapi:v1
    ports:
      - "8080:8080"
  db:
    image: postgres:13
    volumes:
      - db-data:/var/lib/postgresql/data

Якщо вузол (node), на якому розміщено цей стек Compose, вийде з ладу, додаток перестане працювати. Немає control plane, який би виявив збій вузла та перепланував контейнери api та db на справний вузол. Крім того, у Compose відсутні:

Самовідновлення (Self-healing): Якщо процес зависає, але контейнер не завершує роботу, Compose не знає, як його перезапустити на основі перевірок стану (health checks) без складних зовнішніх інструментів.
Оновлення без простою (Zero-downtime rolling updates): Команда docker-compose up -d часто призводить до простою під час перестворення контейнерів.
Розширене управління секретами: Секрети часто передаються як відкритий текст у змінних оточення, без RBAC та шифрування, які надають Kubernetes Secrets.
Інтеграція з Service Mesh: Немає нативного способу обробки складної маршрутизації трафіку, mutual TLS або розширеного моніторингу.

Не вчіть: розгортання Compose у продакшені, спроби використовувати Compose у Swarm mode або використання інструментів прямого перекладу, таких як Kompose, для складних архітектур продакшену.

Чому ці технології вмерли

Спільні патерни технологічних глухих кутів:

Патерн 1: Один вендор проти спільноти

Swarm:    Docker Inc. контролювала → Обмежене впровадження
K8s:      Нейтральна CNCF → Впровадження в усій індустрії
Урок:     Для інфраструктури перемагає управління спільнотою

Патерн 2: Складність без вигоди

Mesos:    Потужний, але складний → Обмежена екосистема
K8s:      Складний, але цінний → Величезна екосистема
Урок:     Складність прийнятна лише за умови пропорційної вигоди

Патерн 3: Неправильний рівень абстракції

Chef/Puppet: Рівень сервера → Не підходить для контейнерів
K8s:         Рівень контейнера → Ідеально підходить
Урок:        Зміна парадигми вимагає нових інструментів

Патерн 4: Ефекти екосистеми

Як тільки Kubernetes набрав критичну масу:
- Хмарні провайдери створили керовані сервіси
- Вендори інструментів орієнтувалися на K8s
- Таланти вивчали K8s
- Альтернативи стали нежиттєздатними

Урок: Мережеві ефекти потужні. Іноді найкраща технологія програє.

Що ВАРТО вчити

На противагу глухим кутам, ось що є актуальним зараз:

Категорія	Актуально/Релевантно
Оркестрація	Kubernetes
Runtime	containerd, CRI-O
Образи	Docker/Buildah для збірки
Конфігурація	Helm, Kustomize, нативний YAML
GitOps	ArgoCD, Flux
Service Mesh	Istio, Linkerd, Cilium
Моніторинг	Prometheus, Grafana
Логування	Fluentd, Loki

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

Помилка	Наслідок	Як уникнути
Вивчення Docker Swarm	Витрачений час на застарілі концепції оркестрації.	Пропускайте посібники зі Swarm. Зосередьтеся виключно на Kubernetes.
Використання Docker Compose в Prod	Єдина точка відмови; немає самовідновлення чи планування на кілька вузлів.	Використовуйте Compose лише локально. Для продакшену — K8s або serverless (як Cloud Run).
Мислення категоріями Chef/Puppet	Ставлення до контейнерів як до VM веде до крихкої інфраструктури.	Прийміть ідею незмінної інфраструктури та декларативного YAML. Ніколи не заходьте по SSH у контейнер для виправлень.
Ігнорування керованих сервісів K8s	Експлуатація K8s “важким шляхом” у продакшені веде до збоїв control plane.	Використовуйте EKS, GKE або AKS, якщо у вас немає спеціальної команди платформи.
Переклад Compose у Kubernetes 1:1	Інструменти перекладу створюють суб’optimal маніфести без проб, лімітів та RBAC.	Пишіть маніфести Kubernetes з нуля (або через Helm) для правильного використання примітивів K8s.
Гонитва за покинутими проєктами CNCF	Використання інструментів, що переходять у стадію “архіву”, залишає вас без підтримки.	Перевіряйте статус у CNCF landscape та активність комітів на GitHub перед впровадженням.
Думка, що Docker вмер	Нерозуміння того, що видалення dockershim не означає відмову від Dockerfiles.	Продовжуйте опановувати `docker build` та контейнеризацію додатків. Вмер лише Docker-як-runtime-для-K8s.

Візуалізація: Еволюція технологій

┌─────────────────────────────────────────────────────────────┐
│              ТАЙМЛАЙН КОНТЕЙНЕРНИХ ТЕХНОЛОГІЙ               │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022│
│    │     │     │     │     │     │     │     │     │     │ │
│    │     │     │     │     │     │     │     │     │     │ │
│    ▼     ▼     ▼     ▼     ▼     ▼     ▼     ▼     ▼     ▼ │
│                                                             │
│  Docker ══════════════════════════════════════════════════  │
│  (образи)                    (Все ще актуально для збірки)  │
│                                                             │
│        Swarm ══════════════════════░░░░░░░░░ (застаріло)    │
│                                                             │
│        Mesos ════════════════════░░░░░░░░░░ (покинуто)      │
│                                                             │
│              K8s ══════════════════════════════════════════ │
│              (Переможець, продовжує зростати)               │
│                                                             │
│                    containerd ═════════════════════════════ │
│                    (Стандартний K8s runtime)                │
│                                                             │
│  Легенда: ════ Активно  ░░░░ Застаріло/Мертве               │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Чи знали ви?

Mesos забезпечував роботу всієї інфраструктури Twitter на піку. У команді Mesos було понад 100 людей. Тим не менш, вони мігрували на Kubernetes.
Docker Inc. ледь не збанкрутувала. Компанія, яка розпочала революцію контейнерів, не змогла побудувати стійку бізнес-модель. Mirantis викупила Docker Enterprise.
Kubernetes ледь не назвали “Seven of Nine” (персонаж Star Trek, як натяк на Borg). Замість цього обрали Kubernetes, бо це звучало більш професійно.
Chef та Puppet все ще прибуткові для традиційного управління серверами. Вони просто не є правильним інструментом для cloud-native навантажень.

Як оцінювати нові технології

Коли з’являються нові технології, запитайте себе:

Чи вирішує це реальну проблему? Чи просто створює складність заради складності?
Це кероване спільнотою чи одним вендором? Управління спільнотою краще масштабується.
Чи відповідає це принципам cloud-native? Декларативність, управління через API, незмінність?
Чи є імпульс (momentum) в екосистемі? Інструменти, інтеграції, фахівці?
Чи впроваджують це великі хмарні провайдери? Вони мають чіткі сигнали щодо життєздатності технологій.

Практична вправа: Аудит технологічного радара

У цій вправі ви проведете аудит уявної застарілої інфраструктури та запропонуєте план модернізації на основі того, що ви дізналися про технологічні глухі кути.

Сценарій: Ви отримали у спадок інфраструктуру “Project Phoenix”. Наразі вона використовує Docker Swarm для оркестрації контейнерів у продакшені, Puppet для підключення по SSH до вузлів та встановлення Docker, а також монолітний файл docker-compose.yml, який перекладається для продакшену за допомогою стороннього скрипта.

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

Ідентифікувати ризики: Перелічіть принаймні 3 критичні точки відмови або технології глухого кута в поточному стеку.
Обрати заміни: Зіставте кожну застарілу технологію з її сучасним галузевим стандартом.
Спроектувати архітектуру: Накидайте (у думках або на папері), як виглядатиме новий стек без застарілих інструментів.
Спланувати зміну парадигми: Напишіть пояснення з одного абзацу для вашої команди, чому ви припиняєте використання Puppet для управління контейнерами.
Визначити процес збірки: Підтвердьте той самий інструмент із застарілого стека, який не буде викинуто (підказка: як ви будете збирати образи?).

Самоперевірка: Ваш план модернізації має вести вас до Kubernetes для оркестрації, декларативного YAML/GitOps замість Puppet та нативних маніфестів Kubernetes замість перекладеного файлу Compose. Docker ви мали залишити суворо для процесу збірки образів.

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

Сценарій: Ваш стартап переходить від монолітної архітектури до мікросервісів. Провідний розробник пропонує використовувати Docker Compose на одному потужному інстансі AWS EC2, бо “це простіше за Kubernetes і чудово працює на моєму ноутбуці”. Як ви маєте відповісти, виходячи з вимог до оркестрації в продакшені?

Відповідь
Вам слід наполегливо відрадити від такого підходу. Docker Compose обмежений одним вузлом, а отже, якщо цей інстанс EC2 вийде з ладу, весь додаток відключиться без автоматичного відновлення. Крім того, у Compose немає нативних можливостей для оновлень без простою, надійного самовідновлення на основі health checks та розширеного управління секретами. Хоча Kubernetes має крутішу криву навчання, його розподілене планування та цикл узгодження є обов'язковими для надійного та висоavailable продакшену.
Сценарій: Рекрутер звертається до вас із пропозицією високооплачуваної контрактної ролі, що вимагає “адміністрування Apache Mesos та Marathon для застарілої фінансової системи”. Ви ніколи не використовували Mesos, але думаєте пройти курс на вихідних. Чому це може бути ризикованим кроком для кар’єри?

Відповідь
Інвестування часу в Apache Mesos — це ставка на технологічний глухий кут. Платформа була майже повністю покинута індустрією після того, як Kubernetes набрав критичну масу, а Marathon офіційно не підтримується. Хоча підтримка застарілих систем може добре оплачуватися в короткостроковій перспективі, набуті навички не перенесуться на сучасні інфраструктурні ролі, що фактично знецінюватиме вашу ринкову вартість. Краще витратити час на опанування сучасних стандартів, таких як Kubernetes, Helm або GitOps-оператори.
Сценарій: Вам доручено оновити старий кластер Kubernetes з версії 1.22 до 1.25. Наразі середовище використовує Docker як runtime. Під час планування оновлення молодший інженер запитує, чи потрібно переписувати всі Dockerfiles додатків, оскільки “Kubernetes видалив Docker”. Як ви розвієте це помилкове уявлення?

Відповідь
Ви маєте пояснити різницю між форматом образу контейнера та середовищем виконання (runtime). Kubernetes версії 1.24 видалив `dockershim` — код, який дозволяв використовувати Docker як runtime на рівні вузла, перейшовши на стандартні CRI-сумісні runtimes, як-от `containerd`. Однак стандартні образи, зібрані за допомогою Docker (через Dockerfiles), повністю відповідають специфікації OCI і продовжуватимуть ідеально працювати на `containerd`. Отже, жодні Dockerfiles додатків чи пайплайни збірки образів змінювати не потрібно.
Сценарій: Старший системний адміністратор, який приєднується до вашої cloud-native команди, наполягає на використанні Ansible для прямого управління станом Pods та ReplicaSets, стверджуючи, що це те саме, що управління інстансами EC2. Чому цей традиційний підхід до управління конфігураціями не працює в середовищі Kubernetes?

Відповідь
Традиційні інструменти, такі як Ansible, є імперативними і часто покладаються на SSH для підключення до змінних (mutable) серверів для послідовного застосування конфігурацій. Kubernetes покладається на незмінну (immutable) інфраструктуру та декларативні API, де ви визначаєте бажаний стан у YAML, а контролери control plane безперервно узгоджують фактичний стан із бажаним. Спроби імперативного управління станом Pods за допомогою Ansible суперечать вбудованим механізмам самовідновлення та циклам узгодження Kubernetes. Конфігурація натомість має оброблятися нативно через Helm, Kustomize або прямі маніфести YAML.
Сценарій: Ваша команда оцінює новий, розрекламований інструмент розгортання з відкритим кодом. Його розробляє виключно один стартап, він не має моделі відкритого управління і не входить до жодного фонду, як-от CNCF. Виходячи з історичних патернів екосистеми контейнерів, який основний ризик впровадження цього інструменту?

Відповідь
Основним ризиком є прив'язка до вендора (vendor lock-in) у поєднанні з ізоляцією екосистеми, подібно до того, що сталося з Docker Swarm. Коли одна компанія контролює дорожню карту без участі нейтрального фонду, конкуренти та великі хмарні провайдери навряд чи створюватимуть глибокі інтеграції або керовані сервіси для нього. Якщо стартап змінить фокус, буде поглинутий або не витримає конкуренції з підтримуваними спільнотою альтернативами, ваша команда залишиться з покинутою технологією, дефіцитом кадрів та відсутністю підтримки галузевих стандартів.
Сценарій: Ваша компанія роками успішно використовувала Cloud Foundry для розгортання безстатусних веб-додатків на Node.js. Тепер команда data science хоче розгорнути складні ML-пайплайни зі станом (stateful), які потребують специфічного спільного використання GPU та кастомних мережевих налаштувань. Чому оригінальна архітектура Cloud Foundry може мати з цим труднощі, що спонукає до переходу на Kubernetes?

Відповідь
Cloud Foundry створювався як суворо регламентована PaaS, оптимізована для простих безстатусних 12-factor додатків, яка агресивно приховує деталі інфраструктури від розробників. Навантаження зі станом, складні розподілені ML-пайплайни та вимоги до кастомного заліза (як-от GPU) руйнують ці жорсткі абстракції. Kubernetes, виконуючи роль "операційної системи для інфраструктури" нижчого рівня, надає гнучкі примітиви для управління станом, кастомні ресурси (CRD) та складні правила планування. Саме ця гнучкість стала причиною стандартизації індустрії на Kubernetes і того, чому Cloud Foundry зрештою перейшов на запуск поверх нього.

Вправа для роздумів

Цей модуль вчить тому, чого НЕ варто вчити — і це не менш цінно, ніж знання актуального:

1. Оцінка безповоротних витрат:

Чи інвестували ви час у технологію, яка згодом стала неактуальною?
Як ви зрозуміли, що настав час рухатися далі?
Що б ви зробили інакше?

2. Розпізнавання патернів:

Модуль описує патерни невдалих технологій (один вендор, неправильна абстракція тощо).
Чи бачите ви якісь сучасні технології зі схожими попереджувальними знаками?
Як би ви оцінили “новий гарячий інструмент”?

3. Питання про Docker:

Чому люди все ще кажуть “Docker”, маючи на увазі “контейнери”?
Чи варто все ще знати Docker? (Так, для збірки образів)
Який урок можна винести з розрізнення інструментів та концепцій?

4. Вплив на кар’єру:

Якби ви були експертом із Mesos у 2018 році, що б ви робили?
Як розвивати навички, які залишаються цінними навіть при зміні інструментів?
Чи є роль “експерта з Kubernetes” надійнішою ставкою, ніж “експерта з Docker Swarm”? Чому?

5. Підготовка до майбутнього:

Що мало б змінитися, аби Kubernetes став “глухим кутом”?
Чи є нові технології, які можуть кинути виклик Kubernetes?
Як би ви помітили їх на ранній стадії?

Здатність оцінювати технологічні ставки — це кар’єрна навичка, що виходить за межі будь-якого конкретного інструменту.

Підсумок

Знання того, чого уникати, заощаджує час:

Мертва оркестрація:

Docker Swarm (застаріло)
Mesos/Marathon (покинуто)
Оригінальна модель Cloud Foundry (перейшла на K8s)

Мертвий runtime:

Docker як runtime для K8s (видалено в K8s 1.24)

Неправильна парадигма:

Chef/Puppet/Ansible для робочих навантажень Kubernetes
Docker Compose для продакшену

Патерни невдач:

Контроль з боку одного вендора
Складність без пропорційної вигоди
Неправильний рівень абстракції
Програш через ефекти екосистеми

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

Частину завершено!

Ви завершили трек пререквізитів Філософія та дизайн. Тепер ви розумієте:

Чому Kubernetes переміг у війнах оркестраторів
Декларативну модель та цикл узгодження
Що охоплює KubeDojo і чому
Яких технологій слід уникати та чому

Наступні кроки:

Cloud Native 101 — якщо ви новачок у контейнерах
Основи Kubernetes — якщо ви вже розумієте контейнери
Навчальна програма CKA — якщо ви готові до підготовки до сертифікації