Рецепт 21. Тонкий контроль кластеров Postgres через liveness probes

Оригинал: CNPG Recipe 21 — Finer Control of Postgres Clusters with Liveness Probes — 15 августа 2025.

Завершающий аккорд серии о пробах (Рецепт 19 — startup, Рецепт 20 — readiness): теперь — liveness. И самое интересное здесь — новая дефолтная проверка изоляции primary, которая решает старую боль HA — split-brain.

Что такое liveness probes

Liveness-проба гарантирует, что нагрузка (в нашем случае PostgreSQL) остаётся работоспособной. Запускается после успеха startup-пробы и крутится непрерывно в течение всей жизни контейнера. Параметры те же: failureThreshold, periodSeconds, successThreshold, timeoutSeconds.

Реализация в CloudNativePG

Liveness-проба проверяет, что instance manager (entrypoint-процесс, который служит «продолжением» оператора внутри пода) отвечает на запросы. По умолчанию — успех, если instance manager отвечает в пределах .spec.livenessProbeTimeout (дефолт 30 секунд).

В CloudNativePG 1.27 добавлена дополнительная проверка для primary: убедиться, что primary имеет связь с Kubernetes API-сервером и с instance manager’ами реплик.

Маппинг .spec.livenessProbeTimeout на параметры Kubernetes:

failureThreshold: FAILURE_THRESHOLD
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 5

Где FAILURE_THRESHOLD = livenessProbeTimeout / periodSeconds. С дефолтами (30 / 10) FAILURE_THRESHOLD = 3.

Полная кастомизация

Если нужен ещё более тонкий контроль — через .spec.probes.liveness:

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: freddie
spec:
  instances: 3

  storage:
    size: 1Gi

  probes:
    liveness:
      periodSeconds: 5
      failureThreshold: 6

Проба каждые 5 секунд, 6 подряд провалов до маркировки «unhealthy» — то же 30-секундное окно, но с более частыми проверками.

Liveness и изоляция primary

Самое важное в этом рецепте — новый дефолт в 1.27 (экспериментально появился в 1.26). Он закрывает риск split-brain при сетевых разделениях.

Теперь liveness primary дополнительно проверяет, что primary может:

• достучаться до Kubernetes API-сервера;
• достучаться до REST API instance manager’ов реплик.

Если хотя бы одна из этих проверок не проходит дольше livenessProbeTimeout — kubelet рестартит под. При рестарте instance manager пытается скачать определение Cluster. Если не может (изолирован) — PostgreSQL не запустится. Это не позволит изолированному primary продолжать принимать запись.

Эффект: окно потенциального split-brain сокращается до ~30 секунд по умолчанию. Это встроенный аналог Patroni failsafe mode, но без внешней зависимости — всё интегрировано в Kubernetes-нативно.

Если по какой-то причине надо отключить:

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: freddie
spec:
  instances: 3

  storage:
    size: 1Gi

  probes:
    liveness:
      isolationCheck:
        enabled: false

Главные выводы

• Primary isolation включён по умолчанию. Liveness-проба primary проверяет связь с API-сервером и с репликами.
• Split-brain mitigation. Окно, в котором два primary могут принимать запись, сильно сокращается; в связке с синхронной репликацией риск split-brain практически нулевой.
• Kubernetes-native. Никаких внешних зависимостей вроде etcd / Consul.
• Фундамент под продвинутый failover. Готовит почву под experimental quorum-based failover в 1.27, который станет stable в 1.28 — для безопасного failover’а с синхронной репликацией.

CloudNativePG идёт поэтапно: сначала навели порядок в startup и readiness, потом — primary isolation, дальше — продвинутый failover. Это отражает фокус команды на стабильности, безопасности и community-driven решениях.

См. также Рецепт 19 — startup probes, Рецепт 20 — readiness probes.