Cozystack 1.5: Gateway API, резервное копирование по умолчанию, шардирование Flux, TLS для управляемых сервисов и проброс GPU

Баннер релиза Cozystack v1.5.0 — Gateway API, резервное копирование по умолчанию, шардирование Flux, TLS и проброс GPU

Cozystack v1.5.0 теперь доступен. Релиз был опубликован 22 июня 2026 года и включает все исправления, выпущенные в линейке патчей с v1.4.1 по v1.4.4.

Этот релиз посвящён следующему уровню зрелости для продакшена. Он делает публикацию трафика более гибкой, резервное копирование — проще во внедрении, согласование состояния арендаторов — безопаснее, управляемые сервисы — более защищёнными по умолчанию, а работу с GPU-нагрузками — менее ручной.

Основные моменты

Поддержка Gateway API через Cilium

Cozystack 1.5 добавляет поддержку Gateway API на базе Cilium.

Это опциональный путь ingress, который может работать наряду с существующими контроллерами ingress-nginx на уровне арендатора. Существующие кластеры по умолчанию сохраняют текущее поведение. Возможность реализуется для каждого арендатора через новый CRD gateway.cozystack.io/v1alpha1 TenantGateway, согласуемый cozystack-controller.

Операторы могут включить новый путь на уровне платформы с помощью publishing.gateway.enabled=true. После этого арендатор может получить собственный Gateway, IP-адрес LoadBalancer и сертификат через tenant.spec.gateway=true. Если значение не задано, арендатор может унаследовать ближайший вышестоящий Gateway через ту же модель на основе меток, которая уже используется для наследования ingress.

Поддерживаются два режима выдачи сертификатов.

HTTP-01 — режим по умолчанию. Он даёт каждому приложению собственный сертификат без дополнительной настройки платформы для новых приложений.

DNS-01 включается опционально. Он использует один wildcard-сертификат для apex-домена и поддерживает провайдеров Cloudflare, Route 53, DigitalOcean и RFC 2136.

Есть две детали обновления, о которых нужно знать.

Cilium Envoy и поддержка Gateway API теперь всегда включены, что добавляет DaemonSet cilium-envoy (примерно 100 МБ RAM на узел в простое). Кроме того, cozystack-api теперь вызывает admission при операциях Create и Delete для apps.cozystack.io/*, поэтому пользовательские политики admission или вебхуки для этих типов теперь будут срабатывать на всех трёх глаголах.

TLS для управляемых баз данных и обмена сообщениями

Cozystack 1.5 добавляет поддержку TLS для внешних эндпоинтов Kafka, NATS, Qdrant и PostgreSQL.

Модель одинакова для всех этих сервисов. Каждый чарт получает значение tls.enabled с поведением из трёх состояний.

Когда значение не задано, оно наследуется от external. Это значит, что TLS включается автоматически, когда сервис публикуется вовне, и остаётся выключенным для развёртываний только для внутреннего использования. Явное значение true или false всегда имеет приоритет.

Корень доверия управляется чартом или оператором. Клиенты получают и закрепляют самоподписанный CA. Публичный CA не задействован.

Kafka теперь обслуживает TLS на своём внешнем слушателе LoadBalancer на порту 9094, а сертификатами управляет Strimzi.

NATS и Qdrant используют автономную цепочку cert-manager внутри пространства имён арендатора. NATS охватывает клиентские подключения и маршруты кластера. Qdrant охватывает REST и gRPC.

PostgreSQL уже обслуживает TLS через CloudNativePG. В 1.5 tls.enabled добавляет внешнее имя хоста в SAN серверного сертификата при external: true, поэтому sslmode=verify-full работает с внешним эндпоинтом.

Одно изменение требует планирования. Существующие экземпляры с external: true после обновления переключатся на включённый TLS. Внутренних экземпляров это не затрагивает.

Резервное копирование, работающее из коробки

Предыдущие релизы дали Cozystack механику резервного копирования. Версия 1.5 делает путь по умолчанию практичным.

Управляемый платформой BackupClass с именем cozy-default теперь поставляется по умолчанию. Он опирается на общий системный бакет с именем cozy-backups.

Приложения могут подключиться с помощью useSystemBucket. После этого Cozystack проецирует общие учётные данные резервного копирования в пространство имён арендатора с изоляцией RBAC и метриками проекции. Это устраняет необходимость настраивать учётные данные S3 для каждого приложения при обычном пути.

Стратегии по умолчанию теперь предоставляются для каждого приложения, поддерживающего резервное копирование: Velero для VMDisk и VMInstance, CNPG для PostgreSQL, Altinity для ClickHouse и отдельные стратегии для MariaDB, FoundationDB и etcd.

Velero теперь является системным пакетом по умолчанию. Это устраняет реальную проблему установки и обновления, когда контроллер стратегии резервного копирования по умолчанию зависел от Velero, тогда как сам Velero был опциональным. Существующие кластеры при обновлении получат Velero в пространстве имён cozy-velero. Операторы, которые не создают резервные копии ВМ, могут отказаться от него с помощью bundles.disabledPackages.

В этом релизе также появляются две новые стратегии резервного копирования.

Новая стратегия etcd действует на уровне кластера и работает только с S3. Она поддерживает BackupJob для создания снимков (snapshot) и деструктивные RestoreJob с восстановлением на месте.

Новая обобщённая стратегия Job даёт операторам не зависящий от приложения способ определить логику резервного копирования и восстановления. Оператор предоставляет шаблон Kubernetes Job. Cozystack рендерит его для резервного копирования и повторно рендерит в режиме восстановления для восстановления.

Flux v2.8 с более строгим согласованием состояния

Cozystack 1.5 обновляет Flux с v2.7.3 до v2.8.0.

Это затрагивает как встроенный Flux в управляющем кластере, так и опциональное дополнение Flux для арендатора. Чарты flux-operator и flux-instance переходят с v0.33.0 на v0.50.0.

Flux v2.8 приносит helm-controller v1.5 с Server-Side Apply, --force-conflicts и проверкой работоспособности на основе kstatus по умолчанию.

Это более строгая модель. Неправильно размещённые поля чартов, которые Flux v2.7 молча игнорировал, теперь становятся жёсткими ошибками. Родительские HelmRelease теперь ждут, пока каждый дочерний ресурс не станет Ready, прежде чем сами сообщат о статусе Ready.

Это лучше с точки зрения корректности, но также меняет поведение при обновлении.

Для управляющего кластера теперь требуется Kubernetes 1.33 или новее. То же требование распространяется на кластеры арендаторов, которые включают дополнение Flux.

Старый переключатель upgrade.force: true удалён. Изменения неизменяемых полей больше не самовосстанавливаются через принудительную замену. Если обновление меняет неизменяемое поле, такое как volumeClaimTemplates или serviceName у StatefulSet, объект необходимо пересоздать вручную (например, kubectl delete sts <name> --cascade=orphan) и заново согласовать через Flux.

flux-shard-operator для шардирования HelmRelease арендаторов

Cozystack теперь включает flux-shard-operator.

Этот оператор распределяет HelmRelease арендаторов по нескольким шардам helm-controller. Цель проста: один шумный арендатор не должен замедлять согласование состояния для всех остальных.

Типичный плохой случай — HelmRelease, застрявший в бесконечной ремедиации. До шардирования это могло ухудшить согласование состояния на всём пути контроллера арендаторов. В 1.5 размещение назначается для каждого арендатора. Все HelmRelease одного арендатора используют один и тот же шард.

Настройка по умолчанию — shardCount: auto. Небольшие кластеры сохраняют текущее поведение с одним шардом. Более крупные парки автоматически распределяются по шардам на основе количества HelmRelease арендаторов. Операторы также могут явно зафиксировать количество шардов.

Старое самодельное развёртывание flux-tenants автоматически опустошается и выводится из эксплуатации миграцией 44.

Wildcard-сертификаты, предоставляемые оператором

Операторы теперь могут обслуживать сервисы платформы и ingress корневого арендатора через уже существующий wildcard-сертификат TLS.

Задайте в publishing.certificates.wildcardSecretName имя TLS Secret в пространстве имён публикации. По умолчанию это пространство имён tenant-root.

По каналу значений Cozystack передаётся только имя Secret. Ключевой материал не передаётся.

Это работает для обоих путей ingress.

С ingress-nginx контроллер обслуживает Secret как SSL-сертификат по умолчанию, а Ingress платформы отбрасывают свои аннотации cert-manager.

С Gateway API новый режим сертификата TenantGateway existingSecret ссылается на Secret напрямую и не создаёт Issuer или Certificate.

Текущая область действия — корневой арендатор. Расширение режима wildcard на дочерних арендаторов запланировано на будущее.

Проброс GPU без ручного патчинга KubeVirt

Поддержка GPU получает крупную операционную доработку в 1.5.

Для Kubernetes арендатора группы узлов, которые объявляют gpus, теперь автоматически получают метку kubelet gpu=on. Это позволяет плагину устройств HAMi планировать и анонсировать nvidia.com/gpu.

Оператор GPU арендатора также загружает драйвер NVIDIA с NVreg_NvLinkDisable=1, что устраняет случай проброса одиночного SXM-GPU, который ранее мог зависать во время инициализации.

Для ВМ KubeVirt включение cozystack.gpu-operator теперь автоматически заполняет CR KubeVirt. Оно добавляет feature gate HostDevices и заполняет permittedHostDevices из поставляемых таблиц значений NVIDIA по умолчанию. Конфигурация vGPU также покрывается через mediatedDevicesConfiguration.

На практике ВМ с GPU теперь могут планироваться без ручного kubectl patch.

Есть одно важное замечание по обновлению. Теперь бандл владеет spec.configuration.permittedHostDevices. Если у вас есть пользовательские, отредактированные вручную записи устройств, перенесите их в .gpu.permittedHostDevices перед обновлением и убедитесь, что каждый resourceName соответствует тому, что анонсируют ваши узлы.

Также добавлен третий вариант оператора GPU. Новый вариант container предназначен для хостов, где драйвер NVIDIA и container toolkit уже установлены операционной системой. Он предоставляет GPU обычным контейнеризованным подам только через плагин устройств.

Защита от удаления для критически важных объектов платформы

Cozystack 1.5 добавляет защитный барьер от удаления для критически важных объектов платформы.

Объекты с меткой platform.cozystack.io/no-delete=true нельзя удалить напрямую. Проверка выполняется внутри процесса через Kubernetes ValidatingAdmissionPolicy. Нет ни вебхука, ни DaemonSet, ни настройки TLS, ни дополнительного образа.

К защищённым объектам относятся пространства имён cozy-system и tenant-root, HelmRelease корневого арендатора, ConfigMap cozystack-version, источник пакетов cozystack-packages, ClusterIssuers cert-manager, LinstorCluster и CRD пакетов.

Если оператору действительно нужно удалить защищённый объект, он может сначала снять метку.

Эта возможность требует Kubernetes 1.30 или новее.

Выпадающие списки панели управления, заполняемые во время выполнения

Панель управления получает более аккуратный способ показывать актуальные варианты в формах создания и редактирования.

Новый ресурс Option только для чтения обеспечивает работу выпадающих списков, зависящих от состояния кластера. Это охватывает устройства GPU, instancetypes и preferences KubeVirt, сети Multus, образы ВМ, пулы хранилищ, классы хранилища, классы резервного копирования и планы резервного копирования.

Чарты приложений объявляют источники вариантов через новое ключевое слово схемы x-cozystack-options. Арендаторы получают доступ только для чтения к вариантам в собственном пространстве имён.

Результат простой, но важный. Формам больше не нужно полагаться на свободный ввод или устаревшие статические перечисления, когда правильное значение уже существует в кластере.

Также в v1.5.0

Cozystack 1.5 также включает широкий набор улучшений и исправлений платформы.

Пользователи-арендаторы теперь могут запускать, останавливать и перезапускать свои ВМ из панели управления. Отсутствовавший RBAC для субресурсов KubeVirt добавлен на уровне базового использования арендатора.

Администраторы платформы получают новую панель управления Grafana Tenant Overview. Она показывает сводку по парку в разрезе арендаторов, топ потребителей, тенденции использования и сигналы работоспособности. Она разворачивается только в корневом стеке мониторинга, а не в Grafana отдельных арендаторов.

Новая страница Cluster Usage в панели управления опирается на выделенный RBAC. Она показывает утилизацию в масштабе всего кластера и по каждому узлу, включая GPU.

Поля storageClass у stateful-приложений теперь помечены как неизменяемые в схеме чарта и отображаются только для чтения в формах редактирования панели управления. Это охватывает 16 stateful-приложений, включая PostgreSQL, Kafka, Redis, OpenSearch, ClickHouse, MongoDB, NATS, Qdrant, RabbitMQ, Harbor, FoundationDB, MariaDB, VMDisk и другие. Причина практическая: изменение storageClass не переносит существующие данные.

В этом релизе ограничение действует только на уровне UI. Прямой kubectl patch по-прежнему принимается, пока не появится принудительное применение на уровне API через CEL.

Релиз также исправляет длинный список проблем установки, обновления и выполнения. Среди основного: более безопасная публикация схемы OpenAPI в cozystack-api, полные CRD prometheus-operator из upstream, исправленные URL издателя OIDC в kubeconfig арендаторов, поддержка конфигурации реестра containerd 2.x, исправления отсоединения hotplug в KubeVirt CSI, startup-пробы для медленных контроллеров, доступность OpenSearch в бандле PaaS и несколько исправлений SeaweedFS после перехода на 4.31.

Компоненты платформы

В этом релизе обновлено несколько основных компонентов.

Flux переходит с v2.7.3 на v2.8.0.

MetalLB переходит с v0.15.2 на v0.16.1. FRR-K8s теперь является BGP-бэкендом по умолчанию. Эндпоинты метрик доступны только по HTTPS.

SeaweedFS переходит с 4.05 на 4.31. Это устраняет опасность upstream 4.23 с erasure-coding и несколькими дисками и приносит множество исправлений корректности S3 API.

etcd-operator переходит с v0.4.3 на v0.4.5. Обновление включает исправления пути восстановления и улучшения статуса резервного копирования.

ouroboros переходит с v0.7.2 на v0.8.0. Теперь он логирует более понятные причины сбоя проверок готовности TCP-бэкенда.

seaweedfs-cosi-driver переходит на v0.3.1 и может восстанавливаться после устаревших UNIX-сокетов при некорректном завершении.

Cozystack также добавляет kuberture в качестве нового опционального системного пакета. Он отслеживает EndpointSlice API-сервера Kubernetes и создаёт headless-сервисы для external-dns, что помогает публиковать эндпоинты Kubernetes API в DNS.

Замечания по обновлению

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

Во-первых, для управляющего кластера требуется Kubernetes 1.33 или новее. Он также требуется для кластеров арендаторов, которые включают дополнение Flux.

Во-вторых, upgrade.force исчез. Изменения неизменяемых полей больше не самовосстанавливаются через принудительную замену. Операторам может потребоваться пересоздать затронутые объекты вручную (например, kubectl delete sts <name> --cascade=orphan) и позволить Flux заново согласовать их.

В-третьих, операторы ВМ с GPU должны перенести пользовательские записи устройств хоста перед обновлением. Cozystack теперь владеет KubeVirt.spec.configuration.permittedHostDevices, когда включён cozystack.gpu-operator.

В-четвёртых, MetalLB теперь по умолчанию использует BGP-бэкенд FRR-K8s. Метрики доступны только по HTTPS, поэтому конфигурации сбора, использующие старые HTTP-эндпоинты, необходимо обновить.

В-пятых, базы данных и сервисы обмена сообщениями, опубликованные вовне, автоматически получают TLS. Клиенты должны получить и закрепить самоподписанный CA. Внутренних сервисов это не затрагивает.

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

Этот релиз поставляется с новой и обновлённой документацией для нескольких продакшен-сценариев.

Спасибо всем участникам

Cozystack v1.5.0 стал возможен благодаря @androndo, @Arsolitt, @elaugaste, @IvanHunters, @kvaps, @kvapsova, @lexfrei, @lllamnyp, @myasnikovdaniil, @sunib и @tym83.

Особо приветствуем @elaugaste, нашего впервые присоединившегося участника в этом релизе. Спасибо всем.

Ссылки на релиз

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