Привет, Хабр. Продолжаем изучение Istio и сегодня рассмотрим некоторые интересные особенности, которые в дальнейшем могут облегчить сопровождение и развитие сервисной mesh-инфраструктуры в Kubernetes. С ростом распределённых систем и микросервисных архитектур в Kubernetes всё чаще встаёт вопрос о построении надёжной, масштабируемой и безопасной сетевой инфраструктуры. Когда одного кластера становится недостаточно, возникает потребность объединить несколько инсталляций в единую mesh-сеть. Здесь и появляется Istio, как кандидат на реализацию мультикластерной архитектуры.

В этой статье рассматриваются:

• Подходы Istio к мультикластерной интеграции

• Их преимущества и ограничения

• Безопасность и управление в таких сценариях

• Концепция external Istio

• Модели изоляции

• Практические рекомендации по применению

Статус релизов:

Архитектурные модели Istio для мультикластера

Выбор архитектурной модели зависит от:

• Возможностей сети (общая/раздельная)

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

• Объёма управления и автоматизации

Istio предлагает несколько архитектурных моделей для работы в мультикластерной среде. Выбор подхода зависит от инфраструктурных ограничений, требований безопасности и уровня зрелости DevOps-процессов.

Вот основные из них:

1. Single Network, Shared Control Plane

В простейшем случае сервисная mesh-сеть работает в рамках одной полностью связной сети. В этой модели все экземпляры рабочих нагрузок могут взаимодействовать напрямую — без использования Istio-шлюзов (gateway).

Модель единой сети позволяет Istio единообразно настраивать потребителей сервисов по всей mesh-сети с возможностью прямого обращения к экземплярам нагрузок. Однако следует учитывать, что при использовании единой сети для нескольких кластеров IP-адреса сервисов и конечных точек (endpoints) не должны пересекаться.

Плюсы:

• Простота конфигурации.

• Минимальные накладные расходы на поддержку control plane.

• Быстрое масштабирование.

Минусы:

• Tight coupling: сбой control plane влияет на весь кластер.

• Меньшая гибкость с точки зрения RBAC и изоляции.

2. Single Network, Replicated Control Planes

Каждый кластер содержит собственную control plane, но между ними происходит синхронизация данных. Они взаимодействуют через общую сетевую плоскость.

Плюсы:

• Изолированные control plane — отказоустойчивость выше.

• Можно реализовать независимое управление каждым кластером.

Минусы:

• Усложнённая конфигурация синхронизации.

• Необходимость согласованного обновления версий Istio между кластерами.

3. Multiple Networks, Replicated Control Planes

Модель с несколькими сетями предоставляет дополнительные возможности по сравнению с единой сетью:

• Поддержка пересекающихся IP- или VIP-диапазонов для сервисов

• Возможность пересечения административных границ

• Повышение отказоустойчивости

• Масштабирование IP-пространства

• Соответствие стандартам, требующим сетевой сегментации

В этой модели экземпляры рабочих нагрузок из разных сетей могут взаимодействовать только через один или несколько шлюзов Istio. Istio применяет раздельное обнаружение сервисов (partitioned service discovery), предоставляя различное представление о конечных точках в зависимости от сети потребителя.

Плюсы:

• Подходит для гибридных и мультиоблачных сценариев.

• Высокий уровень отказоустойчивости.

• Чёткая изоляция сетей.

Минусы:

• Самый высокий уровень сложности настройки и отладки.

• Требует настройки gateway’ев, DNS, сертификатов и trust domain'ов.

Для работы такой схемы необходимо опубликовывать все (или часть) сервисов через шлюз. Для обеспечения безопасного взаимодействия в многосетевом сценарии Istio поддерживает кросс-сетевое взаимодействие только с рабочими нагрузками, использующими Istio-прокси. Это связано с тем, что Istio предоставляет сервисы на Ingress-шлюзе с TLS pass-through, что позволяет использовать mTLS для прямого подключения к нагрузке. Рабочие нагрузки без прокси, как правило, не смогут участвовать во взаимной аутентификации, поэтому такие конечные точки исключаются из маршрутов для сервисов без прокси.

DNS в multicluster среде

При обращении клиента к какому-либо сервису он сначала выполняет DNS-запрос для получения IP-адреса. В Kubernetes DNS-запросы обрабатываются внутренним DNS-сервером кластера на основе определений Service.

Istio использует виртуальный IP, полученный из DNS, для балансировки нагрузки по активным конечным точкам сервиса с учетом заданных правил маршрутизации. Для этого используется информация из объектов Kubernetes Service/Endpoint или Istio ServiceEntry.

При наличии нескольких кластеров эта двухуровневая система имён усложняется. Istio изначально поддерживает multicluster, а Kubernetes — нет. Поэтому DNS-запись для сервиса должна существовать в кластере-клиенте, даже если pod'ы этого сервиса не запущены в данном кластере.

Чтобы DNS-запросы успешно проходили, необходимо создать объект Service в каждом кластере, где используется данный сервис. Это обеспечивает успешное разрешение имени и передачу запроса в Istio для дальнейшей маршрутизации. Альтернативно, можно использовать ServiceEntry, но он не обновляет DNS Kubernetes. В этом случае настройку DNS нужно производить вручную или с помощью инструментов, например, Address auto allocation в Istio DNS Proxying.

Актуальные инициативы по упрощению работы с DNS

• Admiral — проект сообщества Istio, предоставляющий расширенные возможности для multicluster-сред. Он автоматизирует создание и синхронизацию конфигураций между кластерами, особенно актуально при использовании сложных сетевых топологий.

• Kubernetes Multi-Cluster Services (MCS) — предложение по улучшению Kubernetes (KEP), создающее API для экспорта сервисов в несколько кластеров. Это переносит ответственность за доступность сервисов и DNS-резолвинг на Kubernetes. Также ведётся работа по интеграции поддержки MCS в Istio, что позволит использовать контроллеры MCS от облачных провайдеров или сам Istio в роли контроллера.

Безопасность в мультикластере

Одним из ключевых преимуществ Istio остаётся zero-trust модель безопасности. В мультикластерной архитектуре она сохраняется, но требует дополнительного внимания:

• Trust domain: каждый кластер должен иметь уникальный trust domain.

• SPIFFE/SVID: удостоверения сервисов должны быть согласованы между control plane’ами.

• mTLS между кластерами: трафик шифруется даже при пересечении сетей.

Модели control plane в Istio

Control plane в Istio отвечает за настройку взаимодействия между workloads внутри mesh-сети. Экземпляры workloads подключаются к нему для получения конфигурации.

В базовом варианте mesh работает с control plane внутри одного кластера — такой кластер называется primary.

Если в mesh-е несколько primary-кластеров, каждый получает конфигурацию от своего API-сервера, что требует синхронизации при внесении изменений — обычно это автоматизируется через CI/CD.

Также возможно использование внешнего control plane, управляющего полностью remote-кластерами. Это изолирует управление от сервисов в mesh-сети и упрощает администрирование. Пример — управляемый Istio от облачного провайдера.

Для высокой доступности рекомендуется разворачивать несколько экземпляров control plane в разных зонах, регионах или кластерах. Это обеспечивает:

• отказоустойчивость — сбой control plane влияет только на связанные с ним кластеры;

• изоляцию конфигурации;

• контролируемое выкатывание изменений;

• ограничение видимости сервисов на уровне кластеров.

Уровни доступности (от меньшего к большему):

1. Один кластер на регион

2. Несколько кластеров на регион

3. Один кластер на зону

4. Несколько кластеров на зону

5. Отдельный control plane на каждый кластер\

Обнаружение конечных точек при использовании нескольких control plane

Плоскость управления Istio обеспечивает маршрутизацию трафика внутри mesh-сети, передавая каждому прокси-экземпляру список конечных точек (endpoints) доступных сервисов. В мультикластерной архитектуре для корректной работы маршрутизации каждый control plane должен иметь информацию о конечных точках всех кластеров в составе mesh-сети.

Для этого необходимо настроить обнаружение конечных точек (endpoint discovery). Администратор генерирует так называемый remote secret — секрет, содержащий учетные данные для доступа к Kubernetes API другого кластера. Этот секрет затем разворачивается во всех primary-кластерах. Control plane, получивший такой секрет, подключается к API-серверу удалённого кластера и получает информацию о сервисах и их конечных точках. Таким образом обеспечивается балансировка трафика между кластерами.

Пример: primary-кластеры с включённым обнаружением конечных точек
Когда несколько primary-кластеров получают доступ к API-серверам друг друга, они могут обнаруживать конечные точки сервисов во всей mesh-сети. Это позволяет Istio осуществлять балансировку нагрузки между кластерами, распределяя запросы по всем доступным endpoint'ам.

По умолчанию, Istio равномерно распределяет трафик между кластерами. Однако в больших системах, охватывающих несколько регионов, имеет смысл включить локальную балансировку (locality-based load balancing), при которой трафик по возможности остаётся в пределах того же региона или зоны, что снижает задержки и стоимость трафика.

Изоляция кластеров

В некоторых случаях кросс-кластерная маршрутизация может быть нежелательной. Пример — blue/green deployment, при котором разные версии системы разворачиваются в отдельных кластерах. В таких ситуациях кластеры должны работать изолированно, как независимые mesh-сети. Для реализации этого поведения возможны два подхода:

1. Не обменивайтесь remote secrets между кластерами. Это обеспечивает полную изоляцию control plane'ов и исключает доступ к endpoint'ам друг друга.

2. Ограничьте маршрутизацию на уровне конфигурации Istio. Используйте VirtualService и DestinationRule, чтобы запретить маршруты между версиями сервисов в разных кластерах.

В обоих случаях кросс-кластерная балансировка нагрузки будет отключена. Внешний трафик при этом можно направлять на нужный кластер с помощью внешнего балансировщика нагрузки (например, DNS + LoadBalancer).

External Istio: альтернативный взгляд

Если разворачивать Istio внутри каждого кластера неудобно или невозможно, можно использовать external Istio.

Суть подхода — в том, что один кластер с control plane управляет сервисами в других кластерах, в которых развернуты только data plane (sidecar-прокси). Это похоже на централизованное управление несколькими "тонкими" кластерами.

Преимущества:

• Централизация управления.

• Минимальные ресурсы на стороне managed кластеров.

• Упрощение обновлений control plane.

Недостатки:

• Потенциально один SPOF.

• Ограниченная изоляция.

• Требует продуманной политики доступа между кластерами.

По установке external istiod можно почитать здесь.

Модели изоляции (Tenancy models)

В Istio тенантом считается группа пользователей, обладающая общими правами доступа к определённому набору развёрнутых рабочих нагрузок (workloads). Тенанты используются для обеспечения уровня изоляции между разными командами.

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

• Безопасность

• Политики

• Ресурсные квоты

• Учёт затрат

• Производительность

Istio поддерживает три типа моделей изоляции:

1. Изоляция на уровне пространств имён

2. Изоляция на уровне кластеров

3. Изоляция на уровне сетей

Изоляция на уровне пространств имён

Один кластер может использоваться несколькими командами, каждая из которых работает в своём пространстве имён (namespace). Вы можете ограничить права команды на развёртывание её рабочих нагрузок только заданным пространством(ами) имён.

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

Изоляция на уровне пространств имён может выходить за пределы одного кластера. В случае использования нескольких кластеров, пространства имён с одинаковыми именами в разных кластерах считаются одним и тем же пространством имён. Например, Service B в пространстве Team-1 кластера West и Service B в пространстве Team-1 кластера East будут рассматриваться Istio как один сервис — его конечные точки (endpoints) объединяются для целей обнаружения сервисов и балансировки нагрузки.

Изоляция на уровне кластеров

Istio поддерживает модель, при которой каждый кластер выступает единицей изоляции. В этом случае каждой команде выделяется отдельный кластер (или группа кластеров) для развёртывания своих рабочих нагрузок. Права на управление кластером, как правило, имеют только члены соответствующей команды. Возможна более тонкая настройка доступа через роли, например:

• Администратор кластера

• Разработчик

Для использования кластерной изоляции в Istio, вы можете настроить для каждого кластера команды отдельную управляющую плоскость (control plane), позволяя каждой команде управлять своей конфигурацией самостоятельно. Альтернативно, Istio поддерживает объединение нескольких кластеров в одного «тенанта» с помощью удалённых кластеров (remote clusters) или нескольких синхронизированных управляющих плоскостей. Подробнее см. в разделе про модели управляющих плоскостей.

Изоляция на уровне сетей

В многосетевом развертывании (multi-mesh) с федерацией mesh-сетей каждая mesh-сеть может быть единицей изоляции.

Поскольку каждая mesh-сеть управляется отдельной командой или организацией, имена сервисов редко уникальны. Например, Service C в пространстве foo кластера Team-1 и Service C в пространстве foo кластера Team-2 не считаются одним и тем же сервисом. Это частая ситуация в Kubernetes, где множество команд используют пространство имён default.

Если у каждой команды своя mesh-сеть, взаимодействие между сетями происходит согласно принципам, описанным в модели множественных mesh-сетей (multiple meshes).

Когда использовать Istio в мультикластере

Использование Istio оправдано, если:

• Необходима единая сервисная mesh-плоскость между геораспределёнными регионами/облаками.

• Важно обеспечить единый контроль политики доступа и безопасности.

• Требуется единый трафик менеджмент (routing, retries, timeouts) для микросервисов в разных кластерах.

Однако если инфраструктура не требует избыточной сетевой связности или безопасность решается другими способами (например, через service mesh в облаке от провайдера), — Istio может быть избыточным решением.

Заключение

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

Рекомендация: начинайте с простого single-network сценария и постепенно усложняйте архитектуру по мере роста зрелости и потребностей вашей платформы.

P.S. Большинство примеров взято с istio.io, но я дополнил их своими рекомендациями, основанными на личном опыте развертывания подобных mesh-сетей.