Модуль 28. Kubernetes для Greenplum
Greenplum — MPP-СУБД на базе PostgreSQL с архитектурой координатор (master/standby) + множество сегментов (primary/mirror). Для Kubernetes это естественно ложится на StatefulSet + Headless Service + PVC per pod, а жизненный цикл и операции лучше доверить операторам (оператор Greenplum/кластера и смежные операторы). Такая связка позволяет декларативно поднимать/масштабировать кластеры, переживать сбои и автоматизировать обслуживание.
Архитектура Greenplum в терминах Kubernetes
Роли Greenplum
- Coordinator (master) — входная точка SQL, планировщик запросов; Standby master — горячий резерв координатора.
- Segment nodes — рабочие узлы MPP; каждому primary-сегменту соответствует mirror-сегмент для HA.
Отображение на k8s
- StatefulSet для сегментов: фиксированная идентичность segment-0/1/2…, PVC на каждый pod (RWO).
- Headless Service для стабильных DNS-имён сегментов (не через kube-proxy).
- Отдельные StatefulSet’ы (или шаблоны оператора) для primary и mirror групп с anti-affinity по зоне/ноде, чтобы пара «primary↔mirror» не оказалась на одном хосте.
- PDB + TopologySpreadConstraints — чтобы эвакуация/апгрейд не вырубали кворум сегментов.
-
Service на координатор (и отдельный на standby для репликации/проверок).
Базовая логика «StatefulSet + PVC per pod» — это канон для stateful-нагрузок в k8s.
Операторы (почему нужны и что дают)
Что автоматизируют
- Декларативный CR кластера GP и reconcile: инициализация, раздача ролей, создание/привязка томов, масштабирование сегментов, обновления и операции (rehash/rebalance), health-чек и self-heal.
- Корректную инициализацию данных (вплоть до автоматического gpinitsystem-подобного шага), wiring зеркал/standby, ротацию сертификатов и пр.
- Часто — интеграцию с окружением (например, streaming-серверы, sidecar’ы, мониторинг).
Есть ли «родные» реализации?
Да: Greenplum/VMware (Tanzu) публиковали решения/материалы по Greenplum for Kubernetes и операторному подходу: Greenplum Operator/Cluster CRD, а также смежные компоненты (например, Greenplum Streaming Server on Kubernetes использует operator-механику и CRD). Это подтверждает зрелость модели «GP + Operator» для k8s.
Хранилище и профили I/O
Рекомендации
- PV: RWO-блок (Ceph RBD/облачные диски/NVMe). NFS/RWX — не для сегментов (метаданные/блокировки).
- StorageClass с WaitForFirstConsumer, чтобы PV создавались в правильной зоне рядом с вычислением.
- Файловая система: XFS (часто для больших последовательных сканов) или ext4 — протестировать на вашем профиле.
- Отдельные PV под «горячие» каталоги (журналы/WAL-аналогичные структуры), если оператор/спека позволяет.
-
ReclaimPolicy=Retain для прод-томов (чтобы удаление PVC не удалило данные).
Базовая логика PV/PVC/StatefulSet для персистентности — стандартная практика k8s.
Отказоустойчивость (HA) и восстановление
Механика HA Greenplum
- Standby master обеспечивает отказоустойчивость координатора.
- Segment mirroring: у каждого primary-сегмента есть mirror; при сбое запросы продолжают выполняться через mirror на другом хосте/ноде. В k8s это усиливается anti-affinity и PDB.
Практические настройки
- Anti-affinity по hostname/zone для пар primary↔mirror.
- PDB так, чтобы одновременно недоступной могла быть максимум 1 реплика из пары.
- Graceful termination у pod’ов сегментов (времени достаточно на flush).
- Liveness/readiness: readiness должен означать «сегмент в нужной роли и в кворуме», а не просто «порт открыт».
Бэкапы и DR
- Логические бэкапы gpbackup/gprestore в S3/MinIO с версионированием; регулярные проверочные restore.
- Снапшоты PV (CSI/Velero) — как ускоритель RTO, но не замена логическим бэкапам.
- DR-вариант: периодический backup→restore на «холодный» кластер/namespace; для кросс-регионального сценария — репликация бакетов.
Мониторинг производительности
Слои метрик
- Координатор: план/latency запросов, очереди, ошибокки распределённых шагов.
- Сегменты: CPU/IOPS/latency дисков, saturation по соединениям, локальные ошибки запросов, ожидания, «горячие» таблицы/partition’ы.
- Кластер: состояние зеркал (primary/mirror), раскладка по зонам/нодам, stateful-подов и PVC.
- Инфра: apiserver/etcd/scheduler, диски нод.
Инструменты
- Prometheus + Grafana как база. Для «postgres-подобной» телеметрии на сегментах — postgres_exporter (с учётом совместимости версий) и кастомные SQL-вьюхи/экспортеры; у сопутствующих компонентов Tanzu есть примеры Prometheus-интеграции (стриминг-сервер). Общий подход — стандартный: экспортеры + дашборды + alert-правила.
SLO-идеи
- Успешность запросов ≥ 99%, p95 latency по ключевым запросам, отсутствие «degraded сегментов», свободное место ≥ 20%, отсутствие «mirror lag».
Эксплуатация в облаке (EKS/GKE/AKS/Yandex Managed Kubernetes)
Что обычно «болит» и как лечить
- Диски: берите блок-тома с предсказуемым IOPS (gp3/io1 в AWS, Premium SSD в Azure, Balanced/SSD в GCP). Для больших сканов — ширина пула и достаточный throughput.
- Зоны доступности: распределяйте primary↔mirror по разным AZ; StorageClass/подсети — с привязкой к зоне.
- Сеть: межзонная задержка — реальный фактор. Держите coordinator ближе к «масс-центру» сегментов.
- Автоскейлинг узлов: только со строгими taints/affinity; не давайте autoscaler’у «выпилить» ноду с единственной репликой шард-пары.
- Стоимость: холодные/архивные данные — в объектном хранилище; широкие тестовые стенды — на preemptible/spot-узлах, но сегменты prod — только на on-demand/зарезервированных.
Практика (лабораторка, 1–2 дня)
- Storage: создать 2 класса — fast-rwo (блок-диск, WaitForFirstConsumer) и shared-rwx (для вспомогательных шар, не для сегментов).
- Оператор: развернуть Greenplum-оператор, завести CR кластера: master+standby, N primary сегментов, N mirror; задать anti-affinity и spread по зонам.
- Мониторинг: подключить Prometheus, собрать метрики координатора и сегментов (экспортеры), построить дашборд SLO.
- Бэкапы: настроить gpbackup в MinIO/S3; выполнить контрольный restore в тестовый namespace.
- HA-проверка: вывести из строя ноду с одним из primary (drain), зафиксировать переключение на mirror, проверить SLO и алерты.
Риски и анти-паттерны
|
Риск |
Проявление |
Что делать |
|---|---|---|
|
RWX/NFS под сегменты |
блокировки/«стэлы», падение IOPS |
Только RWO-блок для данных сегментов |
|
Primary и mirror на одной ноде/AZ |
сбой ноды = потеря пары |
Anti-affinity + spread по зонам |
|
Случайные удаления PVC |
невосполнимая потеря |
ReclaimPolicy=Retain, ручная утилизация |
|
Readiness «всегда true» |
трафик идёт в «полумёртвые» сегменты |
Readiness по роли/кворуму/интерконнекту |
|
Нет регулярных restore-учений |
«бэкапы не работают» в момент Х |
Ежемесячные тесты restore и RTO/RPO |
|
Автоскейлер «съел» критичную ноду |
деградация MPP |
Taints/affinity + PDB; кластер-автоскейлинг с оговорками |
|
Кардинальность метрик/логов взорвалась |
тормоза Grafana/TSDB |
Контроль лейблов, recording rules, ретенции |
Мини-шаблоны (идеи, не копируйте без адаптации)
Анти-аффинность сегментов (эскиз в StatefulSet шаблоне):
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchLabels: { app: gp-segment, role: primary }
topologyKey: "kubernetes.io/hostname"
PDB для сегментной группы (держим минимум N-1 доступных):
apiVersion: policy/v1
kind: PodDisruptionBudget
spec:
minAvailable: 3 # под ваш размер группы
selector: { matchLabels: { app: gp-segment, group: a } }
Чек-лист «готово к продакшену (Greenplum в k8s)»
- Оператор развернут; кластер описан в CR; auto-reconcile включён.
- Сегменты в StatefulSet + PVC (RWO-блок), WaitForFirstConsumer, Reclaim=Retain.
- Primary↔mirror разведены по нодам/зонам (anti-affinity, spread); PDB на группы сегментов.
- Координатор + standby; сервисы и проверки ролей (readiness by role/quorum).
- gpbackup/gprestore в S3/MinIO; учения restore; DR-план.
- Prometheus/Grafana, экспортеры, SLO/алерты (latency, success, mirror lag, space).
- Runbook’и: «падение сегмента», «переключение master», «истощение дисков», «restore».
Вопрос-ответ
В: Есть ли «официальный» способ управлять Greenplum в Kubernetes?
О: Да, экосистема Greenplum/Tanzu публиковала Greenplum for Kubernetes и материал по Greenplum Operator/Cluster (CRD, контроллеры). Это как раз «k8s-способ» декларировать и обслуживать кластер GP.
В: Почему для сегментов нужен именно StatefulSet и PVC «на под»?
О: Сегменту требуется стабильная идентичность и собственный диск. Это классический паттерн k8s для БД/MPP: StatefulSet + PV/PVC per pod.
В: Как обеспечить отказоустойчивость данных?
О: На уровне Greenplum — segment mirroring и standby master; на уровне k8s — anti-affinity/ToplogySpread/PDB; на уровне бэкапов — gpbackup→S3 и регулярный restore.
В: Что мониторить в первую очередь?
О: Успешность и задержки запросов, состояние зеркал (mirror lag/degraded), свободное место/IOPS, ошибки сегментов, saturation по соединениям. Снимаем через Prometheus-экспортёры и стандартные интеграции.
В: Это вообще жизнеспособно в облаках?
О: Да. Ключевые условия: предсказуемые блок-диски (нормированный IOPS/throughput), разведение пар по AZ, контролируемый автоскейлинг узлов, и бюджет под хранение/логирование. Практика операторного подхода для Tanzu-компонентов (включая «родственные» сервисы) показывает, что k8s — нормальная среда для MPP-данных при правильной конфигурации.
Greenplum на Kubernetes работает надёжно, если сочетать три дисциплины: операторное управление, stateful-паттерны (StatefulSet+PVC) и HA/бэкапы на уровне самой СУБД. Добавьте наблюдаемость (метрики/алерты), чёткий DR-план и сетевую/зональную изоляцию — и получите MPP-кластер, который можно разворачивать, обновлять и восстанавливать так же рутинно, как любое k8s-приложение.
