Модуль istio

Модуль istio реализует Service Mesh (сервис-меш) на основе Istio для централизованного управления сетевым трафиком в Deckhouse Platform (DP). Модуль обеспечивает mTLS (Mutual Transport Layer Security), авторизацию запросов, маршрутизацию трафика, балансировку нагрузки и наблюдаемость взаимодействий между приложениями.

Модуль istio предоставляет возможность одновременной работы нескольких версий Istio. В параметре модуля globalVersion указывается какая версия Istio будет использоваться по-умолчанию для тех неймспейсов, у которых установлен лейбл istio-injection: enabled. В случае, если требуется использовать версию Istio, отличную от версии по-умолчанию, для неймспейсов устанавливается лейбл, соответствующий ревизии Istio, например, istio.io/rev: v1x27.

Модуль работает со следующими кастомными ресурсами API-группы deckhouse.io:

• IngressIstioController — описывает инстанс Istio ingress gateway, обслуживающий выбранный класс шлюза;
• IstioFederation — назначает один или несколько удалённых кластеров доверенными для федерации сервис-меш (доступно в редакциях DP EE, Ultimate);
• IstioMulticluster — назначает один или несколько удалённых кластеров доверенными для multicluster-конфигурации (доступно в редакциях DP EE, Ultimate);
• WaypointInstance — описывает ambient-прокси waypoint, создаваемый компонентом waypoint-controller (доступно в редакциях DP EE, Ultimate).

Модуль также устанавливает и использует кастомные ресурсы Istio (API-группы networking.istio.io, security.istio.io, telemetry.istio.io, extensions.istio.io). Подробнее можно ознакомиться в справочнике кастомных ресурсов Istio.

Если запрошена установка версии Istio с поддержкой оператора, то устанавливаются и используются кастомные ресурсы Sail Operator API-группы sailoperator.io:

• Istio — описывает развёртывание сервис-меш Istio, состоящее из одного или нескольких control plane;
• IstioRevision — представляет одну ревизию control plane Istio.

Набор компонентов модуля и его архитектура зависит от редакции DP. Редакции DP Enterprise Edition (EE) и Ultimate включают возможность реализовать межкластерную федерацию сервис-меш, периодический анализ конфигурации сервис-меш и возможность использования ambient-режима Istio.

Подробнее с настройками модуля можно ознакомиться в разделе документации модуля.

Архитектура модуля

Архитектура модуля istio на уровне 2 модели C4 и его взаимодействие с другими компонентами Deckhouse Platform (DP) изображены на следующих диаграммах:

• Базовая функциональность модуля (control plane, CNI, ingress gateway, Kiali, config-analyzer):

  

• Ambient-режим (на диаграмме отражены только отличия от базового варианта):

  

• Федерация и multicluster-конфигурация (на диаграмме отражены только отличия от базового варианта):

  

Компоненты модуля

Основные компоненты модуля

Модуль состоит из следующих компонентов:

1. Operator-<VERSION> (Deployment) — реализация Sail Operator, управляющий жизненным циклом control plane Istio. Компонент отвечает за установку всех ресурсов, необходимых для работы control plane определенной версии.

   В DP поддерживается работа оператора только для версии Istio 1.25.

   Компонент отслеживает кастомные ресурсы Istio и IstioRevision и на их основе создаёт Deployment istiod-<VERSION>, Service и ConfigMap. Управление вебхуками для валидации и мутации принудительно отключено в операторе, этим занимается контроллер Deckhouse модуля deckhouse при применении Helm-чарта модуля.

   Состоит из одного контейнера:

   • operator — основной контейнер.

2. Istiod-<VERSION> (Deployment) — компонент control plane Istio, выполняющий следующие действия:

   • распространяет конфигурацию маршрутизации сайдкар-прокси по протоколу xDS;
   • выпускает сертификаты для рабочих нагрузок под управлением Istio;
   • выполняет валидацию и мутацию подов пользовательских приложений сайдкар-контейнерами через механику Validating/Mutating Admission Controllers;
   • выполняет валидацию кастомных ресурсов API-групп *.istio.io через механику Validating Admission Controllers.

   Для версии Istio 1.25 (устарела и запланирована к удалению) компонент создаётся и управляется компонентом operator-<VERSION> через кастомные ресурсы Istio и IstioRevision. Для остальных поддерживаемых в DP версий Istio разворачивается напрямую Helm-чартом модуля.

   Состоит из одного контейнера:

   • discovery — основной контейнер.

3. Ingress-gateway-controller-<NAME> (DaemonSet) — контроллер, обрабатывающий входящий меш-трафик приложений. Создаётся контроллером Deckhouse модуля deckhouse для каждого кастомного ресурса IngressIstioController. Плейсхолдер <NAME> определяется именем ресурса IngressIstioController.

   Состоит из одного контейнера:

   • istio-proxy — основной контейнер на основе Open Source-проекта Envoy, обрабатывающий входящий трафик и получающий конфигурацию по протоколу xDS от контроллера istiod.

4. Kiali (Deployment) — веб-интерфейс Kiali для управления и наблюдения за ресурсами Istio и пользовательскими сервисами под управлением Istio, позволяющая следующее:

   • визуализировать связи между сервисами;
   • диагностировать проблемные связи между сервисами;
   • диагностировать состояние Istio control plane.

   Состоит из следующих контейнеров:

   • kiali — основной контейнер;
   • kube-rbac-proxy — сайдкар-контейнер с авторизующим прокси на основе Kubernetes RBAC для организации защищённого доступа к веб-интерфейсу Kiali.

   Аутентификация пользователей веб-интерфейса Kiali выполняется модулем user-authn через отдельный dex-authenticator.

5. Istio-config-analyzer-<VERSION> (Deployment) — компонент, выполняющий периодический анализ конфигурации сервис-меш (istioctl analyze) и экспортирующий результаты анализа в виде метрик Prometheus.

   Компонент создаётся контроллером Deckhouse модуля deckhouse для каждой ревизии Istio, если параметр .settings.configAnalysis.enabled в настройках модуля принимает значение true (по умолчанию — true).

   Состоит из следующих контейнеров:

   • istio-config-analyzer — основной контейнер;
   • kube-rbac-proxy — сайдкар-контейнер с авторизующим прокси на основе Kubernetes RBAC для организации защищённого доступа к метрикам.

Компоненты ambient-режима

В ambient-режиме работы Istio дополнительно создаются следующие компоненты:

1. Istio-cni-node (DaemonSet) — компонент Istio, настраивающий CNI-плагин на каждом узле кластера и выполняющий настройку перехвата трафика подов в ambient-режиме работы Istio.

   Компонент подготавливает исполняемый файл istio-cni и дописывает его как дополнительный плагин в первый обнаруженный CNI-конфиг в каталоге /etc/cni/net.d/ на каждом узле кластера. В стандартной конфигурации DP это файл 05-cilium.conflist, который создаёт CNI-плагин Cilium модуля cni-cilium. При создании каждого пода kubelet (через containerd) вызывает оба CNI-плагина по очереди — сначала cilium, потом istio-cni. Результат работы первого плагина передаётся второму.

   В ambient-режиме работы Istio компонент обрабатывает API-запросы от CNI-плагина istio-cni и настраивает маршрутизацию к компоненту ztunnel.

   Компонент создаётся контроллером Deckhouse, если параметр .settings.dataPlane.trafficRedirectionSetupMode в настройках модуля принимает значение CNIPlugin (по умолчанию — InitContainer).

   Состоит из следующих контейнеров:

   • install-cni — основной контейнер, устанавливающий и настраивающий CNI-плагин на узле;
   • kube-rbac-proxy — сайдкар-контейнер с авторизующим прокси на основе Kubernetes RBAC для организации защищённого доступа к метрикам install-cni.

2. Istio-cni — исполняемый файл, запускаемый компонентом containerd, который получает команду (например, ADD при запуске контейнера и DEL при его удалении) и остальные параметры через переменные окружения в соответствии со спецификацией CNI, а JSON-конфигурацию — через stdin.

   При запуске Istio-cni выполняет следующие действия:

   • обрабатывает входные данные от containerd: JSON-конфигурацию, имя и неймспейс пода;
   • получает информацию о подах и неймспейсах в kube-apiserver;
   • останавливает обработку, если неймспейс находится в exclude_namespaces (параметр конфигурации в ConfigMap cni-config);
   • в ambient-режиме проверяет, включен ли под в ambient через лейблы и, если да, сообщает об этом компоненту istio-cni-node через Unix-сокет;
   • в сайдкар-режиме проверяет отсутствие контейнера istio-init и наличие контейнера istio-proxy в поде, а также аннотации и, если условия выполняются, заходит в сетевое пространство имён (netns) пода и настраивает перехват входящего и исходящего трафика, выполняя команды iptables или nftables.

3. Ztunnel (DaemonSet) — компонент ambient-режима Istio, обеспечивающий L4-прослойку данных (mTLS, авторизацию на уровне L4) без добавления сайдкара к приложению пользователя. Запускается на каждом узле кластера.

   Компонент создаётся контроллером Deckhouse, если параметр .settings.ambient.enabled в настройках модуля принимает значение true (по умолчанию — false).

   Состоит из одного контейнера:

   • istio-proxy — основной контейнер, получающий конфигурацию по протоколу xDS от контроллера istiod.

4. Waypoint-controller (Deployment) — контроллер L7-прослойки ambient-режима. Контроллер управляет кастомным ресурсом WaypointInstance и создаёт или обновляет соответствующий Deployment waypoint-<NAME>.

   Создаётся при тех же условиях, что и ztunnel.

   Состоит из одного контейнера:

   • waypoint-controller — основной контейнер.

5. Waypoint-<NAME> (Deployment) — проксирующий сервис, обрабатывающий L7-трафик (HTTP-маршрутизацию и авторизацию) для сервисов или рабочих нагрузок указанного неймспейса. Создаётся динамически компонентом waypoint-controller для каждого ресурса WaypointInstance.

   Состоит из одного контейнера:

   • istio-proxy — основной контейнер, получающий конфигурацию по протоколу xDS от контроллера istiod.

Компоненты в режиме федерации или мультикластера

В режиме федерации или мультикластера Istio дополнительно создаются следующие компоненты:

1. Metadata-exporter (Deployment) — компонент, предоставляющий публичные метаданные кластера (корневой сертификат CA, публичные ключи, адреса эндпоинтов) удалённым кластерам для настройки межкластерного взаимодействия (федерация или мультикластер).

   Компонент создаётся контроллером Deckhouse, если включён параметр .settings.federation.enabled или параметр .settings.multicluster.enabled в настройках модуля (по умолчанию оба — false).

   Состоит из следующих контейнеров:

   • metadata-exporter — основной контейнер;
   • kube-rbac-proxy — сайдкар-контейнер с авторизующим прокси на основе Kubernetes RBAC для организации защищённого доступа к метрикам.

2. Alliance-healthcheck (Deployment) — компонент, проверяющий доступность меш-соединения с удалёнными кластерами и обновляющий статус кастомных ресурсов IstioFederation и IstioMulticluster.

   Создаётся при тех же условиях, что и metadata-exporter.

   Состоит из одного контейнера:

   • healthcheck — основной контейнер.

3. Ingressgateway (DaemonSet) — компонент, принимающий меш-трафик от удалённых кластеров через mTLS с SNI passthrough. Отдельный от ingress-gateway-controller-<NAME> компонент, обслуживающий исключительно federation- и multicluster-трафик.

   Компонент создаётся контроллером Deckhouse, если:

   • включён параметр .settings.federation.enabled в настройках модуля;
   • включён параметр .settings.multicluster.enabled в настройках модуля и включён параметр .spec.enableIngressGateway в кастомном ресурсе IstioMulticluster.

   Состоит из одного контейнера:

   • istio-proxy — основной контейнер, получающий конфигурацию по протоколу xDS от контроллера istiod.

4. Metrics-exporter (Deployment) — компонент, собирающий данные для метрик multicluster-конфигурации.

   Компонент создаётся контроллером Deckhouse, если включён параметр .settings.multicluster.enabled в настройках модуля.

   Состоит из следующих контейнеров:

   • metrics-exporter — основной контейнер;
   • kube-rbac-proxy — сайдкар-контейнер с авторизующим прокси на основе Kubernetes RBAC для организации защищённого доступа к метрикам.

5. Api-proxy (Deployment) — компонент, предоставляющий удалённым кластерам доступ на чтение к конфигурации сервис-меш и ресурсам приложений этого кластера. Используется istiod удалённого кластера для multicluster service discovery.

   Компонент создаётся контроллером Deckhouse, если включён параметр .settings.multicluster.enabled в настройках модуля.

   Состоит из одного контейнера:

   • api-proxy — основной контейнер.

Компонент, не входящий в состав модуля istio:

• Пользовательское приложение — рабочая нагрузка, созданная пользователем и модифицированная компонентом istiod при мутации пода.

  Состоит из следующих контейнеров:

  • istio-init — опциональный init-контейнер, выполняющий подготовку iptables правил для перехвата трафика приложения. Добавляется, если параметр .settings.dataPlane.trafficRedirectionSetupMode в настройках модуля принимает значение InitContainer. В случае значения CNIPlugin эту функцию выполняет компонент istio-cni-node;
  • istio-proxy — сайдкар-контейнер, обеспечивающий работу пользовательского приложения в меш-сети Istio. Добавляется, если параметр .settings.ambient.enabled в настройках модуля принимает значение false (по умолчанию — false);
  • user-app — набор init-контейнеров и сайдкар-контейнеров пользовательского приложения.

Взаимодействия модуля

Модуль взаимодействует со следующими компонентами:

1. Kube-apiserver:

   • авторизует запросы к метрикам компонентов модуля;
   • управляет кастомными ресурсами Istio, IstioRevision, IngressIstioController, IstioFederation, IstioMulticluster и WaypointInstance;
   • управляет кастомными ресурсами API-групп networking.istio.io, security.istio.io, telemetry.istio.io и extensions.istio.io;
   • создаёт и управляет ресурсами Deployment istiod-<VERSION> и waypoint-<NAME>, DaemonSet ingress-gateway-controller-<NAME>;
   • получает ресурсы Pod, Namespace, Node, Service, Secret, ConfigMap, Job, CronJob, Deployment, DaemonSet, ReplicaSet и StatefulSet.
2. Модуль user-authn — выполняет аутентификацию пользователей веб-интерфейса Kiali.
3. Trickster — запрашивает метрики трафика сервис-меш для веб-интерфейса Kiali.

4. Внешний кластер DP:

   • проверяет доступность меш-соединения между кластерами;
   • получает параметры сервис-меш и приложений пользователя в удалённом кластере.

С модулем взаимодействуют следующие внешние компоненты:

1. Kube-apiserver:

   • валидирует кастомные ресурсы API-групп networking.istio.io, security.istio.io, telemetry.istio.io и extensions.istio.io;
   • мутирует поды для добавления init- и сайдкар-контейнеров.
2. Prometheus-main — собирает метрики всех компонентов модуля.
3. Containerd — запускает исполняемые файлы CNI-плагинов.
4. Балансировщик нагрузки — балансирует входящий трафик к ingress-gateway-controller.
5. Gateway/Ingress-контроллер — пересылает авторизованный запрос пользователя к веб-интерфейсу Kiali. Зависит от выбранного способа публикации ресурсов: с использованием Ingress-контроллера модуля ingress-nginx или с использованием Gateway-контроллера модуля alb.

6. Удалённый кластер DP:

   • запрашивает публичные метаданные кластера;
   • отправляет меш-трафик через mTLS SNI passthrough;
   • читает параметры сервис-меш и приложений пользователя кластера.
7. Пользовательское приложение — получает конфигурацию по протоколу xDS от контроллера istiod.

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

• Документация модуля alb
• Документация модуля cni-cilium
• Документация модуля deckhouse
• Документация модуля ingress-nginx
• Документация модуля istio
• Документация модуля user-authn