Kubernetes — це справжнє зло. Погоджуєтеся?

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Знайшов на просторах інтернету статтю про те, чому Kubernetes — це зло. Хочу обговорити її, тому далі — переклад цієї статті. Якщо що, то зроблений від через ChatGPT, тому, якщо знайдете деякі неточності — не бийте 👀

Почну з визнання: я вважаю Kubernetes однією з найбільших перепон на шляху до справжніх інновацій у хмарних обчисленнях сьогодні.

От, я сказав це. Перш ніж ви візьметеся за вила і почнете твітити гнівні коментарі на кшталт «K8s масштабує!» чи «демократизує розгортання контейнерів» — дайте пояснити.

Бо під усією цією YAML-магією та гучними конференціями, на мою думку, ховається фундаментальна архітектурна помилка, яка гальмує всю індустрію.

У чому справжня проблема, яку варто було б вирішувати

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

Це не нова проблема. Ми вже бачили її в минулому — згадайте CORBA? Так, той стандарт з 90-х, який намагався забезпечити сумісність між різними системами. Схожа концепція, інша епоха, інші умови.

Якщо подумати, ідеальне хмарне розгортання виглядає просто: ти пишеш код і відправляєш його «вгору» в хмару. Мінімум проміжних кроків. Ідеально — миттєво. Написав — розгорнув. Готово.

(Я зараз не про тестування чи безпеку — це окремі етапи. Миттєве розгортання не заважає їм, а, навпаки, полегшує: система буде чистішою, передбачуванішою.)

Яким би мав бути ідеальний світ

В ідеалі ми мали б щось на кшталт Erlang чи Unison — мови, створені з думкою про розподілені обчислення. Але доступні для будь-якої мови програмування.

І знаєте що? Такі універсальні компоненти вже існують. Подивіться на WASI (WebAssembly System Interface) — це компоненти на основі WebAssembly, які можна скомпілювати з будь-якої мови у швидкий, кросплатформовий формат.

Це була б моя мрія: пишеш у чому хочеш, компілюєш мікросервіси в семантично значущі компоненти на WASI — і розгортаєш їх будь-де.

Подібний підхід вже реалізовано в Apache OpenServerless. Там фокус — на логіці компонентів, а не на мікроменеджменті інфраструктури.

Docker-катастрофа

А тепер — чим насправді стало стандартом у хмарі? Docker.

Що таке Docker, якщо по-простому: це бутерброд з образів дисків, куди можна запхати все, що завгодно, і потім запускати все це без будь-якого контролю поведінки — хоч воно старе, нестабільне чи повне лайна.

Вдумайтесь: ми будуємо хмарну інфраструктуру навколо концепції «компонента», яка взагалі не має визначення. Docker-компонент — це просто «образ з випадковим вмістом». Уся його «революція» — в економії місця у порівнянні з повними віртуалками. Все.

І от із цього сумнівного концепту ми зліпили весь Kubernetes, який по суті існує тільки для того, щоб якось керувати цим цифровим сміттям, намагаючись зробити вигляд, що з нього можна зібрати стабільну систему.

Чому Kubernetes такий важкий

Kubernetes важкий не тому, що розподілені системи складні (хоча це теж правда). Він важкий тому, що він — це збирач сміття.

Кожен компонент у кластері K8s може порушувати будь-які правила, жерти пам’ять без обмежень, крашитись, зациклитись — і це твоя проблема.
Немає жодних гарантій поведінки, немає угод, немає абстракцій. Тільки ти й хаос.

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

Симптоми?

• Нескінченні YAML-файли, які ніхто до кінця не розуміє;
• «Експерти Kubernetes», які вивчають магічні заклинання замість вирішення реальних проблем;
• Конференції, де обговорюють складні рішення для проблем, які не мали б існувати.

Це справжній карго-культ: ми виконуємо ритуали (писання Helm-чартів, налаштування service mesh, тюнінг ресурсів), не ставлячи питання «навіщо» і «чи справді це розв’язує проблему».

У чому ж тут вузьке місце для інновацій?

Коли твоя платформа настільки складна та ламка, інновації сповільнюються до повзання.

Стартапи, які мали б «рухатися швидко і ламати речі», витрачають тижні на налаштування CI/CD.
У корпораціях створюють окремі департаменти «платформної інженерії», щоб приручити звіра Kubernetes.
Когнітивне навантаження величезне. Втрати часу — колосальні.

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

Ефект замикання

Kubernetes також створив сильний ефект lock-in, який душить конкуренцію. Коли компанія вже вклалася у фахівців, інфру та тули, змінити підхід дуже важко.

Цей lock-in не лише технічний — він ще й культурний та організаційний. Якщо ти критикуєш Kubernetes — ти ніби ставиш під сумнів компетентність усієї команди.

І поки ми відловлюємо «впавші поди» й вчимося Helm’у, світ розподілених обчислень просувається в інших напрямах — без нас.

Платформи, де розподіленість вшита з самого початку й де абстракції мають сенс — залишаються в тіні Kubernetes-хайпу.

А що ж робити?

1. Визнати, що король голий. Kubernetes — це не неминучий наслідок складності. Це наслідок помилкової абстракції.
2. Інвестувати в кращі абстракції. WASI, WebAssembly, Erlang, Unison — це напрямки, де розподіленість працює по-іншому.
3. Не нашаровувати ще більше на Kubernetes. Кожен новий тул — ще одна латка. Система не стає від цього здоровішою.

Незручна правда

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

Вендори продають «Kubernetes management»-інструменти. Консультанти гребуть гроші. Конференції мають про що говорити.

Але ціна — інноваційна стагнація. Ми витрачаємо час не на створення нового, а на боротьбу зі створеним нами ж хаосом.

Час вирватись

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

Але іноді треба визнати: ми пішли не туди.

Хмара мала бути простою, масштабованою, швидкою.
Kubernetes — це складно, ламко й заплутано.
Ми можемо краще. Але тільки якщо будемо чесні.

Майбутнє хмар не повинно бути про менеджмент хаосу. Воно має бути про передбачувану поведінку за замовчуванням, вбудовані гарантії, і справжню роботу, а не танці з Helm-чартами.

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

Отож, чи погоджуєтеся ви з думками автора? Чи справді кубернетес — це така шляпа чи все таки автор помиляється?