Хабр, привет! На связи команда облачного провайдера Nubes.
Когда мы решили запустить собственный Kubernetes as a Service, на поверхности все выглядело просто: развернуть кластеры, завернуть в удобный интерфейс и добавить автоматику. На практике же оказалось, что «ванильный» Kubernetes, Kubespray и вендорские платформы порой приносят хаос вместо готового сервиса.
В этой статье рассказываем про наш путь, ставший чередой компромиссов, от которых мы устали. Как вместо трех лет разработки мы уложились в два месяца и от попыток собрать решение своими силами дошли до полноценного KaaS, построенного на базе платформы «Штурвал».
С чего все начиналось: Tanzu и первые разочарования
Как и многие, мы начали с использования решения от крупного зарубежного вендора — VMware Tanzu. Довольно быстро стало понятно, что для нашей модели оно не подходит, и вот почему:
Жесткий vendor lock — где сейчас «Варя» и каково ее будущее?
Низкое качество кодовой базы — любое минорное обновление грозило поломкой, создавая паутину зависимых версий всего стека, от vCloud Director до операционной ��истемы на узлах.
Сложный жизненный цикл услуг — высокие риски разрушить весь «карточный домик» при обновлениях из-за архитектуры решения. Она представляет собой стек из множества компонентов с жесткими зависимостями, где обновление одного слоя требует синхронного обновления остальных, а ошибки плохо изолируются и сложно откатываются.
Поддерживать такое решение в проде и масштабировать его как услугу было бы слишком рискованно.
Параллельно мы попробовали пойти классическим путем — построить сервис своими силами бывших *nix-инженеров. От «ванильного» K8s отказались сразу и стали пилить его на базе Kubespray, но быстро поняли, что это путь в эксплуатационный ад. Один кластер еще можно обслуживать, а что делать, если их десятки? Получается зоопарк версий, бесконечные ручные доработки и обновления через «снести и пересоздать». Мы тонули в операционной текучке, из которой с таким трудом когда-то выбрались.
Нам нужен был фундаментально иной подход — надежный, универсальный и избавляющий от рутины. Было два варианта:
Уйти в собственную разработку платформы.
Проанализировать рынок и найти коммерческое решение, подходящее под наши требования.
Первый вариант мы сразу отмели. ~3 года разработки, серьезные инвестиции и высокие риски. Это нам не подходило.
Требования к решению
Перед тем как идти на рынок, мы сформулировали определенный список требований:
Уход от Vendor Lock
Мы стремились уйти от зависимости от конкретного вендора и создать универсальную систему, способную нативно работать не только с vCloud Director, но и с другими гипервизорами, например, на базе KVM. На практике, правда, мы все равно столкнулись с проблемами интеграции в VMware, например, с балансировщиком AVI, чего хотелось бы избежать.
● Готовая платформа управления Kubernetes
С возможностью централизованного управления «по кнопке» и наличием множества сервисов. Так как создавать с нуля дорого и долго.
● Автоматизация всего жизненного цикла
Образы ВМ, узлы, сети, Load Balancer, доступы — все должно собираться и обновляться автоматически.
● Минимум ручной работы и зависимости от инженеров
Для эксплуатации необходимы один-два инженера. Это могут быть специалисты и с небольшим опытом работы с Kubernetes.
Мы посмотрели на Rancher и Cluster API. Но у первого тоже были проблемы с жизненным циклом и обновлениями. Второй вариант был интересней, так как Cluster API умеет работать с большим количеством облачных платформ.
При использовании VMware Tanzu мы столкнулись с проблемой размывания ответственности. Команда виртуализации могла развернуть инфраструктуру, но при возникновении проблем с K8s она тут же заявляла: «Это не наша зона ответственности». При этом у инженеров, способных разобраться в проблеме, часто не было доступа к окружению Tanzu. В итоге, когда система работала нестабильно, выяснялось, что никто толком не понимает, что происходит и как это восстанавливать.
С балансировщиком AVI сложилась схожая ситуация. В штатном режиме он функционировал без нареканий, однако любая деградация, например, небольшая потеря пакетов, оборачивалась полной неопределенностью. Отсутствовали читаемая конфигурация, детальные логи для отладки и трассировки.
Также Cluster API не дает REST API и UI. Это нужно разрабатывать с нуля дополнительно. Еще нам хотелось дать пользователям возможность тонкой настройки, но при этом не давать им доступ, поэтому очень важным критерием стало наличие в решении автоматической конфигурации узлов.
В итоге вариант с чистым Cluster API тоже оказался неудобным, нужно было его сильно допиливать до рабочего состояния.
Пытаясь решить эти проблемы, мы узнали о платформе «Штурвал». Продуктовая команда уже имела опыт подобных интеграций и понимала нашу боль, а также была готова дорабатывать функциональность под vCloud Director и чинить его в случае сбоев и неполадок.
«Из коробки» платформа уже давала модульную архитектуру, развитое REST API для интеграций, автоматическую конфигурацию узлов, удобный UI для управления кластерами и встроенный Cluster API.
Что допиливали
Но без доработок со стороны обеих команд не обошлось.
Основная проблема была связана с особенностями vCloud Director. Это сложный продукт со своими ограничениями и неочевидными сценариями работы. Пришлось дорабатывать сам провайдер и Cloud Controller Manager (CCM), чтобы обеспечить стабильную интеграцию. Для удобства тестирования команда «Штурвала» форкнула Cluster API provider vCloud Director и CCM, а мы выделили отдельные контуры: для управляющего кластера и для тестирования клиентского кластера. Проверка велась с обеих сторон: разработчик отрабатывал инфраструктурную часть и интеграцию провайдера, мы смотрели, как сервис будет выглядеть для конечных пользователей. Если возникали сбои, почти всегда причина была на стороне vCloud Director, например, из-за недостатка прав или еще чего другого.
Нетривиальной проблемой стала сеть — взаимодействие API, настройка балансировщиков и корректная работа ингрессов. Только по исходным кодам получилось понять и скорректировать логику и в итоге обеспечить корректное распределение трафика и автоматическое создание внешних балансировщиков при развертывании кластера. После совместных отладок все заработало так, как и было задумано.
Чтобы удовлетворить все требования по безопасности, в частности изоляцию технических учетных записей и разграничение доступов между пользователями, коллеги из «Лаборатории Числитель» доработали механизмы инициализации узлов и cloud controller manager (CCM).
В остальном все было готово. Интеграция от идеи до запуска в прод заняла около двух месяцев.
Процесс для пользователя выглядит так:
Создание кластера начинается в интерфейсе Nubes.
После пользователь переходит в интерфейс «Штурвала».
У пользователей есть администраторские права в своем кластере. Они могут масштабировать узлы кластера и настраивать автоскейлинг, при этом не взаимодействуя с vCloud Director.
Назначение прав и аутентификация работают «из коробки»: интеграция с Keycloak обеспечивает единый вход, а подключение к системам мониторинга и логирования происходит автоматически.
Кстати, все эти доработки вошли в официальный релиз «Штурвал 2.11».
Итоги
Благодаря совместной работе мы получили:
Запуск KaaS за два месяца вместо нескольких лет.
Централизованное управление кластерами K8s.
Минимальную нагрузку на инженеров — для эксплуатации нужны один-два специалиста.
Возможность гибридных сценариев — кластеры можно разворачивать не только в облаке Nubes, но и в собственных ЦОДах.
Важная особенность, которая появилась из синергии облака Nubes и «Штурвала», — это возможность разворачивать кластера K8s не только на мощностях Nubes в облаке, но и у себя в ЦОДе на собственных серверах, или в любом другом облаке, при этом получая централизованное управление. Хотя логика vCloud Director не переносится на другие облака, например, OpenStack или vCenter, сам подход остается универсальным. «Штурвал» построен на основе Cluster API, и он поддерживает множество разных инфраструктурных провайдеров, каждый из которых реализует взаимодействие с конкретным облаком или гипервизором.
Получается, мы можем предоставлять не только кластер «Штурвала» как сервис, но еще и ресурсы, чтобы на них развернуть уже Kubernetes-кластер. Так, заказчики смогут полностью контролировать платформу, при этом разворачивать кластеры как в своей инфраструктуре, так и в разных облаках.
Этот опыт показал, что даже сложные корпоративные решения можно адаптировать при условии плотного взаимодействия двух команд. Главное здесь — единое понимание целей со стороны технических и коммерческих команд.
