Как спроектировать отказоустойчивое размещение приложения в Kubernetes на несколько зон доступности или регионов, и какие здесь есть принципиальные компромиссы?

Короткий ответ

Единственно верного решения нет: мульти-зональный кластер с topologySpreadConstraints/anti-affinity решает большинство сценариев отказа зоны при умеренной сложности, тогда как мульти-региональная (или мульти-кластерная) архитектура даёт устойчивость к отказу целого региона ценой значительно большей операционной сложности, задержек репликации данных и затрат — выбор зависит от требуемого RTO/RPO, характера состояния приложения и бюджета.

Как это работает подробнее

один кластер, растянутый на несколько зон доступности в одном регионе, решает проблему отказа узла/стойки/зоны при относительно низкой сложности — control plane управляемого кластера (EKS/GKE/AKS) обычно уже мульти-зонален, а worker-узлы распределяют через topologySpreadConstraints и зональные node pools. Для защиты от отказа всего региона нужен либо активный мульти-региональный кластер (сложная синхронизация stateful-компонентов, глобальный DNS/балансировка), либо отдельные кластеры на регион с репликацией данных и механизмом переключения трафика (failover).

• Компромисс. мульти-зональность внутри региона — разумный баланс стоимости и отказоустойчивости для большинства команд; мульти-регион нужно обсуждать предметно, оценивая реальную вероятность отказа целого региона у конкретного провайдера, стоимость поддержки второго полноценного окружения, сложность data-слоя (можно ли вообще синхронно реплицировать используемую БД между регионами с приемлемой задержкой) и то, кто и как тестирует failover на практике, а не только на бумаге.

Пример кода

manifest.yamlКопировать

topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: DoNotSchedule
    labelSelector: { matchLabels: { app: checkout } }

Что использовать на практике

• Практика. для большинства бизнес-приложений без жёстких регуляторных требований достаточно мульти-зональной отказоустойчивости в рамках одного региона — это покрывает подавляющее большинство реальных инцидентов (отказ ЦОД/зоны) при разумной стоимости. Мульти-региональная архитектура оправдана, когда бизнес явно требует непрерывности при отказе целого облачного региона (финансовые сервисы, критическая инфраструктура) — но тогда нужно отдельно решать вопрос консистентности данных между регионами (синхронная репликация увеличивает задержку, асинхронная создаёт риск потери данных при failover).

Подводные камни

• Риски. кандидаты часто приравнивают простое увеличение числа реплик к реальной отказоустойчивости, забывая про topologySpreadConstraints/anti-affinity, из-за чего все реплики могут случайно оказаться в одной зоне; также нередко называют мульти-регион "просто ещё одним кластером", не упоминая проблему консистентности данных и необходимость явного RTO/RPO.