Перейти на PRO

Как развернуть PostgreSQL в Kubernetes?

Тип вопроса: DevOps Вероятность: 10% Категория: Java Разработчик

Ответ

Развертывание stateful-приложений, таких как PostgreSQL, в Kubernetes требует особого подхода, так как им необходимо устойчивое хранилище и стабильные сетевые идентификаторы.

Ключевые концепции и ресурсы:

  1. StatefulSet: Вместо Deployment. Гарантирует порядок развертывания и уникальные, постоянные идентификаторы подов (postgres-0, postgres-1).
  2. PersistentVolume (PV) / PersistentVolumeClaim (PVC): Для хранения данных, которые должны сохраняться при перезапуске пода.
  3. Headless Service: Для стабильного DNS-имени каждого пода в StatefulSet (например, postgres-0.postgres.default.svc.cluster.local).

Пример минимального StatefulSet для PostgreSQL:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres
spec:
  serviceName: "postgres-hl" # Имя headless service
  replicas: 1
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
      - name: postgres
        image: postgres:15
        env:
        - name: POSTGRES_PASSWORD
          valueFrom:
            secretKeyRef:
              name: postgres-secret
              key: password
        volumeMounts:
        - name: data
          mountPath: /var/lib/postgresql/data
  volumeClaimTemplates: # PVC создается для каждого пода автоматически
  - metadata:
      name: data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 10Gi

Рекомендации для production:

  • Используйте операторы: Например, Zalando Postgres Operator или CloudNativePG, которые автоматизируют репликацию, бэкапы и отказоустойчивость.
  • Рассмотрите managed-сервисы: Для production-нагрузок часто надежнее использовать внешний managed PostgreSQL (от облачного провайдера или сторонний сервис), чтобы отделить данные от оркестратора приложений.

Ответ 18+ 🔞

Давай разберём эту дичь, как развернуть базу данных в кубере, чтобы она не сдохла при первом же чихе. Это же не какой-нибудь там статичный контейнер, который можно тупо перезапустить — тут данные, ёпта, они святые!

В чём, блядь, соль?

  1. StatefulSet — твой новый бог. Забудь про эти Deployment для баз. StatefulSet — это такой занудный тип, который гарантирует, что твои поды будут запускаться по очереди, как в очереди за колбасой, и у каждого будет своё постоянное, ёбта, имя, типа postgres-0, postgres-1. Перезапустился — имя то же, все довольны.
  2. PersistentVolume (PV) / PersistentVolumeClaim (PVC) — твоя память. Это чтобы данные не испарились, когда под ляжет. Как будто у тебя внешний жёсткий диск, а не оперативка.
  3. Headless Service — твоя телефонная книга. Обычный сервис даёт один общий адрес, а эта хитрая жопа даёт каждому поду в StatefulSet своё собственное DNS-имя. Хочешь постучаться именно к postgres-0? Пожалуйста: postgres-0.postgres-hl.default.svc.cluster.local. Красота, блядь.

Вот, смотри, набросал тебе простенький манифест, чтоб понял суть:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres
spec:
  serviceName: "postgres-hl" # Это имя той самой headless-штуки
  replicas: 1
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
      - name: postgres
        image: postgres:15
        env:
        - name: POSTGRES_PASSWORD
          valueFrom:
            secretKeyRef:
              name: postgres-secret # Пароль из секрета, а то мало ли кто прочитает
              key: password
        volumeMounts:
        - name: data
          mountPath: /var/lib/postgresql/data # Сюда база свои файлы пишет
  volumeClaimTemplates: # А это магия! Для каждого нового пода автоматом создаст PVC.
  - metadata:
      name: data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 10Gi

А теперь, блядь, самое важное для продакшена:

  • Операторы — твои лучшие друзья. Не выёбывайся, конфигурируя репликацию и бэкапы вручную. Возьми Zalando Postgres Operator или CloudNativePG. Они как личные рабы для твоей базы: сами всё настроят, починят, в случае чего откатят. Овердохуища удобства.
  • Серьёзно, подумай про managed-сервис. Если нагрузка реальная, а не для галочки, то самый разумный поступок — вынести базу за пределы кубера. Взять тот же RDS от AWS, Cloud SQL от Google или сторонний сервис. Зачем тебе этот геморрой с хранением самых ценных данных внутри оркестратора, который может в любой момент, прости господи, накрыться медным тазом? Отдели мух от котлет, и спи спокойно.
© ХакСобесов, 2026
support@hacksobesov.com