Релиз nxs-universal-chart 2.8.3 был более двух лет назад и за это время многое поменялось: Ingress Nginx ушел на покой, GitOps по факту стал стандартом управления инфраструктурой, а AI все сильнее входит в наши жизни. Все эти изменения не могли пройти мимо и заставили нас задуматься о том, как адаптировать наши подход и технологии DevOps к вызовам нового времени.
Результатом этих размышлений стал релиз новой версия nxs-universal-chart v3.x: из универсального набора встроенных шаблонов мы постарались превратить его в модульную платформу для поставки приложений в Kubernetes с упором на надежность и современные практики CI/CD процессов.
Всем привет, на связи Пётр, инженер компании Nixys и по совместительству maintainer проекта nxs-universal-chart. В этой статье я расскажу как мы переработали изначальную идею и какие нововведения в чарте это за собой повлекло.
В начале хотелось бы выразить благодарность всем пользователям nxs-universal-chart, которые продолжали пользоваться проектом даже в период большой паузы, в частности активным участникам, которые создают PR и issue на GitHub. А также отдельное огромное спасибо соавтору данного релиза, Вячеславу @Gekteer.
Новая идеология
Главная идея ветки 3.x — сделать chart не просто “универсальным шаблоном на все случаи”, а предсказуемым и масштабируемым инструментом для работы команд любого уровня.
Для этого в проекте были заложены несколько ключевых принципов.
-
Во-первых, конфигурация стала формальной: появился values.schema.json, который задаёт строгий контракт values и позволяет находить ошибки до деплоя.
-
Во-вторых, chart стал более удобным для GitOps-подхода: рендеринг сделан детерминированным, чтобы минимизировать шум в diff’ах и исключить случайные изменения в манифестах.
-
В-третьих, values модель была переработана в сторону resource-oriented структуры, где настройки группируются по семействам ресурсов, а не растут в виде разрозненного набора параметров.
Новая модель sub-charts
Одно из самых важных изменений — переход на dependency-модель nuc-* sub-charts. Раньше все интеграционные шаблоны находились внутри корневого chart, что значительно усложняло поддержку, тестирование и добавление нового функционала. Помимо этого, была еще одна концептуальная проблема.
Деплоя или удаляя приложение из кластера Kubernetes, мы не хотим производить операции отдельно с Ingress, Service или Deployment — мы хотим заделоить или удалить все части приложения, не забывая про вспомогательные элементы: секреты, Issuer для сертификатов, ServiceMonitor, автоскейлеры и тому подобные вещи. Однако, довольно часто описание этих элементов нужно нам отдельно от основного чарта.
Иными словами, мы хотим получить решение, которое одновременно позволяет и задеплоить всю абстракцию приложения, и задеплоить отдельные свои элементы без подтягивания лишних зависимостей.
В ветке 3.x эта логика была вынесена в отдельные OCI-hosted зависимости, которые представляют из себя самостоятельные Helm чарты NUC семейства. Это позволяет как подключать их к общему чарту, так и использовать их изолировано для развертывания конкретного ресурса.
Такой подход даёт сразу несколько преимуществ.
-
Базовый chart становится легче и чище, потому что отвечает прежде всего за базовые Kubernetes-ресурсы и общую логику рендеринга.
-
Специализированные интеграции при этом развиваются независимо и подключаются только при необходимости. Они покрываются индивидуальным набором тестов и придерживаются своей системы тегирования. Это снижает связность, упрощает сопровождение и делает экосистему более расширяемой, позволяя откатывать на предыдущие версии отдельные элементы.
-
При этом все sub-charts подчиняются общей логике основного чарта, что позволяет задавать глобальные значения для всех подключаемых модулей и совмещать их для построения полноценной инфраструктуры вокруг своего приложения.
На практике это означает, что nxs-universal-chart теперь выступает как единая точка входа в набор совместимых инфраструктурных модулей. Пользователь включает только те sub-charts, которые нужны конкретному окружению или платформе.
Выглядит это следующим образом: если нам необходимо задеплоить serviceAccount и секрет, который попадает в кластер Kubernetes через Vault Secret Operator, мы подключаем в корневом чарте nuc-vault-secret-operator и описываем ресурсы:
---nameOverride: nxsserviceAccount: ro-secret: labels: component: nxsnuc-vault-secret-operator: enabled: true vaultAuths: nxs-vault-auth: namespace: nxs labels: component: nxs method: kubernetes mount: kubernetes params: audience: nxs kubernetes: role: devops_service_nxs serviceAccount: nxs-ro-secret audiences: - nxs tokenExpirationSeconds: 900 vaultStaticSecrets: nxs-auth: namespace: nxs labels: app: nxs vaultAuthRef: nxs-vault-auth mount: nxs-kv path: apps/nxs-hub-auth refreshAfter: 10s destSec: nxs-hub-auth create: true destinationType: "kubernetes.io/dockerconfigjson" restartTargets: - kind: Deployment name: nxs-backend
NUC семейство sub-charts
В новой модели центральную роль играет nuc-common — библиотечный sub-chart с общими helper’ами, рендерингом pod/workload-частей, лейблов, шаблонных значений, configmaps, secrets, ingress и служебных механизмов совместимости.
Поверх него подключаются специализированные зависимости, разбитые на логические группы:
-
Traffic:
-
nuc-traefik — шаблоны для Traefik CRD, включая IngressRoute, Middleware, TLSOption, TLSStore, ServersTransport и TraefikService.
-
nuc-istio — шаблоны для Istio-ресурсов. В v3.0.7 этот модуль заметно расширен и теперь включает AuthorizationPolicy, EnvoyFilter, PeerAuthentication, RequestAuthentication, ServiceEntry, Sidecar, Telemetry, WasmPlugin, WorkloadEntry, WorkloadGroup и другие объекты Istio.
-
nuc-native-gateway — ресурсы для нативного Kubernetes Gateway API.
-
-
MLOps:
-
nuc-knative — ресурсы Knative Serving.
-
nuc-kserve — ресурсы KServe для inference и model serving сценариев.
-
-
Monitoring:
-
nuc-kube-prometheus-stack — CRD мониторинга из экосистемы Prometheus Operator.
-
nuc-victoria-metrics — шаблоны для VictoriaMetrics Operator.
-
-
Infrastructure:
-
nuc-vault-secret-operator — ресурсы Vault Secret Operator. В v3.0.7 в этот модуль добавлены HCPAuth, HCPVaultSecretsApp, SecretTransformation, VaultAuthGlobal, VaultConnection, VaultDynamicSecret и VaultPKISecret.
-
nuc-keda — ресурсы autoscaling из экосистемы KEDA.
-
nuc-certificates — ресурсы cert-manager, включая Certificate, Issuer, ClusterIssuer и связанные сущности.
-
-
GitOps:
-
nuc-argocd — основные ресурсы ArgoCD
-
nuc-fluxcd — основные ресурсы Flux2.
-
Такая структура позволяет собирать приложение и всю необходимую обвязку к нему в рамках одного Helm релиза, создавая контролируемую и воспроизводимую абстракцию.
Например, подключая чарты:
-
nuc-istio
-
nuc-kserve
-
nuc-knative
-
nuc-vault-secret-operator
-
nuc-kube-prometheus-stack
Мы получаем готовый Inference контур для развертывания AI моделей:
-
Gateway -> VirtualService -> AuthorizationPolicy -> DestinationRule в nuc-istio принимает и маршрутизирует трафик.
-
InferenceService из nuc-kserve ведёт запросы в inference-runtime, а nuc-knative Service раскладывается на Route, Configuration, Revision.
-
VaultConnection, VaultAuth, VaultStaticSecret из nuc-vault-secret-operator формируют Kubernetes Secret для workloads.
-
ServiceMonitor и PodMonitor из nuc-kube-prometheus-stack снимают метрики, а PrometheusRule задаёт правила алертов.
Таким образом, nxs-universal-chart перестал быть монолитным проектом и стал экосистемой взаимосвязанных модулей, которую можно адаптировать под конкретный стек.
Тестирование
Ветка 3.x сильно изменила и подход к качеству. Если раньше chart в основном развивался как набор шаблонов и документации, то теперь вокруг него выстроен полноценный тестовый контур.
-
В проекте появились unit-тесты на основе helm-unittest, которые покрывают ключевые шаблоны и контракты рендеринга.
-
Добавлены compatibility-проверки на прошлые стабильные теги, чтобы контролировать обратную совместимость.
-
Появились smoke-тесты, проверяющие схему values, контракты рендеринга, примерные конфигурации и kubeconform-валидацию манифестов.
-
Наконец, были добавлены e2e-тесты на основе kind, которые разворачивают chart в реальном Kubernetes API и проверяют основные ресурсы уже на уровне установки.
-
Все чарты автоматически проходят пайплайн проверки по всем вышеуказанным тестам при merge в релизные ветки.
-
Изменения в шаблонах, values-контрактах и зависимостях теперь проходят через несколько уровней автоматической проверки, а не только через локальный рендеринг.
Таким подходом мы хотели добиться того, чтобы nxs-universal-chart стал заметно надёжнее как проект. Вы можете самостоятельно ознакомиться с тестами, запустив их локально через Makefile, который есть в каждом репозитории. Также в директории docs вы найдете инструкции по запуску тестов и необходимые для них локальные зависимости.
Переход на OCI и публикация на ArtifactHub
Отдельным важным изменением в новой релизной модели стал переход на распространение chart и sub-charts через OCI-реестр. Если раньше Helm-артефакты чаще воспринимались как пакеты из классического chart repository, то теперь nxs-universal-chart и связанные nuc-* модули поставляются в OCI-формате. Это делает модель дистрибуции более современной, упрощает работу с зависимостями и лучше соответствует текущему направлению развития Helm-экосистемы.
Одновременно с этим основной чарт и все nuc-* модули были опубликованы на ArtifactHub. Мы хотели сделать этот релиз по всем современным стандартам, поэтому была внедрена криптографическая подпись публикуемых артефактов через cosign. В результате репозитории публикуются в Artifact Hub со статусом Signed, что подтверждает целостность и происхождение пакетов. Для пользователей это означает более прозрачную и доверенную цепочку поставки: chart не просто доступен для установки, но и сопровождается проверяемой подписью, которую можно использовать как часть практик supply chain security.
Это повышает прозрачность и доверие к релизам, а также делает распространение chart более удобным для пользователей, ориентирующихся на публичные каталоги и стандартизированные метаданные.
Итог
nxs-universal-chart v3.0 — это не просто очередной релиз с новыми шаблонами. Это закрепление новой архитектуры и видения проекта: с формальным values-контрактом, модульной dependency-моделью, расширяемой экосистемой sub-charts обновленными процессами тестирования и публикации.
Как и ранее, будем рады услышать ваши мысли и увидеть предложения по улучшению на GitHub, а также в нашем сообществе в Telegram. Также, если эта статья вызовет заинтересованность у читателей, мы напишем серию статей по использованию nxs-universal-chart в промышленных кейсах. Увидимся!
ссылка на оригинал статьи https://habr.com/ru/articles/1023822/