PostgreSQL в облаке и Kubernetes
Раздел 8.11, шаг 8 из 12. Дальше — HA-кластеры.
On-premise, облако, Kubernetes — выбор
| Среда | Плюсы | Минусы |
|---|---|---|
| Bare metal / VM | Полный контроль GUC, I/O | Сами HA, бэкапы, patching |
| Managed (RDS, Azure DB, Cloud SQL, Yandex MDB) | HA, бэкапы, patching | Лимиты параметров, vendor lock-in |
| Self-hosted в Kubernetes | Единая платформа с приложением | Сложность stateful, нужен оператор |
| DBaaS в K8s (CloudNativePG, Zalando) | GitOps-friendly Postgres | Требует зрелого кластера и storage |
Общая модель shared responsibility в облаке — 3.08/3.
Managed PostgreSQL
Типовой набор возможностей:
- автоматические ежедневные snapshot + WAL/PITR;
- Multi-AZ / regional HA;
- read replicas в один клик;
- параметр-группы (часть GUC);
- Private endpoint — без публичного IP.
Подключение приложения в K8s:
env:
- name: DATABASE_URL
valueFrom:
secretKeyRef:
name: app-db-credentials
key: url
Secret создаётся Terraform/External Secrets из vault провайдера — шаг 12.
StatefulSet — минимальный паттерн
PostgreSQL в Kubernetes stateful: нужны stable network ID и persistent disk.
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: postgres
spec:
serviceName: postgres
replicas: 1
selector:
matchLabels:
app: postgres
template:
metadata:
labels:
app: postgres
spec:
containers:
- name: postgres
image: postgres:16-alpine
ports:
- containerPort: 5432
envFrom:
- secretRef:
name: postgres-credentials
volumeMounts:
- name: pgdata
mountPath: /var/lib/postgresql/data
readinessProbe:
exec:
command: ["pg_isready", "-U", "app"]
initialDelaySeconds: 10
periodSeconds: 5
volumeClaimTemplates:
- metadata:
name: pgdata
spec:
accessModes: ["ReadWriteOnce"]
storageClassName: fast-ssd
resources:
requests:
storage: 100Gi
Headless Service postgres даёт DNS postgres-0.postgres.default.svc.cluster.local.
StatefulSet с replicas: 1 без Patroni/оператора — single point of failure. Pod reschedule на другой node возможен (RWO volume attach), но failover и replication — ваши задачи (шаг 9).
Storage в Kubernetes
| Требование | Почему |
|---|---|
| ReadWriteOnce SSD | Latency WAL и random I/O |
| StorageClass с retain | Случайное удаление PVC не стирает prod |
| Достаточный IOPS | WAL sync — чувствителен к latency |
| Snapshots CSI | Бэкап на уровне volume — дополнение к pg_dump/Wal-G |
Local SSD (local-path-provisioner) даёт скорость, но привязку к node — complicates failover.
Операторы PostgreSQL
Вместо «голого» StatefulSet используют операторы:
| Оperator | Особенности |
|---|---|
| CloudNativePG | CNCF, backup Barman/Wal-G, failover |
| Zalando Postgres Operator | Patroni, Spilo образ, UI |
| Crunchy PGO | Enterprise-функции, pgBackRest |
Оператор создаёт CRD Cluster, управляет Patroni, backup jobs, connection pooler (PgBouncer sidecar).
Пример идеи (CloudNativePG — псевдо):
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
name: app-db
spec:
instances: 3
storage:
size: 100Gi
bootstrap:
initdb:
database: app
owner: app
backup:
barmanObjectStore:
destinationPath: s3://backups/app-db/
Несколько pod и сервисов
- postgres-rw — только primary (оператор выставляет label role=primary).
- postgres-ro — load balance SELECT на replicas.
Секреты и конфигурация
- Пароли — Kubernetes Secrets + rotation (External Secrets Operator).
postgresql.conf— ConfigMap + merge оператором или-cв spec.- NetworkPolicy — только namespace
app→ port 5432.
Anti-patterns
- Postgres в Deployment (не StatefulSet) с emptyDir.
- Horizontal Pod Autoscaler по CPU на primary — нельзя scale write master.
- Liveness probe, убивающая pod при long query.
- Общий NFS RWX для PGDATA — corruption risk; RWO на block storage.
- Запуск
VACUUM FULLна prod без окна.
Практика
- Minikube/kind — StatefulSet + PVC, проверка survive pod delete.
- Установите CloudNativePG или Zalando operator, кластер из 3 inst.
- Сравните latency managed vs self-hosted в том же регионе (pgbench).
Связанные материалы
См. также
Другие статьи этого же раздела в боковом меню (как на странице "О разделе"). MVCC, XID, снимки данных, системные поля xmin/xmax, VACUUM и autovacuum, bloat, wraparound, процессы postmaster, Shared Buffers и WAL. pg_dump, pg_basebackup, PITR, pg_probackup, Wal-G, стратегия 3-2-1, восстановление в Kubernetes и после failover. pg_stat_statements, pg_stat_activity, auto_explain, pgBadger, Prometheus postgres_exporter, типовые метрики SLA и алерты. Ansible role для установки Postgres, шаблоны postgresql.conf, Terraform для RDS и managed PostgreSQL, GitOps паттерны для инфраструктуры БД. EXPLAIN и EXPLAIN ANALYZE, B-tree, GiST, SP-GiST, GIN, BRIN, частичные и составные индексы, типовые ошибки планировщика. Тонкая настройка памяти (shared_buffers, work_mem, maintenance_work_mem), I/O (effective_cache_size, random_page_cost), WAL, checkpoint и autovacuum. Документная модель в Postgres, операторы и индексы JSONB, declarative partitioning по range/list/hash, связь с оконными функциями и CTE. Хранимые функции и процедуры PL/pgSQL, row-level и statement triggers, event triggers, асинхронные события через NOTIFY и LISTEN без polling. Streaming replication, logical replication, read replicas и Hot Standby, failover, connection pooling через PgBouncer — transaction и session pooling. Официальный образ postgres, volumes для PGDATA, переменные окружения, docker-compose с healthcheck, типовые ошибки контейнеризации СУБД. Patroni и DCS, сравнение с Greenplum и CockroachDB, когда нужен sharding, Citus, выбор архитектуры под OLTP и аналитику. Краткое резюме раздела 8.11 — архитектура, оптимизация, эксплуатация в контейнерах и Kubernetes, HA, бэкапы и автоматизация.Архитектура PostgreSQL и внутреннее устройство
Бэкапы PostgreSQL и восстановление
Профилирование и мониторинг PostgreSQL
Автоматизация PostgreSQL — Ansible и Terraform
Продвинутая оптимизация PostgreSQL и индексы
Конфигурация PostgreSQL — postgresql.conf
JSONB, партиционирование и расширения SQL в PostgreSQL
PL/pgSQL, триггеры и NOTIFY/LISTEN в PostgreSQL
Репликация PostgreSQL, Hot Standby и PgBouncer
PostgreSQL в Docker
HA-кластеры PostgreSQL и распределённые СУБД
Практикум PostgreSQL — итоги