Федерация средствами Istio (Service Mesh)

Доступно только в DKP Enterprise Edition (EE) и DKP Certified Security Edition Pro (CSE Pro).

Требования к кластерам

  • Каждый кластер должен иметь уникальное значение параметра clusterDomain в ресурсе ClusterConfiguration. Обратите внимание, что ни один из кластеров не должен иметь домен cluster.local, который является значением по умолчанию.

    Значение cluster.local использовать нельзя, так как это зарезервированный псевдоним для домена локального кластера. Если в AuthorizationPolicy указать cluster.local как principals, правило будет применяться только к локальному кластеру, даже если в Service mesh существует кластер, у которого clusterDomain явно определен как cluster.local (Подробнее — в документации Istio).

  • Требования к уникальности подсетей сервисов и подов в параметрах serviceSubnetCIDR и podSubnetCIDR ресурса ClusterConfiguration при работе кластеров в федерации отсутствуют.

    При анализе трафика Istio использует:

    • для HTTP/HTTPS-запросов — заголовки;
    • для TCP-запросов — IP-адрес назначения и порт.

    Istio работает в режиме multi-network — поды разных кластеров взаимодействуют друг с другом только через Istio ingress gateway. Прямое взаимодействие между подами разных кластеров не поддерживается.

Общие принципы федерации

  • Федерация требует взаимного доверия между кластерами. Для этого необходимо обменяться корневыми сертификатами: кластер A должен доверять кластеру B и наоборот.
  • Для настройки межкластерного доступа к сервисам необходимо обменяться информацией о публичных сервисах. Чтобы опубликовать сервис bar из кластера Б в кластере А, необходимо в кластере А создать ресурс ServiceEntry, который описывает публичный адрес ingress-gateway кластера Б.

Включение федерации: создаваемые сервисы

При включении федерации (установка параметра модуля istio.federation.enabled = true) в кластер добавляются:

  • Сервис ingressgateway, который проксирует mTLS-трафик извне к прикладным сервисам.
  • Сервис экспорта метаданных:
    • корневой сертификат Istio (доступен без аутентификации);
    • список публичных сервисов в кластере (доступен только для аутентифицированных запросов из соседних кластеров);
    • список публичных адресов сервиса ingressgateway (доступен только для аутентифицированных запросов из соседних кластеров).

Настройка федерации

Для настройки федерации необходимо:

  • В каждом кластере создать набор ресурсов IstioFederation для описания других кластеров.
    • После успешного автосогласования между кластерами в ресурсе IstioFederation будут записаны необходимые служебные данные в status.metadataCache.public и status.metadataCache.private.
  • Каждый ресурс (Service), который считается публичным в рамках федерации, пометить лейблом federation.istio.deckhouse.io/public-service: "".
    • В остальных кластерах из состава федерации, для каждого ресурса Service создадутся соответствующие ServiceEntry, указывающие на ingressgateway исходного кластера.

Важно. Убедитесь, что поле name в разделе .spec.ports ресурса Service заполнено для каждого порта, иначе могут быть проблемы в работе федерации.

Пример устройства федерации из двух кластеров

Для настройки федерации средствами Istio используйте кастомный ресурс IstioFederation.

Кластер A:

apiVersion: deckhouse.io/v1alpha1
kind: IstioFederation
metadata:
  name: cluster-a
spec:
  metadataEndpoint: https://istio.k8s-a.example.com/metadata/
  trustDomain: cluster-a.local

Кластер B:

apiVersion: deckhouse.io/v1alpha1
kind: IstioFederation
metadata:
  name: cluster-b
spec:
  metadataEndpoint: https://istio.k8s-b.example.com/metadata/
  trustDomain: cluster-b.local

Дополнительные ресурсы