Перетворюємо Kubernetes на повноцінний приватний Cloud: кейс Kube-DC

Kubernetes може бути не лише платформою для контейнерів, а й повноцінним приватним Cloud, який легко адаптується під потреби бізнесу. Володимир Цап, CTO SHALB, під час виступу на DevOps fwdays’25 презентував підхід до розширення можливостей Kubernetes із перетворенням його на повноцінний приватний Cloud із підтримкою віртуалізації, ізольованих мереж та мультиорганізаційної аутентифікації. Він розповів, як додати повноцінну віртуалізацію в Kubernetes, запускати традиційні віртуальні машини поряд із контейнерами, ефективно керувати ресурсами та зберігати гнучкість для DevOps команд. А також як ізолювати трафік та сегментувати мережі для кожного неймспейсу, забезпечити Multitenancy та надавати гнучку авторизацію для різних користувачів та організацій. High Bar Journal публікує конспект його лекції. 

Основні компоненти Cloud-інфраструктури

Cloud — це комплексна екосистема, що включає віртуалізацію, мережеву інфраструктуру, сховища, підтримку багатокористувацької архітектури (multitenancy), контроль доступу (IAM), керовані сервіси, а також автоматизацію через API та Infrastructure as Code. Будь-який Cloud побудований на Linux-серверах і використовує віртуалізацію або контейнеризацію для ізоляції робочих навантажень. Найскладніший аспект — мережа: від Software-Defined Networks (VPC) до глобальних магістралей передачі даних.

Ключова відмінність Cloud від традиційних дата-центрів — Multitenancy, яка передбачає, що одна фізична інфраструктура обслуговує кілька організацій, але вони не можуть взаємодіяти між собою. Наприклад, запущені процеси не «бачать» ресурси сусідніх клієнтів на тому ж сервері. Контроль доступу реалізується через IAM — систему управління ідентифікацією та доступом, яка містить ролі, політики та механізми аутентифікації.

Автоматизація через API дозволяє керувати ресурсами програмно, а гнучке ціноутворення дає змогу оптимізувати витрати. Отже, Cloud — це не просто віртуалізована інфраструктура, а нова парадигма, орієнтована на автоматизацію, масштабованість і ефективне використання ресурсів.

Які переваги Cloud? Великі провайдери (hyperscalers) пропонують чітко визначені SLA з високими гарантіями доступності. Проте на практиці мало хто реально звертається до них. Багато дев’яток виглядають вражаюче, але вони не означають повну відсутність збоїв. 

Чи правда, що Cloud забезпечує вищу доступність, ніж on-prem? Питання відкрите. Датацентр із належним живленням і охолодженням може працювати безперебійно роками.  Десяток серверів у датацентрі в Україні не впали жодного разу навіть під час війни, обстрілів і блекаутів. Водночас один невдалий апдейт чи збій Cloud може вивести з ладу цілий регіон AWS або Azure, і такі випадки траплялися.

Одна з найбільших переваг Cloud — доступ до менеджмент-сервісів, які значно спрощують роботу. Але що як я скажу, що з Kubernetes ми можемо отримати практично все те саме? 

Bare Metal для власної інфраструктури

Розглянемо типовий кейс: компанія витрачає $10 000 на місяць в AWS або Azure, використовуючи стандартний стек — VMs, Kubernetes, RDS, S3, DNS. Але якщо перенести цю ж інфраструктуру на bare metal сервери, наприклад, у Hetzner, витрати можуть скоротитися до 80% для окремих сценаріїв.

Крім питання доступності, основним аргументом на користь публічних Cloud є зручність. API, автоматичне масштабування, готова екосистема — усе це економить час і спрощує життя DevOps-інженерам. Середньостатистичний інженер сьогодні знає один із Cloud-провайдерів (AWS, GCP, Azure) і, майже гарантовано, Kubernetes. Якщо ми побудуємо рішення, що використовує Kubernetes на bare metal, це не лише здешевить інфраструктуру, але й спростить її адміністрування.

Сьогодні типовий стек виглядає так:

• Bare Metal

• Гіпервізор (для віртуалізації)

• VM-оркестратор (керує віртуальними машинами)

• Віртуальні машини

• Kubernetes на VM

• Контейнери та застосунки

Але якщо прибрати зайві рівні абстракції, можна запустити Kubernetes безпосередньо на bare metal. Це дозволить одразу деплоїти застосунки та, якщо потрібно, запускати VM у самому Kubernetes.

Якщо будувати свою інфраструктуру, варто подивитися на існуючі рішення.

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

Власне рішення. Як виглядає Kube-DC

За свою кар'єру я створив безліч проєктів. Щоразу це виклик, який починаєш і ведеш з ентузіазмом. Коли маєш мало досвіду, але багато амбіцій, ти робиш багато помилок. Коли досвіду вже достатньо, зазвичай енергії на такі експерименти вже не залишається — адже рішення вже існують, тож навіщо пробувати?

Отже, ми вирішили зробити свою систему, бо, як казав Лесь Подерв’янський, «жить нужно інтєрєсно». 

Модель має виглядати так: є клієнти (А, Б), яким потрібна чітка сегментація. Для цього реалізовуємо концепцію тенанта, в межах якого є:

• віртуальні машини,

• поди, контейнери, деплойменти,

• окремий VPC, фаєрволи, VLAN,

• можливість запускати власні Kubernetes-кластери,

• керована база даних та інтеграція з підлеглою інфраструктурою.

Кожен клієнт працює в ізольованому середовищі та не бачить інших користувачів системи. Ми створюємо один керований Kubernetes-кластер на 5000 нод і ріжемо його на 20-30 організацій. Кожна організація отримує акаунт, подібний до AWS Organization.

Реалізація multitenancy

Kubernetes за замовчуванням не має вбудованого механізму управління користувачами, як у традиційних IAM-системах. Є зовнішній OIDC і декілька механізмів авторизації. Починаючи з версії 1.30, з’явилася підтримка множинних OIDC-клієнтів. Це дозволяє кожній організації логінитися через свого провайдера: Active Directory, Google Login, Okta тощо.

Для керування доступами ми використали Keycloak — найбільш гнучке рішення з CNCF-стеку. Написали власний оператор, який керує створенням організацій, груп користувачів та доступами через CRD. Наприклад, адміністратор створює організацію через CRD, вказує проєкти та дефолтну мережу. Групи користувачів (наприклад, девелопери, адміни) отримують доступи на рівні проєктів через YAML-декларацією.

Результат — кастомне multitenancy-рішення, яке імітує модель AWS/GCP, але працює на нашому bare metal зі значно нижчими витратами.

Отже, ми побудували систему, в якій реалізована авторизація та multitenancy. В ній різні організації авторизуються незалежно одна від одної, є ролі та permissions, що дозволяють гнучко керувати доступом до проєктів.

Наш оператор синхронізує Keycloak із діями, які відбуваються в UI. Kubernetes API виступає як місток, що об’єднує всі сервіси. При цьому немає окремого монолітного сервісу — тільки Kubernetes-контролери, які взаємодіють із кластером, Keycloak та іншими компонентами системи.

Мережева ізоляція в Kubernetes

Одна з найскладніших проблем — це flat networking у Kubernetes. За замовчуванням усі поди можуть взаємодіяти один з одним в межах однієї мережі. Нам це не підходило: кожна організація та кожен проєкт повинні мати свою ізольовану мережу (аналог VPC у cloud-платформах), сервісна мережа повинна мати окремі адресні простори, а також передбачається, що користувач не має доступу до загальної інфраструктури датацентру.

Kubernetes не надає інструментів для цього з коробки, тому ми знайшли перспективний  китайський проєкт Kube-ovn — це CNCF-рішення, побудоване за принципами Software-Defined Networking (SDN), аналогічними OpenStack. Його основа — Open vSwitch, який дозволяє:

• керувати мережевими маршрутами,

• сегментувати мережі,

• інтегрувати з фізичною інфраструктурою (VLAN, overlay-мережі).

Надбудовуючи цей стек, ми створили власний контролер для управління VPC, сабнетами, зовнішніми IP та маршрутизацією трафіку. По суті, ми реалізували Cloud-модель у Kubernetes, використовуючи kubeVN, Open vSwitch і Multus.

Складним завданням було написати власний load balancer, адже який Cloud може обійтися без балансування трафіку. Kubernetes має сервіс LoadBalancer, який зазвичай делегує створення балансера провайдеру. У публічних хмарах це працює просто: ми робимо запит, і AWS чи GCP надають готовий балансер. Але на bare metal такого немає, тож нам довелося створити власне рішення.

Наш контролер керує маршрутами на рівні Open vSwitch, що дозволяє:

• експозити Ingress-трафік,

• балансувати навантаження між подами, віртуальними машинами, автоскейлінг-групами,

• інтегрувати балансер із серверлес-функціями (аналог лямбд).

  
  

Усі правила маршрутизації ми описуємо декларативно через YAML-конфігурації. Це дає змогу повністю контролювати трафік усередині проєкту — як зовнішній, так і внутрішній.

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

Маючи налаштовані мережу, авторизацію й автентифікацію, наступний крок — віртуалізація, оскільки багато ворклоадів потребують ізольованого середовища. Оптимальне рішення — KubeVirt, який підтримують великі компанії, зокрема NVIDIA та Red Hat. Це фактичний стандарт для запуску віртуальних машин у Kubernetes.

Принцип роботи: запускається под, у ньому — QEMU, який забезпечує віртуалізацію на наших хостах. Нам було критично важливо, щоб KubeVirt підтримував GPU passthrough, адже GPU-навантаження стає дедалі більшою частиною інфраструктури. Також потрібна підтримка автоскейлінгу для динамічного управління кількістю віртуалок, подібно до cloud-рішень.

Для моніторингу ми використовуємо Grafana Alloy. Білінг реалізований просто: кожна сутність (под, мережа) має свої метрики, які агрегуються під неймспейси або ворклоади і збираються в Prometheus. Далі ці дані пакуються в PostgreSQL. Основне сховище для конфігурацій та стану системи — etcd Kubernetes.

Оновлення Kubernetes на тисячах хостів із десятками тисяч клієнтів — непросте завдання. Ми використали K3S, оскільки це легковажний бінар із вбудованим System Upgrade Controller. Він дозволяє задавати оновлення через декларативні маніфести: менеджмент-кластер розгортає зміни, перезапускає K3S на хостах і підтримує оновлення всієї інфраструктури.

Наше рішення дозволяє будувати повноцінну Cloud-екосистему на bare metal:

• Namespace є аналогом Cloud-акаунту, з власними VPC, сабнетами, Load Balancer и persistent volume.

• CSI-драйвер забезпечує спільний доступ до сховища.

• Cluster API дозволяє розгортати керовані Kubernetes-кластери.

• vCluster дає можливість запускати lightweight Kubernetes-кластери всередині неймспейсу.

• Kamaji забезпечує керований control plane, подібний до EKS.

• Підтримується underlay-мережа для інтеграції з legacy-інфраструктурою.

Оскільки рішення побудоване на базових компонентах Kubernetes, його можна розвивати аналогічно до будь-якого Cloud-провайдера. Підтримуються керовані бази даних, Kafka, Redis, AI-ворклоади, LLM та інші сучасні технології.

UI: як це працює

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

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

• підключитися через VNC — клік на посилання, відкривається VNC, і можна одразу працювати з VM;

• запустити SSH-термінал — без агентів чи додаткових налаштувань, усе працює «з коробки»;

• переглянути моніторинг — вбудовані базові метрики, які можна розширювати через Prometheus. Аутентифікація підтримує OpenID, тож можна керувати великою кількістю клієнтів одночасно.

Також можна змінювати конфігурації віртуалки: додавати CPU та RAM через Hotplug без перезавантаження або підключати нові томи без зупинки VM.

Робота з мережею

До мережі підключена Debian-віртуалка з внутрішнім IP. Вона отримує floating IP — зовнішню адресу, яку можна легко прив’язати до неї. Усе це миттєво відображається в UI.

Додатково можна налаштувати лоадбалансер, який буде розподіляти трафік. Наприклад, якщо потрібно забезпечити доступ до 22 порту SSH, можна використовувати лоадбалансер для маршрутизації запитів на цей порт до відповідної VM. Для економії зовнішніх адрес можна використовувати спільний NAT IP.

Так само просто створюються Kubernetes-кластери:

• Повноцінний кластер для розробників піднімається за 2 хвилини.

• Легковажний vCluster, якщо потрібно лише ізолювати середовище.

Проєкт може покрити всі сценарії: від невеликих розгортань на Hetzner до масштабних продакшн-інфраструктур.

Простота для розробників

Ще одна категорія користувачів — розробники. Їм потрібна можливість швидко й без ускладнень деплоїти свої сервіси у Kubernetes-неймспейси, налаштовувати інгреси, редагувати ConfigMap.

Як це працює:

• Якщо потрібно запустити VM, обираю CentOS, задаю 3 CPU, 4 GB RAM, вибираю мережу.

• Система пропонує відповідний YAML, який можна кастомізувати: змінити ресурси, додати диски, оновити user data.

• Після підтвердження VM миттєво стартує.

Таким чином, немає потреби у Terraform. Усі ресурси описуються як Kubernetes-об’єкти. Увесь проєкт, разом із мережею, віртуалками та persistent volume, можна заархівувати через Velero й перенести в інший кластер. Це знайома модель для Kubernetes-ворклоадів: аналогічна до AWS, але без зайвої складності, з мінімальною кількістю анотацій та значною економією на інфраструктурі.

Що далі

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