Cozystack v1.0 и v1.1: представляем пакетную архитектуру, Cozystack Operator, контроллер стратегии Velero, поддержку MongoDB и OpenBAO

Автор: Timur Tukaev (Ænix)

Последним релизом платформы был 0.41. Поэтому стало неожиданностью, что следующий релиз, 0.42, оказался ответом на главный вопрос жизни, Вселенной и всего остального. Накопилось слишком много серьёзных изменений — настолько много, что 0.42 пришлось переименовать в 1.0.

С выпуском v1.0.0 Cozystack переживает фундаментальный архитектурный переход. Мы построили пакетную систему на основе FluxCD и OCI-артефактов — представьте себе apt для Debian/Ubuntu, но сделанный для Kubernetes (см. «Пакетное развёртывание» ниже). Это позволило нам представить уникальный новый подход: Build Your Own Platform (BYOP).

Мы наконец-то отказались от старых bash-скриптов, которые раньше отвечали за логику платформы, и заменили их полноценным оператором. Теперь этот оператор устанавливает все системные компоненты платформы.

Вся логика платформы теперь строится вокруг двух CRD: Package и PackageSource.

  • PackageSource определяет источник пакета, напрямую ссылаясь на Git- или OCI-репозиторий.
  • Package отражает желание пользователя установить определённый пакет.

Оба ресурса имеют область видимости уровня кластера (то есть не привязаны к какому-либо конкретному пространству имён) и могут управляться напрямую через cozypkg, kubectl или через Helm-чарт платформы.

Этот новый подход обеспечивает более надёжный способ установки, настройки и управления компонентами платформы, сохраняя логику системы простой и согласованной.

Теперь у вас есть два варианта:

  • Использовать Cozystack как готовую платформу со всем предустановленным (как и раньше). В этом случае чарт платформы автоматически устанавливает все необходимые Packages.
  • Собрать свой собственный Cozystack. В этом случае чарт платформы устанавливает только PackageSources для текущих версий компонентов, а вы с помощью cozypkg выбираете и устанавливаете нужные вам Packages.

Установка всегда начинается с cozystack-operator. Как только он запущен и работает, пользователь может установить основной пакет cozystack-platform. После этого можно выбрать один из нескольких вариантов платформы:

PackageSource: cozystack.cozystack-platform
Available variants:
  1. default
  2. isp-full
  3. isp-full-generic
  4. isp-hosted
Select variant (1-4): 1

Варианты isp-full, isp-full-generic и isp-hosted предоставляют полнофункциональные конфигурации Cozystack, адаптированные под конкретные сценарии использования. В варианте default устанавливаются только PackageSources, а не сами Packages. Затем пользователь может изучить доступные пакеты через cozypkg, выбрать нужные и установить их вместе со всеми зависимостями. В отличие от Debian/Ubuntu, пакеты Cozystack поставляются в разных доступных вариантах (flavors). Например, пакет cozystack.networking — от которого зависит большинство остальных — поставляется в комплекте с kubeovn-cilium, cilium, cilium-kilo или noop. Noop ничего не делает, но помогает удовлетворить зависимости — удобно для существующих кластеров Kubernetes.

Вы также можете создать свой собственный репозиторий, подключить его к Cozystack и устанавливать пакеты прямо из него.

В пакетной системе теперь используется новый механизм Flux — Source Watcher. По сути, Cozystack стал одним из первых, кто внедрил новый API FluxCD, позволяющий пользователям определять и размещать пользовательские репозитории без необходимости собирать собственные чарты. Мы также устранили классическую проблему «курицы и яйца» (Cozystack устанавливает всё через Flux — включая CNI и kube-proxy — тогда как самому Flux требуется работающая сеть, чтобы загрузить чарты). Теперь Cozystack опирается на source-watcher (часть самодостаточного инструмента flux-aio), который автоматически извлекает исходники чартов из Git- или OCI-репозиториев, собирает их в готовые к установке артефакты и затем разворачивает.

В конечном счёте это приближает нас на шаг к тому, чем Cozystack всегда стремился быть: уютный, гибкий технологический стек, который вы можете сделать полностью своим (подробнее см. в документации).

Помимо этого фундаментального сдвига, в этой версии дебютирует комплексная система резервного копирования, включающая расширяемый API и реализацию резервного копирования виртуальных машин на основе Velero, а также шардинг Flux для улучшенного распределения ресурсов арендаторов. Пользователи также обнаружат расширенные возможности мониторинга наряду с различными улучшениями производительности и рабочих процессов для виртуальных машин, управления арендаторами и процессов сборки. Вдобавок теперь вы можете развернуть полнофункциональную базу данных MongoDB с автомасштабированием, резервным копированием и отказоустойчивостью из коробки.

image02.png

Критические изменения

Прекращение поддержки FerretDB

Мы полностью удалили этот компонент из платформы. Автоматической миграции нет, поэтому обязательно создайте резервную копию данных перед обновлением, если вы всё ещё используете FerretDB!

MySQL теперь MariaDB

Пакет «MySQL» был переименован в «MariaDB» — на самом деле мы всё это время использовали mariadb-operator.

VirtualMachine (simple) заменён

Этот ресурс был заменён двумя отдельными — VMDisk и VMInstance — что даёт вам более нативный для Kubernetes и детальный контроль над виртуальными машинами.

Переименование API: CozystackResourceDefinition → ApplicationDefinition

Чтобы повысить ясность и обеспечить согласованность в рамках экосистемы, CRD CozystackResourceDefinition был переименован в ApplicationDefinition.

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

Пакетное развёртывание

Этот релиз знаменует значительный переход в том, как платформа управляет развёртываниями. Мы отошли от традиционных бандлов HelmRelease в пользу ресурсов Package, которые теперь оркеструются напрямую cozystack-operator.

Были внесены следующие изменения:

  • Файл values.yaml был полностью реструктурирован, чтобы предоставить исчерпывающие параметры конфигурации. Теперь он включает полную поддержку сети, публикации, аутентификации, планирования, брендинга и управления ресурсами.
  • Мы добавили values-isp-full.yaml и values-isp-hosted.yaml, чтобы предоставить специализированные конфигурации для разных сценариев развёртывания.
  • Стандартные ресурсы Package заменили шаблоны HelmRelease по всей платформе.
  • Вся конфигурация для Cozystack-как-платформы теперь выполняется через параметры ресурса Package для cozystack-platform, а не через ConfigMap

Для существующих установок мы предоставили скрипт миграции, расположенный в hack/migrate-to-version-1.0.sh. С его помощью вы можете преобразовать ваши старые ConfigMaps в новый формат Package.

Основные возможности и улучшения

Оператор Cozystack

В этом релизе представлен cozystack-operator — специальный компонент, разработанный для обеспечения надёжного, декларативного управления пакетами для всей платформы. Чтобы заложить эту новую архитектуру, мы добавили CRD Package и PackageSource. Основная логика согласования (reconciliation) оператора и специализированные контроллеры были полностью реализованы для управления полным жизненным циклом этих ресурсов.

Мы также включили необходимые манифесты развёртывания Kubernetes для запуска cozystack-operator в кластере и интегрировали определения PackageSource. Дополняя эту серверную логику, мы также выпустили cozypkg — новую утилиту командной строки, специально разработанную для упрощения ручного управления ресурсами Package и PackageSource.

Система резервного копирования

Cozystack v1.0 представляет комплексную экосистему резервного копирования с нативной интеграцией Velero для надёжного управления данными приложений.

Основой этой системы является новый контроллер Plan, который управляет расписаниями и ротацией резервных копий. Для поддержки модульного подхода мы добавили отдельную API-группу стратегий резервного копирования, обеспечивающую подключаемую архитектуру для различных реализаций резервного копирования. Вдобавок мы оптимизировали управление ресурсами, добавив индексы к основным ресурсам резервного копирования, что значительно улучшило производительность запросов.

Был интегрирован контроллер стратегии Velero для обеспечения возможностей резервного копирования корпоративного уровня. Кроме того, была добавлена базовая реализация стратегии резервного копирования на основе Job.

Контроллер резервного копирования в настоящее время проходит промышленное тестирование, при этом в релиз включены полная инфраструктура развёртывания, сборки образов контейнеров и манифесты Kubernetes. Для удобства использования мы также представили пользовательский интерфейс панели управления для управления резервными копиями и Jobs резервного копирования, который обеспечивает полную видимость статусов резервных копий и истории заданий.

image03.png

AI/ML и сложные рабочие нагрузки

Мы добавили поддержку томов ReadWriteMany (RWX) в кластеры Kubernetes арендаторов. Это позволяет пользователям создавать общее хранилище со снимками (snapshot) и клонированием — именно то, что нужно для рабочих нагрузок AI/ML, где GPU и общие наборы данных являются стандартом. GPU passthrough также полностью поддерживается.

Поддержка нескольких дистрибутивов и гибкие варианты установки

Хотя Talos Linux остаётся нашим рекомендуемым дистрибутивом, Cozystack теперь официально поддерживает различные дистрибутивы Kubernetes, такие как K3s, Kubeadm и RKE. Мы также упростили настройку с помощью полного набора Ansible-плейбуков. Такие инструменты, как boot-to-talos, cozyhr и talm, получили крупные обновления. Boot-to-talos и talm теперь поддерживают bonding, VLAN, автообнаружение и настройку. Boot-to-talos без проблем работает с последними выпусками Ubuntu и обновлёнными ядрами и может автоматически преобразовать существующую систему с предварительно настроенной сетью в Talos.

Все наши инструменты — cozypkg, boot-to-talos, talm — можно установить одной командой из репозитория Brew.

Сеть

Режим BYOP теперь поддерживает Kilo: соедините ваши узлы K8s в защищённую WireGuard-сеть (mesh), даже если они разбросаны по разным регионам. Также был добавлен local-ccm — инструмент для назначения ExternalIP и управления жизненным циклом узлов без привязки к какому-либо конкретному облачному провайдеру. Вдобавок cluster-autoscaler теперь работает с Azure и Hetzner. В совокупности эти улучшения позволяют легко объединять узлы и кластеры из разных дата-центров в одну бесшовную сеть и динамически предоставлять новые узлы — идеально для гибридно-облачных конфигураций.

Виртуальные машины

Все виртуальные машины теперь доступны через headless-сервис. Это гарантирует, что каждой VM назначается постоянное внутрикластерное DNS-имя, позволяющее беспрепятственно обращаться к ним из других подов внутри кластера, даже если VM не назначен публичный IP-адрес.

Поддержка Windows и других ОС

Cozystack продолжает полностью поддерживать установку Windows и других операционных систем, в том числе через ISO-образы.

Интеграция с Harbor

Добавлен новый пакет для развёртывания реестра образов контейнеров Harbor.

OpenBAO — управляемое хранилище секретов

Теперь Cozystack включает OpenBAO — форк HashiCorp Vault с открытым исходным кодом для безопасного хранения секретов и управления ими. Доступны два режима — базовая конфигурация с одной репликой или высокодоступная на основе консенсуса Raft, при этом переключение выполняется автоматически в зависимости от поля replicas.

Каждый экземпляр OpenBAO поставляется с включённым TLS (используются самоподписанные сертификаты cert-manager), при этом все служебные эндпоинты и IP-адреса подов покрыты DNS SAN. Обратите внимание, что после установки предполагается, что вы вручную инициализируете и распечатаете (unseal) OpenBAO.

SeaweedFS: многоуровневые пулы хранилища

Операторы теперь могут настраивать пулы для конкретных типов дисков (SSD, HDD, NVMe) с помощью полей volume.pools или volume.zones[name].pools. Для каждого пула создаётся дополнительный набор серверов томов, а также соответствующие BucketClass и BucketAccessClass.

В конфигурациях MultiZone каждая комбинация «зона × пул» получает свой собственный набор серверов томов (например, us-east-ssd, us-west-hdd), а узлы сопоставляются по метке topology.kubernetes.io/zone. Существующие развёртывания без определённых пулов дают результат, идентичный предыдущим версиям — миграция не требуется.

Поддержка WORM

Драйверы SeaweedFS и COSI теперь позволяют создавать бакеты с включённым версионированием и поддержкой блокировки (lock).

Новая модель пользователей со входом через S3

Вместо единственного неявного ресурса BucketAccess операторы теперь определяют карту users. Для каждой записи создаётся отдельный BucketAccess со своим собственным секретом, содержащим учётные данные, и необязательным флагом readonly. Интерфейс S3 Manager был обновлён и теперь включает экран входа, позволяющий пользователям входить с помощью своих access_key и secret_key.

Доступны два новых параметра бакета:

  • locking — для BucketClass -lock (режим COMPLIANCE, срок хранения 365 дней), поддерживающий сценарии write-once-read-many;
  • storagePool — выбирает BucketClass, соответствующий конкретному пулу.

Драйвер COSI был обновлён до v0.3.0, добавив поддержку нового параметра diskType.

⚠️ Критическое изменение: неявный ресурс BucketAccess по умолчанию больше не создаётся. После обновления любые существующие бакеты, полагавшиеся на неявно автоматически создаваемый BucketAccess, должны явно определить пользователей в карте users.

Выбор версии RabbitMQ

Теперь вы можете указать, какую версию RabbitMQ запускать — v4.2 (по умолчанию), v4.1, v4.0 или v3.13. Helm-чарт автоматически выбирает правильный образ среды выполнения на основе этого параметра во время развёртывания. Таким образом, операторы могут управлять каналом релизов RabbitMQ, используемым каждым экземпляром. Автоматическая миграция заполняет поле version во всех существующих ресурсах RabbitMQ значением v4.2.

Документация

Документация на сайте была обновлена: теперь доступно подробное руководство по клонированию виртуальных машин и управлению ими, а настройку драйвера NFS мы сделали гораздо более понятной. Мы также отшлифовали руководства по установке Talos Linux для Hetzner и Servers.com, добавили раздел о настройке публичного IP для Hetzner RobotLB.

Помимо крупных архитектурных сдвигов, версии 1.0.0 и 1.1.0 приносят широкий спектр постепенных обновлений мониторинга, управления арендаторами и основных компонентов системы, а также оптимизированные процессы разработки и сборки и различные исправления стабильности.

Руководство по миграции

Доступно подробное руководство по миграции с v0.41 на v1.0. ⚠️ Обратите внимание на обязательные шаги.

Огромная благодарность всем, кто внёс вклад в конечный результат:

Присоединяйтесь к нашему сообществу