Модуль 1.1: Чому Kubernetes переміг

Складність: [QUICK] — Концептуальне розуміння, без практики

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

Попередні вимоги: Немає — це точка старту для всіх

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

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

Пояснити, чому Kubernetes переміг Docker Swarm, Mesos та Nomad, навівши конкретні технічні та екосистемні причини
Визначити патерни, які допомагають технології «перемогти» (спільнота, розширюваність, прийняття хмарними провайдерами)
Оцінити заяви про нові технології, запитуючи: «Чи має це такі ж маркери екосистеми, які мав Kubernetes?»
Описати шлях від Borg до Kubernetes і причини, чому Google зробив його відкритим (open-source)

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

Була 3-тя година ранку Чорної п’ятниці 2014 року. Розробник у швидкозростаючому e-commerce стартапі дивився на 47 вікон термінала, кожне з яких було підключено через SSH до іншого сервера. Їхній святковий розпродаж став вірусним — трафік у 10 разів перевищив очікуваний. Контейнери Docker падали швидше, ніж він встигав їх перезапускати. «Масштабуй сервер 23… ні, почекай, 23 заповнений, спробуй 31… 31 впав, коли це сталося?» О 4-й ранку сайт пішов офлайн. У понеділок генеральний директор запитав, чому вони втратили 340 000 доларів продажів.

Цей жах розробника — саме та причина, чому існує Kubernetes. Не як академічна вправа, не як марнославний проєкт Google — а тому, що ручне управління контейнерами у великих масштабах — це проблема, яка з’їсть вас живцем.

Kubernetes переміг не випадково. Розуміння «війн оркестраторів» допоможе вам зрозуміти, чому існують певні патерни і чому альтернативи зазнали невдачі.

Проблема: Оркестрація контейнерів

До 2014 року контейнери довели свою цінність. Docker зробив їх доступними. Але виникла нова проблема:

Як запускати тисячі контейнерів на сотнях машин?

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

Ручне управління не масштабується. Вам потрібні:

Автоматичне планування (scheduling) (де має працювати цей контейнер?)
Самовідновлення (що відбувається, коли контейнер гине?)
Масштабування (як впоратися зі зростанням трафіку?)
Мережева взаємодія (як контейнери знаходять один одного?)
Оновлення (як розгортати без простоїв?)

Це і є оркестрація контейнерів.

Претенденти

Docker Swarm

Простий вибір

Відповідь Docker Inc. на потребу в оркестрації. Вбудований у сам Docker.

Переваги:
- Простий у налаштуванні
- Нативна інтеграція з Docker
- Знайомий синтаксис Docker Compose
- «Просто працює» для невеликих розгортань

Недоліки:
- Обмежений набір функцій
- Слабка підтримка мультихмарності
- Прив’язка до вендора Docker Inc.
- Обмеження масштабування

Що сталося: Docker Inc. поставила все на Swarm. Коли Kubernetes переміг, Docker Inc. зрештою змінила стратегію (була придбана компанією Mirantis у 2019 році). Swarm зараз фактично застарів.

Apache Mesos + Marathon

Вибір корпорацій

Народився в Каліфорнійському університеті в Берклі, використовувався Twitter та Airbnb. Marathon забезпечував рівень оркестрації контейнерів поверх Mesos.

Переваги:
- Перевірений у величезних масштабах (Twitter)
- Гнучкий (запускає контейнери ТА інші типи навантажень)
- Дворівнева архітектура планування
- Надійність у продакшені

Недоліки:
- Складний в експлуатації
- Крута крива навчання
- Менша екосистема
- Потребував окремих компонентів (Marathon, Chronos)

Що сталося: Twitter відмовився від Mesos у 2020 році, перейшовши на Kubernetes. Mesosphere (компанія-розробник) змінила назву на D2iQ і тепер продає… Kubernetes. Marathon покинутий.

Kubernetes

Вибір Google

Внутрішня система Google «Borg» оркеструвала контейнери понад десять років. Kubernetes став наступником Borg з відкритим кодом, переданим новоствореному CNCF.

Переваги:
- Десятирічний досвід Google
- Декларативна модель (бажаний стан)
- Величезна екосистема
- Основа Cloud Native
- Сильне управління спільнотою

Недоліки:
- Складний
- Крута крива навчання
- «Занадто багато» для простих розгортань

Що сталося: Він переміг. Рішуче.

Чому Kubernetes переміг

1. Декларативна модель

Kubernetes запропонував фундаментально інший підхід:

Імперативний (Swarm/Традиційний):
«Запусти 3 контейнери nginx на сервері-1»
«Якщо один помре, запусти інший»
«Якщо трафік зросте, запусти ще 2»

Декларативний (Kubernetes):
«Я хочу, щоб працювало 3 репліки nginx. Завжди.»
(Kubernetes сам вирішує, як це зробити)

Зупиніться та подумайте: Якщо ви визначили стан як «3 репліки», і хтось вручну зайде на сервер і видалить 2 з них, що зробить декларативна система? (Відповідь: Вона негайно виявить невідповідність стану і запустить 2 нові репліки, щоб відновити бажаний стан.)

Це глибоке зрушення. Ви описуєте чого ви хочете, а не як цього досягти. Kubernetes постійно узгоджує реальність із вашим бажаним станом.

2. Досвід Google

Google запускав контейнери в масштабах планети понад десять років за допомогою Borg. Kubernetes втілив уроки, отримані з:

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

Це не була перша спроба стартапу — це була система третього покоління від Google, випущена як open-source.

3. Ефект екосистеми та кейс Spotify

Kubernetes прийняв розумні архітектурні рішення:

Розширюваність: Custom Resource Definitions (CRDs) дозволяють будь-кому розширювати Kubernetes
Модульність (Pluggable): Середовища виконання контейнерів, мережі, сховища — все можна підключати як модулі
API-first: Все є API, що дозволяє створювати інструменти поверх системи

Кейс Spotify: Розглянемо міграцію Spotify у 2018 році. Вони створили власний оркестратор з відкритим кодом Helios. Чому вони відмовилися від нього на користь Kubernetes? Тому що Helios просто розгортав контейнери, а Kubernetes пропонував цілу екосистему. Spotify хотів використовувати галузеві стандарти для логування, моніторингу (Prometheus) та Service Mesh, які нативно інтегрувалися з Kubernetes. До 2019 року Kubernetes займав понад 75% ринку оркестрації контейнерів, що зробило власні рішення неможливими для виправдання.

4. Прийняття хмарними провайдерами

До 2017 року всі основні хмарні провайдери запропонували керований Kubernetes:

Google Kubernetes Engine (GKE)
Amazon Elastic Kubernetes Service (EKS)
Azure Kubernetes Service (AKS)

Подумайте про це: Чому AWS захотів запропонувати керований сервіс на основі інструменту, спочатку створеного Google?

Це було безпрецедентно. Конкуренти зазвичай не переймають технології один одного. Але Kubernetes був:

З відкритим кодом (жоден вендор ним не володіє одноосібно)
Під управлінням CNCF (нейтральний фонд)
Ставав стандартом (його неможливо було ігнорувати)

5. Спільнота та управління

CNCF (Cloud Native Computing Foundation) забезпечив:

Нейтральне управління (не контролюється Google)
Вендор-нейтральну сертифікацію
Чіткі правила внесення внесків (contributions)
Захист торгової марки

Це означало, що компанії могли інвестувати в Kubernetes, не боячись прив’язки до конкретного постачальника.

Застосування фреймворку: Чекліст виживання оркестратора

Оцінюючи будь-яку нову фундаментальну інфраструктурну технологію сьогодні (як-от платформи WebAssembly або AI-оркестратори), застосуйте «фреймворк Kubernetes», щоб передбачити її виживання. Чи має вона:

Декларативне управління станом: Чи покладається вона на постійне узгодження (reconciliation) замість імперативних команд?
Розширювана архітектура: Чи можуть користувачі додавати власні ресурси без зміни основного коду?
Нейтральне управління: Чи розміщена вона у фонді (як-от CNCF), а не контролюється одним вендором?
Модульні інтерфейси (Pluggable): Чи можна легко замінити мережеві компоненти, сховища та середовища виконання?
Підтримка хмарних провайдерів: Чи пропонують кілька конкуруючих хмарних провайдерів цю технологію як керований сервіс?

Хронологія

2013: Запуск Docker, контейнери стають мейнстрімом
2014: Google анонсує Kubernetes (червень)
      Анонсовано Docker Swarm
      Mesos/Marathon набирають популярність

2015: Реліз Kubernetes 1.0 (липень)
      Створено CNCF, Kubernetes передано фонду
      Починаються «війни оркестраторів»

2016: Pokemon Go працює на Kubernetes (масштабне підтвердження)
      Усі великі хмари анонсують підтримку K8s

2017: Docker Inc. додає підтримку Kubernetes (капітуляція)
      Kubernetes стає стандартом де-факто

2018-2019: Swarm застаріває, Mesos покинутий
           Домінування Kubernetes стає повним

2020+: Фокус зміщується з «чи варто використовувати K8s?» на
       «як використовувати K8s краще?»

Візуалізація

┌─────────────────────────────────────────────────────────────┐
│             ВІЙНИ ОРКЕСТРАТОРІВ (2014-2018)                 │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  2014        2015        2016        2017        2018       │
│    │           │           │           │           │        │
│    ▼           ▼           ▼           ▼           ▼        │
│                                                             │
│  ████████████████████████████████████████████████████████   │
│  █ Docker Swarm                        ░░░░ застарів        │
│  ████████████████████████████████████████████████████████   │
│                                                             │
│  ██████████████████████████████░░░░░░░░░░░░░░░░░░░░░░░░░░   │
│  █ Mesos/Marathon              ░░░░ покинутий               │
│  ██████████████████████████████░░░░░░░░░░░░░░░░░░░░░░░░░░   │
│                                                             │
│  ████████████████████████████████████████████████████████   │
│  █ Kubernetes ════════════════════════════════► ПЕРЕМОЖЕЦЬ  │
│  ████████████████████████████████████████████████████████   │
│                                                             │
│  Ключові події:                                             │
│  • 2015: K8s 1.0, створено CNCF                             │
│  • 2016: Pokemon Go підтверджує K8s у масштабі              │
│  • 2017: Docker додає підтримку K8s (білий прапор)           │
│  • 2018: Twitter відмовляється від Mesos                    │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Чи знали ви?

Kubernetes грецькою означає «керманич». Логотип — це корабельне штурвал. Сім спиць символізують сім оригінальних розробників.
Borg був названий на честь раси зі Star Trek. Внутрішній попередник Kubernetes у Google. Інші проєкти Google наслідували це: Omega (ще одне посилання на Star Trek).
Запуск Pokemon Go став віхою для K8s. Коли гра вийшла у 2016 році, трафік у 50 разів перевищив очікуваний. Kubernetes автоматично масштабував бекенд. Це стало «доказом», який переконав багато корпорацій.
Docker намагався купити Kubernetes. До того, як Kubernetes став відкритим, Docker звертався до Google з пропозицією про покупку. Google відмовив і натомість передав його в CNCF.

Поширені міфи

Міф	Реальність
«K8s переміг, бо це Google»	Google допоміг, але нейтральне управління було ключовим. AWS не прийняв би продукт, контрольований Google.
«Swarm програв через Docker»	Swarm програв, бо не зміг зрівнятися з функціями та екосистемою K8s. Проблеми компанії лише прискорили це.
«Mesos був гіршою технологією»	Mesos був потужним, але занадто складним. Технологія сама по собі не перемагає — важливі екосистема та простота.

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

Вивчаючи історію оркестрації контейнерів та застосовуючи її уроки, початківці часто припускаються таких концептуальних помилок:

Помилка	Чому це помилка	Кращий підхід
Сприйняття K8s просто як «Docker Swarm, тільки більший»	Це фундаментально змінює парадигму від імперативних команд до декларативних циклів узгодження.	Розумійте K8s як рушій узгодження стану, а не як інструмент для запуску скриптів.
Вибір K8s для простого застосунку з 2 контейнерів	Операційні витрати на управління кластером часто перевищують переваги для тривіальних завдань.	Почніть з Docker Compose або PaaS (як-от Heroku/Render), поки вам не знадобиться масштаб K8s.
Віра в те, що вендорські оркестратори безпечніші	Історія показує, що інструменти, якими володіє одна компанія (як Swarm), важко здобувають широку підтримку екосистеми.	Надавайте пріоритет інструментам, які підтримує CNCF або мають відкрите управління.
Ігнорування екосистеми CNCF	Спроба створити власні системи логування чи моніторингу замість використання стандартних інтеграцій K8s марнує головну перевагу платформи.	Використовуйте інструменти екосистеми, такі як Prometheus та Fluentd, які інтегруються нативно.
Фокусування лише на ролі Google	Хоча Google почав це, саме нейтральне управління CNCF стало каталізатором прийняття AWS та Azure.	Визнайте важливість відкритих фондів у прийнятті технологій корпораціями.
Припущення, що Kubernetes замінює Docker	K8s оркеструє контейнери, але йому все ще потрібне середовище виконання (як containerd), щоб їх запускати.	Розрізняйте образ контейнера/середовище виконання та оркестратор.
Спроба вивчити K8s без розуміння «Навіщо»	Перехід прямо до YAML без розуміння проблем, які вирішує K8s, призводить до зазубрювання без розуміння.	Спершу вивчіть історію та декларативну філософію.

Чому ця історія важлива для навчання

Розуміння того, чому Kubernetes переміг, допомагає вам:

Цінувати декларативний дизайн: Цикл узгодження (reconciliation loop) не є випадковим — це основна інновація.
Розуміти екосистему: Знання того, чому існують CRD, допомагає використовувати їх ефективно.
Уникати глухих кутів: Ви не витрачатимете час на застарілі підходи.
Говорити однією мовою: На співбесідах та в роботі цей контекст демонструє глибоке розуміння.

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

Сценарій: Ваш стартап переходить з одного сервера на багатовузлову архітектуру. Провідний розробник пропонує написати Python-скрипт, який підключається через SSH до серверів для запуску контейнерів Docker, перевіряє їх кожні 5 хвилин і перезапускає у разі збою. Базуючись на історії оркестрації, чому цей підхід ризикований?

Відповідь
Цей підхід є примітивною імперативною системою, подібною до ранніх спроб до появи Docker Swarm. Це ризиковано, оскільки побудувати надійний цикл узгодження (моніторинг стану, обробка розривів мережі, управління збоями серверів) неймовірно важко. Kubernetes вже вирішує це за допомогою надійної декларативної моделі, заснованої на десятирічному досвіді Google. Створення цього з нуля призведе до збоїв у складних випадках і величезного технічного боргу.
Сценарій: Велика технологічна компанія випускає новий пропрієтарний оркестратор контейнерів, який працює швидше за Kubernetes. Вони пропонують його безкоштовно, але він працює лише на їхній конкретній хмарній платформі. Базуючись на причинах перемоги Kubernetes, чому цей новий інструмент, швидше за все, зазнає невдачі на ринку?

Відповідь
Новому інструменту бракує нейтрального управління та широкого прийняття хмарними провайдерами, що було критичним для успіху Kubernetes у межах CNCF. Корпорації уникають прив’язки до вендора (vendor lock-in) у фундаментальній інфраструктурі. Без відкритої, розширюваної екосистеми, куди можуть вносити вклад і конкуренти, пропрієтарному інструменту буде важко створити величезну спільноту, яка зробила Kubernetes галузевим стандартом.
Сценарій: Ваша команда обговорює вибір між Docker Swarm та Kubernetes для нового корпоративного застосунку, який з часом працюватиме в AWS та на власних серверах (on-premises). Інженер виступає за Swarm, бо «його простіше налаштувати». Який історичний контекст ви маєте навести як контраргумент?

Відповідь
Хоча Swarm справді простіший на початку, він фактично застарів і програв «війни оркестраторів» саме тому, що не впорався зі складними корпоративними сценаріями використання в мультихмарних середовищах. Kubernetes переміг, бо його розширювана декларативна архітектура набагато краще справляється зі складною мережевою взаємодією та гібридними розгортаннями. Вибір покинутої технології для нового корпоративного проєкту несе серйозні ризики для довгострокової підтримки та інтеграції в екосистему.
Сценарій: Під час співбесіди вас запитують: «Якщо у вас постійно падає контейнер, як декларативний оркестратор впорається з цим інакше, ніж системний адміністратор, що пише імперативний скрипт?» Що ви відповісте?

Відповідь
Імперативний скрипт виконує послідовність кроків (наприклад, «запусти контейнер, перевір статус, перезапусти, якщо впав») і може легко дати збій, якщо виникне неочікуваний стан, наприклад, на сервері закінчиться місце. Декларативний оркестратор, як Kubernetes, постійно порівнює поточний стан кластера з бажаним станом (наприклад, «завжди мати 3 репліки»). Він безперервно працює над їх узгодженням, використовуючи вбудований інтелект для перенесення контейнера на здоровіший вузол без ручного втручання.

Практична вправа: Рефлексія архітектури оркестрації

Хоча цей модуль є концептуальним, застосування історичних уроків до сучасного сценарію закріпить ваше розуміння.

Сценарій: Технічний директор вашої компанії хоче створити власну внутрішню систему оркестрації для ваших мікросервісів, оскільки Kubernetes «здається занадто складним». Вам потрібно підготувати контраргументи, базуючись на «війнах оркестраторів».

Завдання: Складіть короткий (3-4 пункти) технічний аргумент проти створення власного оркестратора, посилаючись на конкретні історичні уроки Docker Swarm та Mesos.

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

Ви визначили принаймні один ризик, пов’язаний зі створенням власної екосистеми (посилаючись на CNCF або екосистему K8s).
Ви пояснили різницю між імперативною та декларативною моделями у своєму аргументі.
Ви згадали про тягар підтримки, посилаючись на десятирічний досвід Google з Borg.
Ви навели конкретний приклад компанії (наприклад, Docker або Twitter), яка відмовилася від власного оркестратора.

Підсумок

Kubernetes переміг у війнах оркестраторів, тому що:

Декларативна модель: Визначаєте бажаний стан, а K8s робить усе інше
Досвід Google: Десятиліття продакшен-уроків від Borg
Екосистема: Розширювана архітектура дозволила створити величезну кількість інструментів
Управління: Нейтральність CNCF дозволила прийняти технологію всією галуззю
Прийняття хмарами: Усі основні провайдери пропонують керований Kubernetes

Альтернативи програли не тому, що були поганими, — вони програли, тому що Kubernetes був краще підготовлений до загальногалузевого прийняття.

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

Модуль 1.2: Декларативний проти Імперативного — Філософія, яка робить Kubernetes особливим.