Два Kubernetes-кластера — одна сеть: объединяем через Mesh и межкластерный роутинг

В сфере искусственного интеллекта произошло заметное событие. leshoi 18 минут назад Два Kubernetes-кластера — одна сеть: объединяем через Mesh и межкластерный роутинг Сложный 9 мин 538 Блог компании АО «ГНИВЦ» DevOps * Системное администрирование * Kubernetes * Сетевые технологии * Туториал Когда Kubernetes-кластеров становится больше одного, инфраструктура начинает жить по новым правилам. Один кластер развёрнут в основном датацентре, второй — в резервной площадке. Сложности начинаются в тот момент, когда этим кластерам нужно взаимодействовать друг с другом.

Сервисы в одном кластере должны обращаться к сервисам в другом, приложениям требуется нормальная маршрутизация, а администраторам хочется управлять этим без набора костылей. В этой статье разберём, как объединить два Kubernetes-кластера в единую сетевую среду, где: pod'ы могут общаться напрямую между собой сервисы доступны между кластерами трафик можно гибко маршрутизироватьВ качестве сетевого слоя будем использовать Calico, а для межкластерного взаимодействия сервисов — Istio. Первый даст маршрутизацию и связность, второй — discovery, балансировку и управление трафиком на уровне приложений.

Технические детали

ДисклеймерОписанный подход на момент написания обкатывается только на тестовых контурах. Под нагрузкой поведение системы не валидировалось, поэтому гарантировать стабильность или предсказуемость в реальных сценариях не могу. Фактически, сейчас можно опираться лишь на синтетические тесты Istio и рассчитывать на корректную работу Calico.

Отдельный риск — наличие критических багов в BGP-реализации, которые в условиях межкластерной маршрутизации могут проявиться не сразу. Зачем объединять два кластераЕсли второй Kubernetes-кластер у вас уже есть, значит причина для этого давно найдена. Обычно вопрос стоит не в необходимости второго кластера, а в том, как заставить два независимых окружения работать удобно и предсказуемо, если на то есть потребность.

Чаще всего несколько кластеров связывают через внешний входной слой: LoadBalancer, Ingress, публичные DNS-имена. Для пользовательских запросов это нормально, но для внутреннего взаимодействия сервисов такой путь выглядит не очень. Один backend в первом кластере обращается ко второму backend во втором кластере, при этом запрос выходит наружу, проходит через ingress-контур и только потом возвращается обратно во внутреннюю сеть.

Отраслевые последствия

В этой статье пойдём другим путём — построим привычную внутреннюю связность между кластерами. Такую, где можно обращаться к сервисам через Service, DNS-имена Kubernetes и при необходимости напрямую по Pod IP, будто перед нами не два отдельных кластера, а единая среда. Архитектура решенияВ основе решения лежат два независимых Kubernetes-кластера, каждый со своим control plane, worker-нодами и стандартным набором сервисов.

Pod CIDR и Service CIDR в кластерах не должны пересекаться. КластерPod CIDRService CIDRcluster-a10. 0/12Также стоит заранее проверить MTU, firewall и доступность портов для BGP, Istio east-west gateway.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.