Рецепт 22. Новый supply chain и image catalogs CloudNativePG

Оригинал: CNPG Recipe 22 — Leveraging the New Supply Chain and Image Catalogs — 6 октября 2025.

CloudNativePG ушёл от использования официального Docker Hub postgres и полностью построил свой supply chain с нуля на docker bake. В рецепте — что это даёт и как пользоваться новой фичей Image Catalogs для декларативного управления PostgreSQL-образами без жёстко прибитых тегов в манифестах кластеров.

Что нового в supply chain

CloudNativePG больше не зависит от Docker Hub. Теперь весь pipeline сборки операнд-образов управляется самим проектом:

• Сканирование уязвимостей через Snyk — непрерывное обнаружение CVE.
• Подпись образов через sigstore/cosign — проверка целостности и происхождения.
• SBOM (Software Bill of Materials) — полная прозрачность по компонентам.
• Оптимизированные multi-arch builds — поддержка amd64 и arm64.

Это ровно то, что хотят слышать enterprise-команды и compliance-аудиторы.

Image Catalogs

Главная фича рецепта. Image Catalog — это ресурс, который отвязывает конфигурацию кластера от конкретного образа/тега. Вместо того чтобы каждый раз править imageName в Cluster, вы держите централизованный каталог образов и ссылаетесь на него по major-версии.

Развернуть официальный каталог одной командой:

kubectl apply -k \
  https://github.com/cloudnative-pg/artifacts/image-catalogs?ref=main

После этого в кластере появятся ClusterImageCatalog-ресурсы с актуальными PostgreSQL-образами по major-версиям.

Использование в Cluster

Декларативная ссылка на каталог:

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: angus
spec:
  instances: 3
  imageCatalogRef:
    apiGroup: postgresql.cnpg.io
    kind: ClusterImageCatalog
    name: postgresql-minimal-trixie
    major: 18
  storage:
    size: 1Gi

Никаких жёстко зашитых ghcr.io/cloudnative-pg/postgresql:18.0-minimal-trixie. Major-версия объявлена явно, конкретный образ управляется каталогом. Обновляешь каталог — обновляются все кластеры, ссылающиеся на этот major.

Spread upgrades для парка БД

В крупных инсталляциях с десятками-сотнями PostgreSQL-кластеров одновременный rollout новой версии — это удар по нагрузке кластера Kubernetes и storage. Новая фича spread upgrades управляет шагом раскатки.

Поведение настраивается переменной окружения CLUSTERS_ROLLOUT_DELAY в ConfigMap’е оператора. Раскатка идёт с задержкой между кластерами, не позволяя системе захлебнуться.

Куда движется проект

Бартолини снова возвращается к идее минимальных PostgreSQL-образов с расширениями отдельными OCI-образами, монтируемыми через Kubernetes ImageVolume («Иммутабельное будущее расширений»). Это модульная архитектура, в которой extension’ы существуют независимо от core-образа PostgreSQL.

Уже сегодня: PostgreSQL 18 minimal-образ — ~230 МБ, на 45% меньше, чем для PostgreSQL 17.

Итог

• Собственный supply chain CloudNativePG — больше нет зависимости от Docker Hub postgres.
• Snyk + cosign + SBOM + multi-arch — стандартная заявка на enterprise-готовность.
• Image Catalogs убирают жёстко зашитые теги из манифестов Cluster — управление становится централизованным.
• Spread upgrades делают раскатку массовых апгрейдов безопасной для парка БД.
• Минимальные образы становятся основой для модульной поставки PostgreSQL и расширений в Kubernetes.

См. также: PostgreSQL 18 в Kubernetes, Рецепт 17 — in-place major-апгрейды.