Чому не варто використовувати Kubernetes

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

DevOps Engineer з Франції Поль Бріссо, який спеціалізується на роботі з системами логування та моніторингу з використанням контейнерних рішень, у блозі на Medium поділився своїми думками, чому не всім потрібен Kubernetes. Ми переклали статтю українською і цікаво, що ви на це скажете.

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

Слабкі сторони Kubernetes

Надто складно

Kubernetes має чималий API, який можна нескінченно розширювати для додавання функціональності. Тому після розгортання нового кластеру багато необхідних компонентів відсутні або не дуже придатні для використання. Розробникам часто доводиться починати роботу з Kubernetes із встановлення Ingress-контролера (реверсивний проксі, що слухає вхідний трафік) або сховища даних. Крім того, вам доведеться звернутися до сторонніх розширень, щоб додати моніторинг, безпеку чи інші доповнення.

Усі ці доповнення вимагатимуть від вас відповідних технічних навичок, щоб їх інсталювати, налаштовувати та підтримувати в актуальному стані. Крім того, ці компоненти потребуватимуть ресурсів процесора та оперативної пам’яті, що збільшить використання ресурсів кластеру і, як наслідок, коштів.

Невелика частина екосистеми Kubernetes. Джерело: CNCF Landscape

Надто дорого

Kubernetes, як і будь-яка кластерна система, вимагатиме більше ресурсів для хостингу навіть найпростішого додатка через забезпечення відмовостійкості та масштабування (контролер кластеру, Ingress контролер і т.д. — ред.). Якщо ми додамо до цього майже обов’язковий технологічний надлишок, згаданий у першому пункті, ми отримаємо додаткові витрати. Хмарні рішення для Kubernetes (Google Kubernetes Engine (GKE), Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS)) пропонують трохи більше гнучкості щодо розміру кластера (автоматичне надання вузлів / широкий вибір розмірів віртуальних машин), проте з ними треба дуже уважно контролювати всі витрати на інфраструктуру.

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

Зміна методології розгортання

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

Чи зробили ми крок назад порівняно з тим, що робили раніше? Ні, якщо цей розрив нівелюється відповідними інструментами, сумісними з новою процедурою. Використання Kubernetes поза гарно налаштованого CI/CD механізмів є величезною помилкою. Побудова належного робочого процесу GitOps необхідна для економії часу, впевненості та спокою під час розгортання. Але це також означає освоєння нових технологій і додаткові витрати.

Приклад робочого процесу GitOps з ArgoCD

Конкуренти

Для початку визначимось, хто «вони»? Для мене основними конкурентами Kubernetes є сервіси PaaS (Platform as a Service), FaaS (Function as a Service) і CaaS (Container as a Service). Я не беру до уваги Kubernetes-подібні (Openshift або Nutanix Karbon), оскільки вони мають ті самі симптоми, що й їхній старший брат.

PaaS і FaaS схожі, оскільки дають можливість розгортати та виконувати скомпільовані програми в розділених середовищах. FaaS — це служба хмарних обчислень, з допомогою якої розробники додатків отримують простий спосіб запуску та управління — з допомогою виконання коду у відповідь на подію, тоді як PaaS призначений для більш сталих додатків (вебсайтів, серверної частини). CaaS дозволяє виконувати образ певного контейнера.

Ось неповний перелік таких послуг:

Приклади послуг PaaS / FaaS / CaaS

Першою перевагою цих сервісів є простота використання. Ви підключаєтеся, налаштовуєте, і через 10 хвилин готово! Нема потреби знати технологію, яка стоїть за цим (навіть якщо з 99% ймовірності це контейнер у кластері Kubernetes); це просто працює. Більше ніяких нічних оновлень і жодних міграцій до іншого центру обробки даних у вихідні. Крім того, для PaaS і FaaS вам не потрібно створювати образ Docker для вашої програми; платформи працюють на вас! Хіба життя не величне?

Звичайно, за всі ці переваги доведеться заплатити вашою свободою дій.

Порівняння Kubernetes з іншими платформами

Найсуттєвішою перевагою цих платформ є ціна. Ви можете розмістити свою програму всього за кілька доларів на місяць і скористатися перевагами автоматичного масштабування або сертифіката TLS. Проте остерігайтеся прихованих витрат; деякі платформи стягують плату за моніторинг або обмежують кількість розгортань на місяць.

Випадки, коли Kubernetes перемагає

І хоч конкуренти достойні, проте їм далеко до Kubernetes.

Саморозміщена (Self-hosted) / гібридна інфраструктура

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

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

Гібридна архітектура з Banzai Cloud

Програми з підтримкою збереження стану

Описані в попередньому розділі сервіси в основному використовуються для розміщення програм в форматі «без збереження стану» (stateless). Ваш додаток має мати можливість горизонтального та вертикального масштабування, через це неможливо зберегти дані, створені конкретною реплікою вашої програми, наприклад, кеш. Тож забудьте про ідею розміщення баз даних у таких сервісах напряму, це не працює! Замість цього вам доведеться звернутися до спеціалізованих хмарних служб, таких як MongoAtlas або CloudSQL.

Kubernetes також заточений на підтримку програм в форматі «без збереження стану» (stateless), ба керування такими програмами там набагато легше! Але за допомогою розширення StatefulSets і підтримкою сховищ даних запуск бази даних у Kubernetes не тільки можливий, але й працює у продакшені.

Бізнес-логіка в Kubernetes

Ми підійшли до основного, але не найочевиднішої переваги використання Kubernetes — він має розширюваний API, що підтримує реалізацію кастомної бізнес-логіки для ваших конкретних задач. Ви можете створити, наприклад, новий спеціальний ресурс під назвою «Клієнт», який, опинившись у кластері, дозволить вам керувати спеціальною таблицею стилів або новим записом DNS.

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

Висновок

Незважаючи на те, що Kubernetes не дуже простий, він є повним та прозорим рішенням для підтримки глобальної інфраструктури. Однак на початкових етапах розробки додатків сервіси PaaS / FaaS дозволять вам більш ефективно розміщувати свої послуги, заощаджуючи гроші.

А яка ваша думка, спільното?