Оригинал: CloudNativePG Recipe 9 — Inspecting the Network and Storage in a CloudNativePG Cluster — 9 июля 2024.
Разбор сетевых и storage-ресурсов кластера CloudNativePG — то, что нужно знать DBA, переходящему из «классической» инфраструктуры в Kubernetes.
Сеть
CloudNativePG использует Kubernetes Service для абстрагирования primary/standby-архитектуры PostgreSQL. По умолчанию создаётся три сервиса:
-rw— указывает на текущий primary (через label-selector);-ro— балансирует read-only запросы по доступным hot-standby;-r— отправляет трафик на любой инстанс (включая primary).
Цитата:
«CloudNativePG скрывает сложность primary/standby PostgreSQL за сервисом, который всегда указывает на primary.»
Приложениям не нужно знать имена подов — это делает оператор.
При фейловере оператор обновляет лейблы подов, и сервисы автоматически перенаправляются на новый primary. Self-healing без ручного вмешательства.
Storage
CloudNativePG управляет файлами PostgreSQL через PVC (PersistentVolumeClaim) — в типовой схеме:
- один PVC под
PGDATA; - (опционально) отдельный PVC под WAL;
- (опционально) PVC под каждый tablespace.
Ключевые атрибуты PVC:
- storage class;
- access mode (обычно
ReadWriteOnce); - volume mode (обычно
Filesystem); - лейблы CloudNativePG, описывающие назначение тома.
Вывод
DBA, который мигрирует в Kubernetes, не обязан знать всю экосистему. Достаточно понимать ровно столько, чтобы эффективно управлять Cluster-объектами CloudNativePG и продуктивно общаться с инфраструктурными и продуктовыми командами.