Связывание мультиоблачных кластеров Kubernetes с помощью Cilium Cluster Mesh

Связывание мультиоблачных кластеров Kubernetes с помощью Cilium Cluster Mesh

Сетевое взаимодействие между подами в разных кластерах Kubernetes (например, AWS EKS и Google Cloud GKE) традиционно решается через внешние балансировщики нагрузки (LoadBalancer) или прикладные шлюзы. Это увеличивает расходы, задержки и усложняет безопасность. Технология Cilium Cluster Mesh решает проблему иначе — на уровне CNI с использованием eBPF, создавая плоскую сеть для прямого взаимодействия подов без трансляции адресов (NAT) и L7-прокси.

В отличие от традиционных решений класса Service Mesh (например, Istio или Linkerd), использующих прокси-серверы sidecar (типа Envoy) для перенаправления трафика на прикладном уровне, Cilium работает непосредственно в ядре Linux с помощью eBPF. Это обеспечивает минимальные накладные расходы и высокую пропускную способность.

Сетевая модель базируется на трех концепциях:

1. Плоская сеть (Flat Network): Поды взаимодействуют напрямую по своим IP-адресам без NAT, если настроена базовая маршрутизация.
2. Синхронизация подов и сервисов: Специализированный компонент kvstoremesh транслирует информацию о состоянии ресурсов и политиках безопасности между кластерами.
3. Глобальные сервисы (Global Services): Сервисы объединяются в единую службу, распределяющую запросы между репликами во всех кластерах.

Предварительные требования и сетевое планирование

Перед настройкой крайне важно провести аудит сетевой инфраструктуры. Ошибки на этапе планирования адресации могут привести к необходимости пересоздания кластеров.

Для успешной работы Cilium Cluster Mesh должны быть соблюдены следующие условия:

• Уникальность адресных пространств (PodCIDR): Подсети подов в кластерах не должны перекрываться. Например, если в EKS используется 10.244.0.0/16, то in GKE должен быть другой диапазон, например 10.245.0.0/16.
• Базовая сетевая связность узлов: Узлы (Worker Nodes) обоих кластеров должны иметь возможность общаться по внутренним IP-адресам (InternalIP). В мультиоблачной среде это требует настройки VPN-тунлеля или VPC Peering (прямого объединения виртуальных сетей облаков) с корректировкой таблиц маршрутизации и правил межсетевых экранов.
• Идентичность сетевого режима (Datapath Mode): Оба кластера должны использовать одинаковый режим работы Cilium — либо инкапсуляцию (VXLAN или Geneve), либо прямую маршрутизацию (Native Routing).
• Уникальность имен кластеров: Каждый кластер должен иметь уникальное имя (параметр cluster.name в конфигурации Cilium) и идентификатор (cluster.id от 1 до 255).

Инструкция по настройке и запуску Cluster Mesh

Все команды по установке и конфигурации выполняются системным администратором на локальном компьютере разработчика через консольный терминал (CLI), имеющий доступ к контекстам управления Kubernetes (kubectl).

Шаг 1. Активация Cluster Mesh на кластерах

Сначала необходимо включить модуль Cluster Mesh на каждом кластере по отдельности. Это действие запускает внутренний API-сервер Cluster Mesh и настраивает TLS-сертификаты для безопасного шифрования служебного трафика.

Выполните в терминале для первого кластера (AWS EKS):

cilium clustermesh enable --context eks-cluster-context --service-type NodePort

Здесь параметр --context указывает имя контекста подключения в файле kubeconfig, а --service-type NodePort указывает способ публикации API-сервера Mesh.

Активируйте Mesh на втором кластере (Google Cloud GKE):

cilium clustermesh enable --context gke-cluster-context --service-type NodePort

После запуска подождите завершения инициализации компонентов. Проверить статус готовности API-сервера в каждом кластере можно следующей командой:

cilium clustermesh status --context eks-cluster-context --wait

Шаг 2. Соединение кластеров в единую сеть

После того как API-серверы запущены на обеих сторонах, необходимо инициировать их взаимное сетевое подключение. Утилита CLI автоматически извлечет публичные ключи шифрования, настроит безопасный обмен данными и свяжет кластеры.

Запустите команду соединения из терминала локального компьютера:

cilium clustermesh connect --context eks-cluster-context --destination-context gke-cluster-context

Эта команда устанавливает двунаправленное доверие, считывает конфигурацию из контекста назначения (gke-cluster-context) и применяет настройки к исходному контексту (eks-cluster-context).

Для проверки успешности соединения выполните команду мониторинга:

cilium clustermesh status --context eks-cluster-context

Шаг 3. Конфигурация глобальных сервисов и локальной аффинности

Теперь, когда сетевой мост построен, приложения могут взаимодействовать между кластерами. Для автоматического распределения запросов используется механизм Global Services.

Создайте в обоих кластерах стандартный манифест сервиса Kubernetes (например, для веб-приложения frontend-service), добавив специальную аннотацию. Сохраните следующий конфигурационный файл как service.yaml на диске локального компьютера:

apiVersion: v1
kind: Service
metadata:
  name: frontend-service
  namespace: default
  annotations:
    # Активируем глобальный режим для автоматического объединения эндпоинтов
    service.cilium.io/global: "true"
    # Настраиваем предпочтение локального кластера для минимизации задержек и стоимости
    service.cilium.io/affinity: "local"
spec:
  ports:
  - port: 80
    targetPort: 8080
  selector:
    app: frontend

Примените данный файл в терминале к обоим кластерам:

kubectl apply -f service.yaml --context eks-cluster-context
kubectl apply -f service.yaml --context gke-cluster-context

Аннотация service.cilium.io/affinity: "local" указывает Cilium направлять запросы на поды внутри текущего кластера, пока они находятся в здоровом состоянии. Перенаправление трафика в другой кластер произойдет только тогда, когда все локальные реплики упадут. Это критически важно, так как межоблачный трафик является платным и имеет более высокие задержки.

Тестирование отказоустойчивости и верификация

Чтобы убедиться в надежности работы сети, необходимо провести три проверочных сценария в тестовой среде.

1. Тестирование локального удаления пода: Отправьте поток HTTP-запросов к сервису frontend-service из тестового пода в кластере AWS EKS. Удалите один из подов веб-приложения в EKS. Убедитесь, что Cilium мгновенно перенаправляет запросы на оставшиеся поды в этом же кластере без прерывания обслуживания.
2. Тестирование полного падения локального сервиса (Failover): Уменьшите количество реплик приложения frontend в кластере AWS EKS до нуля:

   kubectl scale deployment frontend --replicas=0 --context eks-cluster-context
   

   Проверьте, что поток запросов автоматически переключился на поды в кластере Google Cloud GKE. Сетевая задержка при этом возрастет, но запросы продолжат обрабатываться успешно.
3. Имитация разрыва межоблачного канала (Split-Brain): Заблокируйте сетевые порты подключения Cluster Mesh на уровне межсетевого экрана в облачной панели управления. Убедитесь, что оба кластера изолировали себя друг от друга и перешли в режим автономной работы, обслуживая локальных клиентов только собственными силами.

Информационная безопасность и least-privilege политики

Объединение сетей кластеров значительно упрощает взаимодействие разработчиков, но создает новые риски безопасности. После включения Cluster Mesh любой под из одного кластера потенциально может отправить пакет поду в другом кластере.

Рекомендуется придерживаться концепции наименьших привилегий (Least Privilege):

• Ограничивайте межкластерное взаимодействие с помощью сетевых политик Cilium Network Policy (CNP), явно прописывая разрешенные источники (селекторы пространств имен и меток подов) и блокируя несанкционированный трафик.
• Никогда не делайте инфраструктурные и системные пространства имен (например, сбор логов или мониторинг) открытыми для запросов из любых прикладных подов смежных кластеров.

План отката изменений

В случае возникновения проблем с маршрутизацией или стабильностью межоблачного канала, процедура отката выглядит следующим образом:

1. Удалите аннотацию service.cilium.io/global из манифестов сервисов. Это мгновенно разорвет связь, вернув поведение служб к стандартному локальному режиму.
2. Разорвите физическое соединение между кластерами, выполнив команду отключения в терминале:

   cilium clustermesh disconnect --context eks-cluster-context --destination-context gke-cluster-context
   

3. При необходимости полностью отключите API-серверы Cluster Mesh на обеих сторонах, выполнив команду отключения:

   cilium clustermesh disable --context eks-cluster-context
   

Cilium Cluster Mesh делает сетевые вызовы между AWS и GCP прозрачными для кода приложений, однако требует строгого контроля за маршрутизацией, бюджетом сетевого трафика и политиками безопасности.