Релиз 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: nxs

serviceAccount:
  ro-secret:
    labels:
      component: nxs

nuc-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 в промышленных кейсах. Увидимся!