Предыдущим релизом платформы был 0.41. И тут неожиданно будущий релиз 0.42 стал ответом на главный вопрос жизни, вселенной и всего такого: слишком много серьезных изменений накопилось в платформе. Так что 0.42 пришлось переименовать в 1.0.
С выходом версии 1.0 платформа Cozystack перешла на новую архитектурную модель. Мы создали систему пакетов на основе FluxCD и артефактов OCI, похожую на apt в Debian/Ubuntu, но для Kubernetes (см. раздел «Развертывание на основе пакетов» ниже). Это позволило нам реализовать новый подход — Build Your Own Platform (BYOP).
Мы наконец-то избавились от bash-скриптов, который раньше управлял логикой платформы и заменили его на полноценный оператор, который обслуживает установку всех системных компонентов платформы.
Что такое Cozystack
Cozystack — это Open Source-платформа, которая позволяет строить облако на bare metal для быстрого развертывания managed Kubernetes, database as a service, applications as a service и виртуальных машин на базе KubeVirt. В рамках платформы можно по клику разворачивать Kafka, FerretDB, PostgreSQL, Cilium, Grafana, Victoria Metrics и другие сервисы. Кроме того, платформа поддерживает работу с GPU в виртуальных машинах и K8s-кластерах. Cozystack — проект CNCF Sandbox, существует под лицензией Apache 2.0.
По сути вся логика платформы теперь крутится вокруг двух сущностей: Package и PackageSource:
PackageSource определяет исходники пакета ссылаясь напрямую на Git- или OCI-репозиторий.
Package отражает намерение пользователя установить тот или иной пакет.
Обе сущности кластерные (т. е. не привязаны к конкретному неймспейсу) и могут управляться как пользователем напрямую через cozypkg и kubectl или платформенным чартом.
Новый подход предоставляет более надёжный путь к установке компонентов, кастомизации и расширению платформы, не переусложняя логику.
Теперь можно использовать Cozystack в двух сценариях:
Как готовую платформу со всеми предустановленными приложениями (как и раньше). В этом случае платформенный чарт самостоятельно установит все необходимые Packages.
Собрать свой собственный Cozystack. В этом случае платформенный чарт завезёт только PackageSources для текущих версий компонентов. Приглашая пользователя использовать cozypkg для самостоятельной установки желаемых Packages.
В любом случае установка начинается с cozystack-operator и после установки оператора, пользователю предлагается установить основной пакет cozystack-platform. Дальше на ваш выбор предлагается несколько вариантов для «платформы»:
Варианты isp-full, isp-full-generic, isp-hosted предлагают вариант установки Cozystack со всеми необходимыми пакетами под конкретный кейс использования. В default-варианте устанавливаются только PackageSources, но не сами Packages — в дальнейшем пользователь может использовать утилиту cozypkg, посмотреть список доступных пакетов выбрать и установить желаемые, с автоматическим разрешением зависимостей. Система пакетов Cozystack немного отличается от Debian/Ubuntu тем, что у каждого пакета есть доступные варианты. Например, в случае с пакетом cozystack.networking, который является зависимостью почти для всех остальных пакетов мы предоставляем варианты: kubeovn-cilium, или просто cilium, cilium-kilo и noop. Noop по факту ничего не устанавливает, но используется для удовлетворения зависимостей. Это может быть полезно, например, при установке в уже существующий managed Kubernetes-кластер.
Система выстроена таким образом что теперь вы можете создать свой собственный репозиторий, подключить его в Cozystack и устанавливать из него пакеты.
Под капотом новой системы пакетов используется Flux с новым механизмом Source Watcher. По сути Cozystack стал одним из самых первых адоптеров нового API FluxCD благодаря чему мы предоставили возможность без необходимости сборки своих чартов определять и создавать свои собственные репозитории, а так же полностью избавиться от проблемы курицы и яйца (напомним: Cozystack устанавливает через Flux всё, включая сетевой стек: CNI, kube-proxy — но при этом сам Flux нуждается в работающей сети, чтобы скачивать чарты), теперь мы полностью перешли на source-watcher в составе самодостаточного flux-aio, который самостоятельно скачивает исходники чартов из Git- или OCI-репозитория, собирает их в готовые к установке артефакты и затем устанавливает.
В итоге мы на шаг ближе стали к воплощению самой парадигмы Cozystack (Cozy Technology Stack) — «уютного/удобного стека технологий», который вы формируете под свои нужды. Подробная информация об установке есть в документации.
Помимо архитектурных изменений, в этой версии появилась развитая система бэкапов включая максимально расширяемое API и реализация бэкапа для виртуальных машин на основе Velero, и добавлен шардинг Flux для оптимизации распределения ресурсов между тенантами. Также расширены возможности мониторинга, улучшена работа с виртуальными машинами, тенантами и процессами сборки. Кроме того, теперь прямо «из коробки» доступны базы данных MongoDB с поддержкой автоскейлинга и отказоустойчивости.
Изменения, нарушающие обратную совместимость
Прекращена поддержка FerretDB
Этот компонент был полностью удален из платформы; автоматическая миграция не предусмотрена.
Внимание: если у вас имеются работающие инстансы FerretDB, перед апгрейдом необходимо сделать полный бэкап данных.
MySQL переименован в MariaDB
Пакет, ранее называвшийся MySQL, был переименован в MariaDB, чтобы корректно отражать используемую СУБД (мы всегда использовали mariadb-operator).
Удален ресурс VirtualMachine (simple)
Вместо него предлагается использовать две раздельные сущности — VMDisk и VMInstance — для более гранулярного и Kubernetes-native управления виртуальными машинами.
Новое именование в API: CozystackResourceDefinition теперь называется ApplicationDefinition
Для большего удобства и единообразия платформы CRD CozystackResourceDefinition был переименован в ApplicationDefinition.
Чтобы упростить процесс обновления для пользователей, мы предусмотрели скрипты автоматической миграции. Которые переведут существующие ресурсы на новый формат.
Развертывание на основе пакетов
Релиз 1.0 меняет логику управления приложениями. Мы переходим от использования бандлов HelmRelease к ресурсам Package, которыми управляет cozystack-operator.
Что изменилось:
Структура values.yaml была полностью пересмотрена. Добавлены разделы для настройки сети, публикации, аутентификации, планирования ресурсов и брендинга.
Появились файлы values-isp-full.yaml и values-isp-hosted.yaml с настройками для разных вариантов использования.
Ресурсы типа Package пришли на смену шаблонам HelmRelease.
Вся настройка Cozystack-как-платформы теперь производится не через ConfigMap а через параметры ресурса Package для cozystack-platform
Для обновления воспользуйтесь скриптом hack/migrate-to-version-1.0.sh — он сконвертирует старые ConfigMap в формат Package.
Ключевые изменения
Cozystack-operator
Ключевым нововведением релиза стал cozystack-operator — компонент для декларативного управления пакетами платформы. Новая архитектура опирается на CRD Package и PackageSource. В платформе была реализована полноценная логика реконсиляции и контроллеров оператора, что позволяет автоматически управлять всем жизненным циклом этих ресурсов.
Релиз включает готовые манифесты для развертывания оператора в кластер и настроенные PackageSource. Кроме того, с помощью новой CLI-утилиты cozypkg стало гораздо проще вручную управлять пакетами и их источниками.
Система резервного копирования
В v1.0.0 появилась развитая экосистема бэкапов на базе Velero для надежного управления данными. Основой системы стал контроллер Plan, отвечающий за расписание бэкапов и ротацию копий. Новая архитектура на основе плагинов позволяет гибко выбирать способы создания бэкапов. Также мы поработали над скоростью: добавление индексов в основные ресурсы существенно ускорило запросы.
В систему интегрирован контроллер стратегий Velero для задач энтерпрайз-уровня, а также добавлена базовая заготовка для бэкапов на основе Job.
Контроллер бэкапов проходит испытания в продакшене: в релиз включено все, что нужно для развертывания, образы и манифесты Kubernetes. Для управления бэкапами был добавлен наглядный дашборд, в котором можно отслеживать статусы и историю всех задач (job) по резервному копированию.
Поддержка AI/ML и комплексных рабочих нагрузок
Добавили поддержку ReadWriteMany (RWX) томов для тенантных Kubernetes-кластеров. Теперь пользователи могут создавать полноценные хранилища с общим доступом, снапшотами и клонированием, что крайне востребовано в AI/ML сценариях, где графические ускорители (GPU) и общие датасеты являются стандартом. Кроме того, Cozystack поддерживает проброс GPU, о чем мы писали ранее.
Мульти-дистрибутивность и гибкая установка
Хотя Talos Linux остается нашим рекомендуемым дистрибутивом, Cozystack теперь официально поддерживает и другие дистрибутивы Kubernetes: K3s, Kubeadm, RKE. Для упрощения установки мы подготовили набор Ansible-плейбуков. Значительно улучшены side-утилиты, такие как boot-to-talos, сozyhr и talm. boot-to-talos и talm теперь поддерживают бондинг, VLAN, автоматическое обнаружение и настройку. boot-to-talos работает с новыми версиями Ubuntu и с новыми ядрами, без проблем переключает существующую систему с уже готовыми настройками сети в Talos.
Все эти утилиты (cozypkg, boot-to-talos, talm) легко можно установить одной командой из нашего Brew-репозитория.
Сеть
В режиме BYOP появилась поддержка Kilo: теперь узлы Kubernetes можно объединить в защищенную WireGuard-сеть независимо от их географического расположения. Добавлен local-ccm — решение для проставления ExternalIP и управления жизненным циклом нод без привязки к облачным вендорам. Так же добавлен cluster-autoscaler для Azure и Hetzner. Всё вместе это позволяет легко объединять ноды и целые кластеры, расположенные в разных дата-центрах, в единую, бесшовную сеть, и заказывать ноды динамически что идеально подходит для сценариев гибридного облака.
Виртуальные машины
Теперь для всех виртуальных машин создается headless-сервис. Это обеспечивает каждой ВМ фиксированное DNS-имя внутри кластера. В результате к виртуальным машинам можно обращаться из любых подов в кластере напрямую, даже если у ВМ нет публичного IP-адреса.
Запуск Windows и кастомных ОС
Cozystack, как и прежде, полностью поддерживает установку Windows и других ОС, в том числе из ISO-образов.
Добавлена поддержка Harbor
В состав платформы включен пакет для развертывания реестра образов Harbor.
OpenBAO — managed-сервис по управлению секретами
Cozystack теперь включает OpenBAO — open-source форк популярного инструмента HashiCorp Vault для безопасного хранения секретов и управления ими. Поддерживается два режима — автономный (одна реплика с файловым хранилищем) и высокодоступный (несколько реплик с интегрированным консенсусом Raft), режимы переключаются автоматически в зависимости от значения поля replicas.
В каждом инстансе OpenBAO по умолчанию включен TLS на самоподписанных сертификатах cert-manager’а, при этом DNS SAN покрывают все эндпоинты сервисов и адреса подов. После установки OpenBAO ожидает ручной инициализации и распечатывания (unsealing) от пользователя.
Многоуровневые пулы хранения в SeaweedFS
Операторы теперь могут определять отдельные пулы для разных типов дисков (SSD, HDD, NVMe) в поле volume.pools (для простой топологии) или volume.zones[name].pools (для MultiZone-топологии). Для каждого пула создается дополнительный набор volume-серверов и создаются соответствующие BucketClass и BucketAccessClass.
В MultiZone-топологии пулы определяются для каждой зоны, и для каждой комбинации «зона × пул» создается свой выделенный набор volume-серверов (например, us-east-ssd, us-west-hdd), узлы выбираются с помощью меток topology.kubernetes.io/zone. Существующие развертывания без пулов будут работать так же, как и в предыдущих версиях — миграция не требуется.
Добавлена поддержка WORM
В seaweedfs и COSI-драйвер добавлена возможность заказывать бакеты с включенным режимом версионирования и поддержкой блокировок.
Новая пользовательская модель с S3-аутентификацией для бакетов
Вместо единого имплицитного ресурса BucketAccess операторы теперь определяют список (map) users. Для каждой записи из нее создается выделенный BucketAccess с собственным секретом, содержащим учетные данные, и опциональным флагом readonly. Пользовательский интерфейс S3 Manager был обновлен и теперь включает экран входа, который позволяет пользователям заходить со своими access_key и secret_key.
Доступны два новых параметра для бакетов: locking для бакетов типа -lock BucketClass (режим COMPLIANCE, блокировка на 365 дней) для сценариев с однократной записью и многократным чтением (write-once-read-many), а storagePool выбирает BucketClass для конкретного пула. Драйвер COSI был обновлен до версии v0.3.0 и теперь поддерживает новый параметр diskType.
Внимание: Имплицитный BucketAccess больше не создается по умолчанию. После обновления существующим бакетам, которые полагались на BucketAccess, необходимо явно задать пользователей в списке users.
Выбор версии RabbitMQ
Инстансы RabbitMQ теперь поддерживают селектор версии (поле version со значениями: v4.2, v4.1, v4.0, v3.13; по умолчанию v4.2). Helm-чарт проверяет его во время развертывания и использует для привязки рантайм-образа. Автоматическая миграция заполняет поле version значением v4.2 для всех существующих ресурсов RabbitMQ.
Документация
Обновили документацию на сайте: теперь доступно полное руководство по клонированию виртуальных машин и управлению ими, а инструкции по настройке NFS-драйвера стали проще и понятнее. Также мы актуализировали документацию по установке Talos Linux для инфраструктур Hetzner и Servers.com, добавили описание настройки публичных IP через Hetzner RobotLB.
Помимо глобальной смены архитектуры, релизы 1.0.0 и 1.1.0 содержат множество улучшений в мониторинге, управлении тенантами и базовых компонентах системы. Оптимизированы процессы сборки и устранены различные ошибки.
Руководство по миграции
Подготовили подробное руководство по миграции с v0.41 на v1.0. Особое внимание обратите на обязательные шаги.
Спасибо всем, кто поучаствовал в подготовке релиза:
Присоединяйтесь к нашему комьюнити
