kubepkg 1.3: apt-подобный пакетный менеджер для Kubernetes

Разбор новинки простыми словами: что это, кому нужно и брать ли.

Для команд, собирающих платформы на K8s, появляется готовый слой зависимостей и CRD-контроля поверх Helm — меньше самописных прослоек при сборке дистрибутива.

Связанные услуги: каталог, AI Boost Team, стать клиентом.

У Linux есть apt, dnf и pacman. У Kubernetes за десять лет ничего похожего так и не появилось. Helm аккуратно ставит один чарт, Argo CD и Flux синхронизируют кластер с Git, а слоя, который знает, что cert-manager нужен половине остальных компонентов, что CRD переживают поставивший их релиз и что удаление CRD сносит все объекты этого типа, нет ни у кого. Каждая команда, собирающая платформу, пишет эту прослойку сама. И каждый раз заново.

kubepkg 1.3 — очередная попытка закрыть дыру. Отличие от предыдущих в одном решении: никого не просят переупаковывать софт.

Что внутри: пакет, индекс, четыре ресурса

Проект живёт в GitHub-организации kuberoot-dev рядом со сборщиком дистрибутивов kuberoot и вырос из компонента cozypkg платформы Cozystack. Автор — TimurTukaev, это личный проект, старт — начало октября, текущая версия 1.3 уже со стабильным API.

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

Пакет это неизменённый Helm-чарт, а всё, чего Helm не знает, лежит рядом с ним в отдельном описании.

В описании — зависимости и владение CRD. Зависимости двух видов: пакет с ограничением версии (для cert-manager, например, не ниже 1.20) и «возможность» — скажем, API monitoring.coreos.com/v1, которую может закрыть уже стоящий в кластере оператор. Второй случай Helm не умеет вообще: он не видит, что Prometheus Operator уже кем-то поставлен, и впихивает второй.

Состояние хранится в четырёх типах ресурсов кластера: Repository, Package, PackageSource, PackageRevision. Читается как история установки, а не как «что сейчас в Git».

Если апстрим чарт не публикует — KubeVirt, например, — рецепт собирает его из релизных манифестов. На выходе всё равно обычный чарт.

Собранный пакет лежит в OCI-реестре и ставится без kubepkg, хоть самим Helm, хоть через Flux или Argo CD.

Вот это и есть главный аргумент. Нет vendor lock на инструмент: надоело — забираете пакеты из реестра и катите их привычным способом.

Почему предыдущие попытки умерли

История тут длинная и поучительная. Helm появился в 2015-м с подзаголовком «пакетный менеджер для Kubernetes» и формально им стал: пакеты, репозитории, версии. Не хватило знания о том, как пакеты живут вместе.

Дальше по списку: KPM от CoreOS в 2016-м, из которого выросли App Registry и раздел Applications в Quay — его убрали в 2022-м после покупки Red Hat. CNAB, предложенный в 2018-м Microsoft, Docker и компанией, — эталонная реализация Duffle в архиве. KUDO от D2iQ — последний релиз весной 2021-го. Glasskube в 2024-м собрал несколько тысяч звёзд на GitHub и был закрыт, команда ушла в другой продукт. Kubeapps, который вообще не придумывал своего формата, ушёл в архив в августе 2025-го, поддерживает его форк SAP.

Выжили только те, у кого за спиной большая платформа: OLM внутри OpenShift и kapp-controller внутри Tanzu. За пределами своих экосистем ими почти не пользуются.

Причина одна и она не техническая. Новый формат пакета требует, чтобы кто-то упаковал в него софт. Авторы cert-manager, Cilium или KubeVirt не станут вести ещё один формат ради инструмента без пользователей. Пользователи не придут в инструмент без пакетов. Проект живёт ровно столько, сколько его команда успевает переупаковывать чужие релизы.

Отсюда решение kubepkg: взять де-факто стандарт поставки — Helm-чарт, которых на Artifact Hub тысячи, — и не трогать его.

Кому это нужно на практике

• Тем, кто собирает дистрибутив Kubernetes или внутреннюю платформу и уже держит самописный оркестратор «сначала cert-manager, потом всё остальное».
• Тем, кто ловит инциденты из-за CRD, снесённых вместе с релизом.
• Тем, кому нужно объяснить аудитору, какая версия чего стоит и почему.

Если у вас три-пять чартов и один кластер, слой не нужен. Argo CD справится, а лишняя сущность в кластере только запутает.

Где подвох

Проект личный, один автор. Инженеры Ænix к коду отношения не имеют — об этом сказано прямо. И это ровно та причина, по которой умерли KUDO и Glasskube: команда устала или переключилась на другое. Стабильный API в 1.3 не отменяет вопроса, кто будет вести рецепты, когда автор занят.

Часть знаний зашита в рецепты, а не в код. KubeVirt после обновления не откатить на прошлую версию — kubepkg про такие вещи знает, но только если это кто-то описал. Наполнение репозитория само не масштабируется.

Брать или подождать

Брать, если строите дистрибутив или платформу и уже написали свою прослойку поверх Helm. Версия 1.3 со стабильным API — рабочая точка входа, а переносимые OCI-пакеты дают путь отхода.

Подождать, если у вас ванильный набор чартов и Flux закрывает задачи. Вы получите ещё один слой состояния без выгоды.

Проверить до старта: кто внутри отвечает за рецепты и что будет с ними, если апстрим сменит формат релиза.

Вердикт

kubepkg 1.3 решает реальную боль платформенных команд и делает это единственным способом, который не противоречит рынку: не заставляет никого переупаковывать чарты. Риск здесь не технический, а организационный — тот же, что сгубил пять предшественников. Инструмент стоит того, чтобы прогнать его на тестовом кластере, но ставить его фундаментом платформы без своего человека на рецептах рано.

FAQ

Заменяет ли kubepkg Helm?

Нет. Работает поверх: Helm, Argo CD и Flux остаются на месте, kubepkg добавляет слой зависимостей и владения CRD.

Нужен ли свой формат пакета?

Нет. Пакет — обычный Helm-чарт в OCI-реестре плюс отдельное описание рядом.

Можно ли обойтись без kubepkg после сборки?

Да. Пакеты из реестра ставятся обычным Helm, через Flux или Argo CD.

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