Иммутабельное будущее расширений PostgreSQL в Kubernetes

Оригинал: The Immutable Future of PostgreSQL Extensions in Kubernetes with CloudNativePG — 3 марта 2025.

Расширения PostgreSQL — одна из самых больных тем при запуске Postgres в Kubernetes: иммутабельные контейнеры с одной стороны и желание устанавливать произвольные .so-библиотеки в /usr/share/postgresql/... — с другой. Этот пост — про то, как PostgreSQL 18 (extension_control_path) и Kubernetes 1.31+ (ImageVolume) в связке закрывают эту проблему по-настоящему. CloudNativePG (теперь — CNCF Sandbox) уже умеет описывать расширения декларативно.

Текущий подход: pre-built operand-образы

CloudNativePG всегда придерживался Kubernetes-принципа иммутабельных образов. Но это создаёт напряжение с главной фишкой PostgreSQL — расширяемостью.

Текущие ограничения:

Большие образы при упаковке нескольких расширений.
Жёсткий выбор расширений → пользователи вынуждены идти на компромиссы.
Операционная сложность: приходится поддерживать собственные образы.
Compliance-проблемы для команд без packaging-экспертизы.

Раньше рассматривался вариант динамической установки расширений в зарезервированный volume — его отвергли как «нарушающий принцип иммутабельности».

Чего не хватало в PostgreSQL

PostgreSQL традиционно требует, чтобы расширения лежали в системной директории /usr/share/postgresql/17/extension. Это конфликтует с read-only-файловой системой, обязательной для security-модели CloudNativePG.

`extension_control_path`

Патч в PostgreSQL 18 добавляет настройку, по которой Postgres умеет искать .control-файлы и shared-библиотеки в нескольких директориях — вместо единственной системной. Авторы патча: Peter Eisentraut, Andrew Dunstan, Matheus Alcantara — на основе работы Christoph Berg и обсуждений, начатых David Wheeler.

Чего не хватало в Kubernetes

`ImageVolume`

Появилась в Kubernetes 1.31 как alpha. Позволяет монтировать container-образ как read-only volume в под. То есть расширение PostgreSQL можно упаковать в отдельный, минимальный OCI-образ, и оператор смонтирует его в нужную директорию. К Kubernetes 1.33 фича ожидается в beta.

Как это потестили в CloudNativePG

Лёгкие образы расширений

Тестовый образ pgvector весит 1.6 МБ — внутри только директории lib и share.

BASH

dive ghcr.io/cloudnative-pg/pgvector-18-testing:latest
Нажмите, чтобы развернуть и увидеть больше

Декларативный деплой

Пример декларативной конфигурации:

YAML

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: postgresql-with-extensions
spec:
  instances: 1
  imageName: ghcr.io/cloudnative-pg/postgresql-trunk:18-cf-4913
  postgresql:
    extensions:
      - name: pgvector
        image:
          reference: ghcr.io/cloudnative-pg/pgvector-18-testing:latest
  storage:
    storageClass: standard
    size: 1Gi
Нажмите, чтобы развернуть и увидеть больше

Что происходит под капотом

Оператор:

Триггерит rolling update, начиная с реплик.
Монтирует указанные образы как read-only volume через ImageVolume.
Автоматически обновляет dynamic_library_path и extension_control_path — добавляет соответствующие поддиректории.

Проверка:

SQL

SELECT * FROM pg_available_extensions WHERE name = 'vector';
Нажмите, чтобы развернуть и увидеть больше

Требования

Чтобы это всё заработало, нужно:

Kubernetes 1.31+ с включённым feature gate ImageVolume;
container runtime CRI-O (поддержка containerd ещё в процессе).

Выводы

Это не косметическое улучшение, а смена парадигмы управления расширениями PostgreSQL в Kubernetes. Связка PostgreSQL extension_control_path + Kubernetes ImageVolume создаёт «новую эру динамического, иммутабельного и масштабируемого управления расширениями».

Что мы получаем:

Установка сторонних расширений динамически, без пересборки core-образа.
Удобство тестирования и валидации расширений.
Апгрейды расширений независимо от апгрейдов БД.
Сохранение строгой иммутабельности — со всеми security- и maintenance-плюшками.

Авторы расширений должны будут «принять OCI-образы как first-class артефакты» наряду с традиционными пакетами. С PostgreSQL 18 и Kubernetes 1.33 экосистема позволит держать operand-образ Postgres минимальным, а расширения собирать декларативно из отдельных OCI-образов.

«Будущее расширений PostgreSQL в Kubernetes — иммутабельное, но гибкое. Так и должно быть.»