Модуль istio

Таблица совместимости поддерживаемых версий

В таблице ниже указаны версии Istio и их статус поддержки в Deckhouse Platform (DP).

Задачи, которые решает Istio

Istio — фреймворк централизованного управления сетевым трафиком, реализующий подход Service Mesh.

Istio решает для приложений следующие задачи:

• Использование Mutual TLS.
• Авторизация доступа между сервисами.
• Маршрутизация запросов.
• Управление балансировкой запросов между эндпоинтами сервиса.
• Повышение Observability.
• Организация мульти-ЦОД кластера за счет объединения кластеров в единый Service Mesh (мультикластер).
• Объединение разрозненных кластеров в федерацию с возможностью предоставлять стандартный (в понимании Service Mesh) доступ к избранным сервисам.
• Подключение к сети без сайдкаров в каждом поде с помощью режима ambient.

Также доступно видео об архитектуре Istio и накладных расходах.

Mutual TLS

Это основной метод взаимной аутентификации сервисов. Принцип основан на том, что для всех исходящих запросов проверяется сертификат сервера, а для входящих - клиентский сертификат. После проверки сайдкар-прокси получает возможность идентифицировать удаленный узел и использовать эти данные для аутентификации или для прикладных целей.

Каждый сервис получает собственный идентификатор в формате <TrustDomain>/ns/<Namespace>/sa/<ServiceAccount>, где TrustDomain в нашем случае — это домен кластера. Каждому сервису можно выделять собственный ServiceAccount или использовать стандартный «default». Полученный идентификатор сервиса можно использовать как в правилах авторизации, так и в прикладных целях. Именно этот идентификатор используется в качестве удостоверяемого имени в TLS-сертификатах.

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

Авторизация

Ресурс AuthorizationPolicy отвечает за управление авторизацией. После создания этого ресурса для сервиса для определения судьбы запроса используется следующий алгоритм:

• если запрос попадает под политику DENY — запретить запрос;
• если для данного сервиса нет политик ALLOW — разрешить запрос;
• если запрос попадает под политику ALLOW — разрешить запрос;
• все остальные запросы — запретить.

Иными словами, если явно что-то запретить, работает только запрет. Если же что-то явно разрешить, будут разрешены только явно одобренные запросы (запреты при этом имеют приоритет).

Для написания правил авторизации доступны следующие аргументы:

• идентификаторы сервисов и wildcard на их основе (mycluster.local/ns/myns/sa/myapp или mycluster.local/*);
• неймспейсы;
• диапазоны IP;
• HTTP-заголовки;
• JWT-токены из прикладных запросов.

Маршрутизация запросов

Основной ресурс для управления маршрутизацией — VirtualService, он позволяет переопределять судьбу HTTP- или TCP-запроса. Доступные аргументы для принятия решения о маршрутизации:

• Host и любые другие заголовки;
• URI;
• метод (GET, POST и пр.);
• лейблы пода или неймспейса источника запросов;
• dst-IP или dst-порт для не-HTTP-запросов.

Управление балансировкой запросов между эндпоинтами сервиса

Основной ресурс для управления балансировкой запросов — DestinationRule, он позволяет настроить нюансы исходящих из подов запросов:

• лимиты/таймауты для TCP;
• алгоритмы балансировки между эндпоинтами;
• правила определения проблем на стороне эндпоинта для выведения его из балансировки;
• нюансы шифрования.

Observability

Трассировка

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

• Если запрос инициирует на сервисе вторичные запросы, для них необходимо наследовать трассировочные заголовки средствами приложения.
• Jaeger для сбора и отображения трейсов потребуется устанавливать самостоятельно.

Grafana

В стандартной комплектации с модулем предоставлены дополнительные дашборды:

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

Kiali

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

Метрики mesh и access log (Telemetry API)

Дашборды Grafana для workload и количественные данные в Kiali опираются на стандартные метрики istio_*, которые Prometheus забирает с istio-proxy. Начиная с Istio 1.21+, они настраиваются через Telemetry API и связанные провайдеры по умолчанию в meshConfig, а не только через прежний блок telemetry.v2.

В DP параметр — telemetryAPI.enabled: false оставляет полностью включённым telemetry.v2, true переводит mesh на режим Telemetry API (defaultProviders, управляемые модулем Telemetry CR и формат строки доступа из dataPlane.accessLog). Подробнее с примерами — в разделе Telemetry API: метрики mesh, трассировка и журналы доступа.

Архитектура кластера с включённым Istio

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

• control plane — управляющие и обслуживающие сервисы. Под control plane обычно подразумевают поды istiod.
• data plane — прикладная часть Istio. Представляет собой контейнеры сайдкар-прокси.

Все сервисы из data plane группируются в mesh. Его характеристики:

• Общий неймспейс для генерации идентификатора сервиса в формате <TrustDomain>/ns/<Namespace>/sa/<ServiceAccount>. Каждый mesh имеет идентификатор TrustDomain, который в нашем случае совпадает с доменом кластера. Например: mycluster.local/ns/myns/sa/myapp.
• Сервисы в рамках одного mesh имеют возможность аутентифицировать друг друга с помощью доверенных корневых сертификатов.

Элементы control plane:

• istiod — ключевой сервис, обеспечивающий решение следующих задач:
  • Непрерывная связь с API Kubernetes и сбор информации о прикладных сервисах.
  • Обработка и валидация с помощью механизма validating-вебхуков Kubernetes всех Custom Resources, которые связаны с Istio.
  • Компоновка конфигурации для каждого сайдкар-прокси индивидуально:
    • генерация правил авторизации, маршрутизации, балансировки и прочих;
    • распространение информации о других прикладных сервисах в кластере;
    • выпуск индивидуальных клиентских сертификатов для организации схемы Mutual TLS. Эти сертификаты не связаны с сертификатами, которые использует и контролирует сам Kubernetes для своих служебных нужд.
  • Автоматическая подстройка манифестов, определяющих прикладные поды через механизм mutating-вебхуков Kubernetes:
    • внедрение дополнительного служебного контейнера сайдкар-прокси;
    • внедрение дополнительного init-контейнера для адаптации сетевой подсистемы (настройка DNAT для перехвата прикладного трафика);
    • перенаправление readiness- и liveness-проб через сайдкар-прокси.
• operator — компонент, отвечающий за установку всех ресурсов, необходимых для работы control plane определенной версии.
• kiali — панель управления и наблюдения за ресурсами Istio и пользовательскими сервисами под управлением Istio, позволяющая следующее:
  • Визуализировать связи между сервисами.
  • Диагностировать проблемные связи между сервисами.
  • Диагностировать состояние control plane.

Для приема пользовательского трафика необходима доработка Ingress-контроллера:

• К подам контроллера добавляется сайдкар-прокси, который обслуживает только трафик от контроллера в сторону прикладных сервисов (параметр enableIstioSidecar ресурса IngressNginxController).
• Сервисы не под управлением Istio продолжают работать как раньше, запросы в их сторону не перехватываются сайдкаром контроллера.
• Запросы в сторону сервисов под управлением Istio перехватываются сайдкаром и обрабатываются в соответствии с правилами Istio (подробнее о том, как активировать Istio для приложения).

Контроллер istiod и каждый контейнер сайдкар-proxy экспортируют собственные метрики, которые собирает кластерный Prometheus.

Архитектура прикладного сервиса с включённым Istio

Особенности

• Каждый под сервиса получает дополнительный контейнер — сайдкар-прокси. Технически этот контейнер содержит два приложения:
  • Envoy — проксирует прикладной трафик и реализует все функции, которые предоставляет Istio, включая маршрутизацию, аутентификацию, авторизацию и пр.
  • pilot-agent — часть Istio, отвечает за поддержание конфигурации Envoy в актуальном состоянии, а также содержит в себе кеширующий DNS-сервер.
• В каждом поде настраивается DNAT входящих и исходящих прикладных запросов в сайдкар-прокси. Делается это с помощью дополнительного init-контейнера. Таким образом, трафик будет перехватываться прозрачно для приложений.
• Так как входящий прикладной трафик перенаправляется в сайдкар-прокси, readiness/liveness-трафика это тоже касается. Подсистема Kubernetes, которая за это отвечает, не рассчитана на формирование проб в формате Mutual TLS. Для адаптации все существующие пробы автоматически перенастраиваются на специальный порт в сайдкар-прокси, который перенаправляет трафик на приложение в неизменном виде.
• Для приема запросов извне кластера необходимо использовать подготовленный Ingress-контроллер:
  • Поды контроллера аналогично имеют дополнительный контейнер сайдкар-прокси.
  • В отличие от подов приложения, сайдкар-прокси Ingress-контроллера перехватывает только трафик от контроллера к сервисам. Входящий трафик от пользователей обрабатывает непосредственно сам контроллер.
• Ресурсы типа Ingress требуют минимальной доработки в виде добавления аннотаций:
  • nginx.ingress.kubernetes.io/service-upstream: "true" — Ingress-контроллер в качестве upstream будет использовать ClusterIP сервиса вместо адресов подов. Балансировкой трафика между подами теперь занимается сайдкар-прокси. Используйте эту опцию, только если у вашего сервиса есть ClusterIP.
  • nginx.ingress.kubernetes.io/upstream-vhost: "myservice.myns.svc" — сайдкар-прокси Ingress-контроллера принимает решения о маршрутизации на основе заголовка Host. Без данной аннотации контроллер оставит заголовок с адресом сайта, например Host: example.com.
• Ресурсы типа Service не требуют адаптации и продолжают выполнять свою функцию. Приложениям все так же доступны адреса сервисов вида servicename, servicename.myns.svc и пр.
• DNS-запросы изнутри подов прозрачно перенаправляются на обработку в сайдкар-прокси:
  • Требуется для разыменования DNS-имен сервисов из соседних кластеров.

Жизненный цикл пользовательского запроса

Приложение с выключенным Istio

Приложение с включённым Istio

Как активировать Istio для приложения

Основная цель активации — добавить сайдкар-контейнер к подам приложения, после чего Istio сможет управлять трафиком.

Рекомендованный способ добавления сайдкаров — использовать sidecar-injector. Istio умеет «подселять» к вашим подам сайдкар-контейнер с помощью механизма Admission Webhook. Настраивается с помощью лейблов и аннотаций:

• Лейбл к неймспейсу — обозначает ваш неймспейс для компонента sidecar-injector. После применения лейбла к новым подам будут добавлены сайдкар-контейнеры:
  • istio-injection=enabled — использует глобальную версию Istio (spec.settings.globalVersion в ModuleConfig);
  • istio.io/rev=v1x21 — использует конкретную версию Istio для этого неймспейса;
  • istio.io/rev=default — использует глобальную версию Istio (spec.settings.globalVersion в ModuleConfig).
• Аннотация к поду sidecar.istio.io/inject ("true" или "false") позволяет локально переопределить политику sidecarInjectorPolicy. Эти аннотации работают только в неймспейсах, обозначенных лейблами из списка выше.

Также существует возможность добавить сайдкар к индивидуальному поду в неймспейсе без установленных лейблов istio-injection=enabled или istio.io/rev=vXxYZ путем установки лейбла sidecar.istio.io/inject=true.

Istio-proxy, работающий как сайдкар-контейнер, потребляет ресурсы и добавляет следующие накладные расходы:

• Любой входящий запрос принудительно перехватывается прокси-сервером Envoy. Он анализирует его и отправляет дальше, используя DNAT-правила, создавая новое соединение. Со стороны получателя происходит то же самое: трафик сначала попадает в «принимающий» Envoy, а только потом — в само приложение.
• Каждый Envoy хранит информацию обо всех сервисах в кластере, поэтому масштабирование кластера ведёт к линейному росту потребления RAM в Envoy из-за хранения полной карты сервисов. С помощью кастомного ресурса Sidecar происходит фильтрация конфигурации и передача в Envoy только необходимого минимума данных.

Также важно подготовить Ingress-контроллер и Ingress-ресурсы приложения:

• Включите enableIstioSidecar у ресурса IngressNginxController.
• Добавьте аннотации на Ingress-ресурсы приложения:
  • nginx.ingress.kubernetes.io/service-upstream: "true" — Ingress-контроллер в качестве upstream использует ClusterIP сервиса вместо адресов подов. Балансировкой трафика между подами теперь занимается сайдкар-прокси. Используйте эту опцию, только если у вашего сервиса есть ClusterIP;
  • nginx.ingress.kubernetes.io/upstream-vhost: "myservice.myns.svc" — сайдкар-прокси Ingress-контроллера принимает решения о маршрутизации на основе заголовка Host. Без этой аннотации контроллер оставит заголовок с адресом сайта, например Host: example.com.

Федерация и мультикластер

Поддерживаются две схемы межкластерного взаимодействия:

• федерация;
• мультикластер.

Принципиальные отличия:

• Федерация объединяет суверенные кластеры:
  • у каждого кластера собственный неймспейс (для неймспейсов, сервисов и пр.);
  • доступ к отдельным сервисам между кластерами явно обозначен.
• Мультикластер объединяет созависимые кластеры:
  • неймспейс у кластеров общий — каждый сервис доступен для соседних кластеров так, словно он работает на локальном кластере (если это не запрещают правила авторизации).

Федерация

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

• У каждого кластера должен быть уникальный домен в параметре clusterDomain ресурса ClusterConfiguration. Ни один из кластеров не должен использовать домен cluster.local, который является значением по умолчанию.
• Уникальность подсетей сервисов и подов в параметрах serviceSubnetCIDR и podSubnetCIDR ресурса ClusterConfiguration при работе в федерации не требуется.

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

• HTTP- и HTTPS-запросы — идентификация и решение о маршрутизации или блокировке принимается по заголовкам;
• TCP-запросы — решение принимается только по IP-адресу назначения и номеру порта.

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

• Федерация требует установления взаимного доверия между кластерами. Соответственно, для установления федерации нужно в кластере A сделать кластер Б доверенным и, аналогично, в кластере Б сделать кластер А доверенным. Это достигается взаимным обменом корневыми сертификатами.
• Для прикладной эксплуатации федерации необходимо также обменяться информацией о публичных сервисах. Это можно сделать с помощью ресурса ServiceEntry. ServiceEntry описывает публичный адрес ingressgateway кластера Б, чтобы сервисы кластера A могли обращаться к сервису bar в кластере Б.

Включение федерации

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

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

Управление федерацией

Для построения федерации необходимо сделать следующее:

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

Пример публичного сервиса:

apiVersion: v1
kind: Service
metadata:
  name: reviews
  namespace: bookinfo
  labels:
    federation.istio.deckhouse.io/public-service: ""
spec:
  selector:
    app: reviews
  ports:
  - name: http
    port: 9080
    targetPort: 9080

Диагностика публикации сервисов в федерации:

Проверьте, какие сервисы помечены как публичные в локальном кластере:

d8 k get svc -A -l federation.istio.deckhouse.io/public-service=

Проверьте состояние обмена метаданными с удалёнными кластерами:

d8 k get istiofederation
d8 k get istiofederation <name> -o jsonpath='{.status.conditions}'

Проверьте, что удалённый кластер передал список своих публичных сервисов:

d8 k get istiofederation <name> -o jsonpath='{.status.metadataCache.private.publicServices}'

Проверьте, что по полученным метаданным созданы маршруты в локальном кластере:

d8 k -n d8-istio get serviceentry,destinationrule

В status.conditions ресурса IstioFederation должны перейти в True условия PublicMetadataExchangeReady, PrivateMetadataExchangeReady и DataplaneConnectionReady. Если обмен метаданными не работает, проверьте алерт D8IstioFederationMetadataEndpointDoesntWork и доступность параметра spec.metadataEndpoint удалённого кластера.

Мультикластер

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

• Домены кластеров в параметре clusterDomain ресурса ClusterConfiguration должны быть одинаковыми для всех участников мультикластера. По умолчанию значение параметра — cluster.local.
• Подсети сервисов и подов в параметрах serviceSubnetCIDR и podSubnetCIDR ресурса ClusterConfiguration должны быть уникальными для каждого кластера.

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

• HTTP- и HTTPS-запросы — идентификация и решение о маршрутизации или блокировке принимается по заголовкам;
• TCP-запросы — решение принимается только по IP-адресу назначения и номеру порта.

Общие принципы

• Мультикластер требует установления взаимного доверия между кластерами. Соответственно, для построения мультикластера нужно в кластере A сделать кластер Б доверенным и в кластере Б сделать кластер А доверенным. Технически это достигается взаимным обменом корневыми сертификатами.
• Для сбора информации о соседних сервисах Istio подключается напрямую к API-серверу соседнего кластера. Данный модуль DP берет на себя организацию соответствующего канала связи.

Включение мультикластера

При включении мультикластера (параметр модуля istio.multicluster.enabled = true) происходит следующее:

• В кластер добавляется прокси для публикации доступа к API-серверу посредством стандартного Ingress-ресурса:
  • Доступ через данный публичный адрес ограничен авторизацией на основе Bearer-токенов, подписанных доверенными ключами. Обмен доверенными публичными ключами происходит автоматически средствами DP при взаимной настройке мультикластера.
  • Сам прокси имеет read-only-доступ к ограниченному набору ресурсов.
• В кластер добавляется сервис, который экспортирует метаданные кластера наружу:
  • Корневой сертификат Istio (доступен без аутентификации).
  • Публичный адрес, через который доступен API-сервер (доступен только для аутентифицированных запросов из соседних кластеров).
  • Список публичных адресов сервиса ingressgateway (доступен только для аутентифицированных запросов из соседних кластеров).
  • Публичные ключи сервера для аутентификации запросов к API-серверу и закрытым метаданным.

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

Для сборки мультикластера необходимо в каждом кластере создать набор ресурсов IstioMulticluster, которые описывают все остальные кластеры.

В случае проблем при работе с мультикластером необходимо проверить в каждом кластере:

1. Состояние ресурсов IstioMultiCluster. Для этого выполните команду d8 k describe istiomulticluster cluster-name. Важно, чтобы в статусе ресурса был указан Root CA и в поле Public Last Fetch Timestamp была свежий лейбл времени.
2. В поле Ingress Gateways ресурса IstioMultiCluster должен быть указан корректный адрес (IP или FQDN) IngressGateway второго кластера.

3. С помощью утилиты istioctl из debug-контейнера DP убедитесь, что удалённые кластеры находятся в состоянии synced, и для них указан экземпляр istiod (подробнее — в подразделе «Диагностика Istio с помощью istioctl»):

   istioctl remote-clusters -i d8-istio
   

   Пример вывода:

   NAME          SECRET                                     STATUS     ISTIOD
   cluster-b     d8-istio/istio-remote-secret-cluster-b     synced     istiod-v1x21-5c57d85b54-k8pl7
   

Ambient mesh

Помимо классического режима с сайдкарами, Istio может запускать data plane в режиме ambient. В этом режиме функциональность сети разделена на два уровня, и в поды приложений больше не добавляется сайдкар-контейнер istio-proxy:

• компонент уровня узла (ztunnel) отвечает за функциональность уровня L4 (Mutual TLS, идентификация, базовая авторизация) для всех рабочих нагрузок сети на узле;
• опциональный компонент уровня неймспейса (прокси waypoint) отвечает за функциональность уровня L7 (маршрутизация HTTP, авторизация L7, телеметрия).

По сравнению с режимом сайдкаров, режим ambient снижает накладные расходы на каждый под (сайдкар-контейнер не добавляется в каждый под) и позволяет внедрять возможности сети постепенно — сначала L4 через ztunnel, а затем L7 только для тех неймспейсов, которым это нужно.

Компоненты

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

• ztunnel — DaemonSet, который запускает один под на узел и прозрачно туннелирует трафик рабочих нагрузок, подключенных к ambient mesh на этом узле, по протоколу HTTP-Based Overlay Network Encapsulation (HBONE) с использованием Mutual TLS. Он обеспечивает функциональность L4 без сайдкара;
• прокси waypoint — опциональный прокси уровня L7, разворачиваемый на неймспейс (или для части его рабочих нагрузок или сервисов). В DP он создается с помощью кастомного ресурса WaypointInstance, который является абстракцией DP над встроенным механизмом создания waypoint в Istio. Он добавляет декларативное управление количеством реплик (Static/HPA), ресурсами (Static/VPA), размещением по узлам и бюджетами прерываний (PDB) для каждого экземпляра waypoint.

Требования

Для использования режима ambient выполните следующие требования:

• Используйте Istio 1.25 или более новой версии (режим ambient доступен начиная с Istio 1.25).
• Для параметра dataPlane.trafficRedirectionSetupMode установите значение CNIPlugin. Режим ambient требует настройки перенаправления трафика с помощью CNI-плагина.
• Включите режим ambient с помощью параметра модуля ambient.enabled.

Ограничения ambient mesh

Режим ambient совместим с федерацией и мультикластером на уровне кластера: его можно включить в кластере, который является участником федерации или мультикластера, — межкластерное взаимодействие продолжит работать.

Ограничение действует на уровне отдельных рабочих нагрузок: федерация и мультикластер работают только с рабочими нагрузками в режиме сайдкаров. Межкластерный трафик до рабочей нагрузки, подключенной к ambient mesh, и от неё не работает ни в одном из направлений.

Оба режима data plane могут одновременно использоваться в одном кластере, поэтому межкластерные рабочие нагрузки можно оставить в режиме сайдкаров, а остальные — подключить к ambient mesh.

Подключение рабочих нагрузок

Модуль устанавливает и запускает компоненты инфраструктуры ambient (ztunnel и контроллер waypoint для ресурсов WaypointInstance), но не подключает рабочие нагрузки автоматически.

Чтобы подключить рабочие нагрузки, используйте стандартные лейблы Istio:

1. Добавьте лейбл istio.io/dataplane-mode=ambient на неймспейс (или под), чтобы захватывать его трафик с помощью ztunnel (L4).
2. Создайте ресурс WaypointInstance в неймспейсе, а затем направьте рабочие нагрузки или сервисы на него, назначив им лейбл istio.io/use-waypoint, чтобы включить возможности L7.

Пошаговая настройка описана в разделе «Примеры».

Аутентификация

По умолчанию аутентификацию для Kiali обеспечивает модуль user-authn. Также можно настроить аутентификацию через externalAuthentication. Если оба варианта отключены, модуль использует базовую аутентификацию со сгенерированным паролем.

Чтобы посмотреть сгенерированный пароль, выполните:

d8 k -n d8-system exec svc/deckhouse-leader -c deckhouse -- deckhouse-controller module values istio -o json | jq '.istio.internal.auth.password'

Чтобы сгенерировать новый пароль, удалите секрет:

d8 k -n d8-istio delete secret/kiali-basic-auth

Накладные расходы

Внедрение Istio повлечёт за собой дополнительные расходы ресурсов, как для control-plane (контроллер istiod), так и для data-plane (istio-сайдкары приложений).

control-plane

Контроллер istiod непрерывно наблюдает за конфигурацией кластера, компонует настройки для istio-сайдкаров data-plane и рассылает их по сети. Соответственно, чем больше приложений и их экземпляров, чем больше сервисов и чем чаще эта конфигурация меняется, тем больше требуется вычислительных ресурсов и больше нагрузка на сеть. При этом, поддерживается два подхода для снижения нагрузки на экземпляры контроллеров:

• горизонтальное масштабирование (настройка модуля controlPlane.replicasManagement) — чем больше экземпляров контроллеров, тем меньше экземпляров istio-сайдкаров обслуживать каждому из них и тем меньше нагрузка на CPU и на сеть.
• сегментация data-plane с помощью ресурса Sidecar (рекомендуемый подход) — чем меньше область видимости у отдельного istio-сайдкара, тем меньше требуется обновлять данных в data-plane и тем меньше нагрузка на CPU и на сеть.

Примерная оценка накладных расходов для экземпляра control-plane, который обслуживает 1000 сервисов и 2000 istio-сайдкаров — 1 vCPU и 1.5 GB RAM.

data-plane

На потребление ресурсов data-plane (istio-сайдкары) влияет множество факторов:

• количество соединений,
• интенсивность запросов,
• размер запросов и ответов,
• протокол (HTTP/TCP),
• количество ядер CPU,
• сложность конфигурации Service Mesh.

Примерная оценка накладных расходов для экземпляра istio-сайдкара — 0.5 vCPU на 1000 запросов/сек и 50 MB RAM.

istio-сайдкары также вносят задержку в сетевые запросы — примерно 2.5мс на запрос.

Внешние компоненты

Список стороннего программного обеспечения, используемого в модуле istio (информация представлена на английском языке):

• Istio 1.21.6

  License: Apache License 2.0

  An open platform to connect, manage, and secure microservices.

• Istio 1.25.2

  License: Apache License 2.0

  An open platform to connect, manage, and secure microservices.

• Istio 1.27.9

  License: Apache License 2.0

  An open platform to connect, manage, and secure microservices.

• Kiali 1.81.0

  License: Apache License 2.0

  Visualisation tool for the istio service mesh topology, and features like circuit breakers or request rates.

• Kiali 2.7.1

  License: Apache License 2.0

  Visualisation tool for the istio service mesh topology, and features like circuit breakers or request rates.

• Kiali 2.12.0

  License: Apache License 2.0

  Visualisation tool for the istio service mesh topology, and features like circuit breakers or request rates.