Розробники й платформні команди хочуть самообслуговування в Kubernetes, але розходяться в тому, кому воно належить

Розробники хочуть отримувати середовища Kubernetes тоді, коли вони потрібні, а не через тиждень після черги заявок. Платформні команди відповідають за витрати, доступ і відповідність політикам компанії. Про цю суперечність The New Stack розповіли продакт-менеджери HPE Marius Bogoevici та Karthik Subramanian.

Kubernetes в апстрімі дає оркестрацію та декларативні API, але не повну операційну модель. За словами Subramanian, команди, які будують власний шар самообслуговування, стикаються з двома постійними проблемами. Перша — розростання інструментів і пакетів: для продакшену доводиться підтримувати набір проєктів CNCF для мережі (CNI), сховища (CSI), ingress, ідентичності та політик.

Де ламається самообслуговування, зібране власними силами

Друга — складність життєвого циклу після запуску та гібридної інфраструктури. Створити кластер легко; підтримувати його актуальним у середовищах розробки, QA, staging і продакшену значно важче, і, за словами HPE, кожне оновлення перевіряють на сумісність із сусідніми компонентами. Дрейф зростає, коли кластери розкидані по фізичних серверах, приватних і публічних хмарах та edge-майданчиках, а прямий доступ розробників до API лише переносить цю роботу.

Прокладений шлях, а не безмежний доступ

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

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

У швидкості свої ризики

У традиційному IT окреме середовище для нового проєкту проходить через заявки між командами інфраструктури, мережі, безпеки та сховищ і часто чекає від днів до тижнів. За словами HPE, об'єднання оркестрації, рольового доступу та мультитенантності в один операційний досвід скорочує ці процеси до хвилин або годин. «Коли час підготовки скорочується з тижнів до годин, це дуже відчутно», — каже Bogoevici.

Швидкість має і зворотний бік: команди втрачають облік того, що було створено і навіщо. Противага — видимість використання й витрат і контролі, що вимикають тимчасові кластери. Bogoevici вважає кількість заявок поганим показником успіху: краще дивитися на успішність деплойментів, частку винятків і використання ресурсів. Безпека, додає він, має бути частиною дизайну сервісу, тож ідентичність, RBAC, ізоляція тенантів і політики приходять разом із середовищем.