Приложения в нескольких кластерах развёртывают по нескольким причинам:
⚪️ Запуск реплик в разных зонах доступности, регионах или у разных провайдеров для защиты от глобальных сбоев.
⚪️ Приближение бэкенда к пользователям по всему миру.
⚪️ Изоляция критических сред. В отличие от логической изоляции через
Namespaces, разделение по кластерам защищает от сбоев на уровне Control-Plane.⚪️ Вынос мониторинга или логирования в отдельный служебный кластер, который должны видеть все остальные.
Самый очевидный способ связать два сервиса в разных кластерах — выставить сервис в кластере-2 наружу через
LoadBalancer и стучаться в него из кластера-1 по внешнему IP. Но есть и минусы:⚪️ Облачные балансировщики стоят дорого, а в On-Prem средах внешние IP-адреса ограничены.
⚪️ Для удаленного кластера этот трафик выглядит как обычный внешний запрос. Теряются метаданные Kubernetes и сквозная авторизация.
Cluster Mesh работает иначе: создает единую виртуальную оверлейную сеть между кластерами. Для приложений это выглядит так, будто они находятся в одной сети с единым пространством имен и идентичностей.
Чтобы узнать, как объединить Kubernetes-кластеры в разных облаках через Cluster Mesh на примере Cilium, Amazon EKS (AWS) и Google GKE (GCP), рекомендуем статью. Узнаете про архитектуру сетевого взаимодействия, режимы маршрутизации CNI, посмотрите практический сценарий и сможете реализовать у себя.
👈 Читать статью
@DevOpsKaz 😛