У подкасті The Pragmatic Engineer ведучий Ґерґей Орош говорив із Робертом Ерецем, Principal Engineer в Octopus Deploy і фахівцем із CI/CD та систем розгортання. Попри репутацію «cloud‑native» технології, у їхній розмові Kubernetes постає в іншій ролі: не лише як переможець хмарних оркестраторів, а й як де-факто стандарт для on‑prem інфраструктури — від датацентрів до POS‑терміналів і наукових суден у відкритому морі.
Як Kubernetes став «платформою моменту»
Ерец називає Kubernetes «the platform of the moment» і говорить, що він «has become the clear winner in this space». Історія така: Kubernetes прийшов із внутрішніх напрацювань Google і вийшов на ринок у момент, коли було багато конкуруючих рішень для оркестрації контейнерів. Згадуються альтернативи на кшталт інших оркестраторів і навіть окремі платформи, які намагалися вирішити проблему мікросервісів і залежностей власним шляхом.
Розв’язка відома: завдяки кросплатформеності й тому, що великі хмарні провайдери підняли Kubernetes як керовану послугу, він поступово витіснив конкурентів і закріпився як стандартна платформа для запуску контейнеризованих робочих навантажень. Але далі починається менш очевидна частина історії.
У дискусіях про Kubernetes зазвичай звучать слова «cloud» і «cloud‑native», на конференціях демонструють інтеграції з AWS, Azure чи Google Cloud. Створюється враження, що це інструмент насамперед для публічної хмари. Та картина, яку описує Ерез, інша: значна частина реального використання відбувається далеко від глянцевого «cloud‑native» на слайдах.
On‑prem як норма: від власних VM до керованих кластерів
«The reality is a lot of customers actually use Kubernetes for running on premise», — наголошує Ерез. Йдеться не про поодинокі випадки: «A non-insignificant number of our customers… are running on potentially their own VMs on their own server farms or maybe they’re running VMs in AWS or Azure but they’re maintaining Kubernetes itself.»
Тобто навіть коли інфраструктура фізично розміщена в хмарі, для багатьох це все одно on‑prem‑парадигма: клієнт піднімає власні віртуальні машини, сам розгортає і обслуговує Kubernetes‑кластер, контролює версії, конфігурацію і політики. Причини типові для великих організацій — фінансовий сектор, урядові установи та інші структури з жорсткими вимогами до контролю, відповідності та безпеки. Вони хочуть «fully sort of control the process and manage the whole piece of infrastructure from end to end».
Для таких команд Kubernetes виступає як універсальний, зрозумілий шар абстракції над власною інфраструктурою. Навіть якщо сервери стоять у власному датацентрі або в колокації, а віртуальні машини запускаються в публічній хмарі, модель керування і для девів, і для опсів одна й та сама: декларативні маніфести, контролери, що стежать за бажаним станом, і знайомі примітиви — поди, деплойменти, сервіси.
Це знімає частину складності, яка традиційно супроводжувала on‑prem інфраструктуру. Команди можуть мислити не в категоріях конкретних серверів, а в термінах «desired state» — кількості реплік, типів сервісів, політик оновлення. І саме цей декларативний підхід, за словами Ереця, став ще одним аргументом на користь Kubernetes у світі, де вже прижилися Terraform, Puppet та інші інструменти інфраструктури як коду.
Kubernetes у POS-терміналі: кластери в кожному магазині
Один із найяскравіших прикладів, які наводить Ерез, стосується ритейлу. «Some of our customers have Kubernetes clusters basically in their point of sale systems… they have hundreds and hundreds of stores and they have little Kubernetes clusters that essentially run in them and each one’s independent.»
Мова про сотні, а подекуди й тисячі магазинів, де кожен POS‑вузол фактично є міні‑кластером Kubernetes. У кожному такому магазині живе своя незалежна інфраструктура, яка відповідає за локальні сервіси — і водночас підкоряється тим самим декларативним правилам, що й «великий» кластер у датацентрі.
Такий підхід вирішує кілька задач одночасно. По‑перше, забезпечує автономність: кожен магазин працює незалежно, без критичної залежності від центрального датацентру в режимі реального часу. По‑друге, дозволяє застосовувати знайомі інструменти — ті самі гілки конфігурацій, ті самі механізми оновлення і розгортання.
Але на цьому рівні з’являються й нові проблеми масштабу. Ерез описує, як клієнти, що будують тисячі таких кластерів і практикують GitOps‑підхід, стикаються з дуже приземленими обмеженнями: коли всі кластери регулярно тягнуть стан із одного git‑репозиторію, сам репозиторій може стати вузьким місцем. З’являються тротлінг, ліміти запитів і необхідність шукати обхідні шляхи, щоби підтримувати оновлення на такому рівні розподіленості.
Це показує Kubernetes не як «один великий кластер на всю організацію», а як платформу, яку можна вшити в сам край інфраструктури — аж до POS‑пристрою в кожній торговій точці.
Кластери посеред океану: коли корабель не в онлайні
Ще один кейс, який згадує Ерез, — наукові дослідницькі судна. «They’ve got Kubernetes clusters running on research vessels… they’ve got Kubernetes clusters out out in the open sea.»
Сюжети з «cloud‑native» світу зазвичай обмежуються датацентрами або, у кращому разі, edge‑локаціями поблизу мегаполісів. Тут же йдеться про кораблі у відкритому морі, де з’єднання з берегом може не бути тижнями чи місяцями. Кластери Kubernetes працюють на борту, обслуговують свої задачі, але для інженерів з’являється новий клас обмежень.
Головна з них — оновлення. «When you want to do a deployment that the ship’s not available. So when that ship comes back into port, it needs to get the update.» Іншими словами, звичні сценарії безперервного деплойменту, де кластери завжди «висять» у хмарі й можуть у будь-який момент витягнути новий маніфест, тут не працюють.
Потрібні процеси, які враховують фізичний цикл судна: вихід у рейс, період повної або часткової ізоляції, повернення в порт і лише тоді — отримання оновлень. Для таких сценаріїв Kubernetes знову виявляється зручним будівельним блоком: у момент, коли судно з’являється в досяжності мережі, воно може отримати весь пакет змін і привести свій стан у відповідність із бажаним.
Але це не «ідеальний cloud‑native», де все завжди онлайн. Це адаптація хмарних практик до дуже матеріальних обмежень: затримок, відсутності зв’язку, фізичної логістики. Та попри це платформа залишається тією ж самою — Kubernetes.
Конференції говорять про хмару, команди вирішують свої проблеми
Працюючи в Octopus Deploy, Ерез бачить широкий зріз індустрії — від фінансових організацій до ритейлу і дослідницьких проєктів. На цьому фоні він обережно відсторонюється від типової конференційної риторики.
«It’s easy to sometimes to get lost in… conferences… everyone’s saying it’s all about cloud… the reality is, you know, everyone’s kind of got their own little problems and they just want to solve them the way they kind of need to solve them.»
Це, мабуть, ключова теза до розуміння того, чому Kubernetes виграв не лише хмару, а й on‑prem. Не тому, що всім знадобилася модна «cloud‑native» архітектура, а тому, що платформа виявилася достатньо гнучкою, щоби вмістити дуже різні реальності:
- банки й урядові установи, які хочуть «full control» і роками не оновлюють версії, якщо «воно просто працює»;
- ритейл із сотнями мінікластерів у магазинах, де питання тротлінгу git‑репозиторію стає не теоретичним, а щоденним;
- наукові судна, де деплоймент відбувається не «по пушу в main», а коли корабель фізично пришвартувався.
У кожному з цих сценаріїв Kubernetes дає спільну мову для девів і опсів і дозволяє будувати CI/CD‑процеси навколо однакових примітивів, навіть якщо мережеві, організаційні чи регуляторні обмеження радикально різні.
Висновок: стандарт, який вийшов за межі хмари
Якщо судити за розповідями Ереця, Kubernetes уже давно перестав бути просто «cloud‑native» інструментом. Він став універсальним стандартом платформи виконання — і в хмарі, і в on‑prem, і на межі мережі.
Той самий механізм декларативного опису стану, автоматичної «continuous reconciliation» і уніфікованих примітивів однаково добре лягає на приватні серверні ферми, VM у публічній хмарі, магазини з POS‑терміналами та наукові судна.
І, можливо, головний урок, який випливає з цих історій, полягає не в технологіях, а в очікуваннях. Попри гучні тези про «усе в хмарі», значна частина індустрії продовжує будувати та обслуговувати власну інфраструктуру — просто тепер вона виглядає і працює як Kubernetes‑кластер. Саме це робить Kubernetes не лише «переможцем у хмарі», а й новим базовим стандартом для on‑prem світу, який навряд чи зникне найближчим часом.