От bare metal до managed Kubernetes: как устроен Cozystack
Во время поездки в ОАЭ участник проекта Cozystack случайно присоединился к дубайскому IT-сообществу в Telegram. Переписка быстро переросла в организацию небольшого митапа: 3 октября в Дубае собрались инженеры и обсудили архитектуру платформы - от операционной системы и хранилища до сетей и управления Kubernetes. Помочь с площадкой и координацией встречи вызвался участник сообщества Артём Гончаренко.
Cozystack - открытая платформа, предназначенная для запуска управляемых сервисов на собственной инфраструктуре. На встрече разбирали, как она связывает Talos Linux, Flux, LINSTOR, Kube-OVN, Cilium, KubeVirt, Kamaji и Cluster API. Главный вопрос - как превратить запрос пользователя на готовый сервис в работающую систему, не заставляя его самостоятельно собирать и обслуживать все компоненты. Подробный разбор архитектуры и обсуждения участников представлен в материале о том, как устроен Cozystack и managed Kubernetes на собственном оборудовании.
От виртуальных машин к готовым сервисам
В привычной облачной модели пользователь арендует виртуальную машину, устанавливает на неё базу данных, настраивает резервное копирование и мониторинг. Провайдер отвечает за инфраструктуру, а эксплуатация приложения остаётся на клиенте. Cozystack предлагает поднять уровень абстракции: вместо набора ресурсов заказчик может запросить PostgreSQL, Kubernetes-кластер или другой сервис, а платформа возьмёт на себя его развертывание и сопровождение.
Виртуальные машины при этом сохраняются как самостоятельный продукт и как основа для других решений. Например, рабочие узлы пользовательских Kubernetes-кластеров могут работать в виртуальной среде. Но запускать каждое приложение в отдельной VM необязательно: некоторые сервисы можно развернуть прямо в контейнерах, используя операторы и реплицируемое хранилище.
Слово managed подразумевает больше, чем автоматическую установку. Платформа должна помогать с мониторингом, резервным копированием, восстановлением после сбоев и управлением жизненным циклом. Все эти процессы важно сделать повторяемыми и предсказуемыми - независимо от того, в каком окружении работает сервис.
Система, хранилище и сеть
Для управления физическими узлами используется Talos Linux. Важное архитектурное решение - разделять конфигурацию системы и настройки конкретного узла: они меняются с разной частотой и требуют разных подходов к обновлению. В связке с декларативным управлением это упрощает обслуживание инфраструктуры и помогает поддерживать одинаковую конфигурацию машин.
Для хранения данных выбрали LINSTOR и DRBD. Такая связка позволяет реплицировать данные между узлами и размещать вычисления ближе к хранилищу. Соседство ресурсов важно не только для производительности: оно влияет на устойчивость к отказам и на то, насколько эффективно инфраструктура использует доступные серверы.
Сетевую архитектуру пришлось пересмотреть с появлением виртуальных машин. При этом Cozystack стремится сохранить знакомую модель Kubernetes и разделить уровни сети. Есть сеть физических узлов, сеть Pod, которую обслуживает CNI, и отдельная логика доступа к сервисам. Kubernetes Services не образуют самостоятельную физическую сеть: это абстракция, которую реализуют сетевые компоненты. Входящий и исходящий трафик также требуют разных механизмов настройки и контроля.
Kubernetes как сервис
Пользовательский API платформы работает поверх Flux: нужное состояние описывается декларативно, а контроллеры приводят реальные ресурсы к заданной конфигурации. Каталог приложений при этом должен расширяться независимо от базовой платформы - так можно добавлять новые сервисы, не перестраивая всю инфраструктуру. Мониторинг и управление доступом рассматриваются не как необязательные дополнения, а как часть готового продукта.
Для изоляции пользователей используется модель тенантов. Она позволяет задавать разные границы разделения ресурсов и сочетать общие платформенные сервисы с выделенными компонентами для отдельных заказчиков. Такой подход особенно важен, когда на одной инфраструктуре работают разные команды с неодинаковыми требованиями к безопасности и производительности.
Управление пользовательскими кластерами строится вокруг Cluster API и принципа Kubernetes внутри Kubernetes. Запрос на создание кластера преобразуется в набор декларативных ресурсов. В этой модели используются объекты MachineDeployment, MachineSet и Machine, а один управляющий кластер может обслуживать сразу несколько пользовательских. За разные участки жизненного цикла отвечают, в частности, CCM, CSI и Cluster Autoscaler.
Чем сложнее bare metal
В публичном облаке часть инфраструктурных задач уже решена провайдером: вычислительные ресурсы, control plane и хранилище могут обслуживаться независимо друг от друга. На bare metal платформе приходится выстраивать эти процессы самостоятельно - от подготовки серверов до выдачи ресурсов пользователям. Поэтому managed Kubernetes на собственном оборудовании требует не только Kubernetes, но и автоматизации физического уровня.
Особый случай - установка в закрытом контуре, где нет обычного доступа к внешним репозиториям и сервисам. Платформе нужно учитывать доступность образов и пакетов, а также организовать управление ресурсами отдельным слоем. Для физических серверов требуется собственный процесс provisioning - подготовки оборудования к работе и передачи его под управление системы.
Ещё один практический вызов - ускорители GPU. Важно не просто обнаружить устройство, но и корректно предоставить его контейнеру или виртуальной машине. В зависимости от сценария может потребоваться выделение GPU отдельному пользователю либо совместное использование ускорителя. Подобные задачи показывают, что Kubernetes на bare metal - это не только запуск контейнеров, но и согласованная работа вычислений, хранения, сети и оборудования.
Cozystack позволяет строить управляемые сервисы на собственной инфраструктуре, не ограничиваясь виртуальными машинами. Это может быть актуально компаниям, которым важно контролировать размещение данных, конфигурацию оборудования и расходы. При этом аренда bare metal серверов остаётся одним из вариантов получить физические ресурсы без необходимости самостоятельно покупать и размещать серверы: поверх них можно развернуть платформу и предоставлять сервисы пользователям.
Такой подход не отменяет виртуализацию, а делает её частью более широкой системы. Заказчик получает сервис через каталог, а платформа связывает в единый процесс подготовку узлов, Kubernetes, сетевые компоненты, хранилище и инструменты эксплуатации. Именно эта интеграция определяет, насколько удобным и надёжным окажется managed Kubernetes в реальной работе.
