Компоненты кластера делятся на две категории:
- Control plane — управляющие и обслуживающие сервисы. Под control plane обычно подразумевают поды istiod.
- Data plane — прикладная часть Istio. Представляет собой контейнеры sidecar-proxy.
Все сервисы из Data Plane группируются в сервис-меш (service mesh). Его характеристики:
- Общее пространство имен для генерации идентификатора сервиса в формате
<TrustDomain>/ns/<Namespace>/sa/<ServiceAccount>
. Каждый сервис-меш имеет идентификатор TrustDomain, который в нашем случае совпадает с доменом кластера. Например:mycluster.local/ns/myns/sa/myapp
. - Аутентификация сервисов внутри одного сервис-меш с помощью доверенных корневых сертификатов.
Элементы control plane:
- istiod — ключевой сервис, обеспечивающий решение следующих задач:
- Непрерывная связь с API Kubernetes и сбор информации о прикладных сервисах.
- Обработка и валидация с помощью механизма Kubernetes Validating Webhook всех кастомных ресурсов, которые связаны с Istio.
- Компоновка конфигурации для каждого sidecar-proxy индивидуально:
- генерация правил авторизации, маршрутизации, балансировки и пр.;
- распространение информации о других прикладных сервисах в кластере;
- выпуск индивидуальных клиентских сертификатов для организации схемы Mutual TLS. Эти сертификаты не связаны с сертификатами, которые использует и контролирует сам Kubernetes для своих служебных нужд.
- Автоматическая подстройка манифестов, определяющих прикладные поды через механизм Kubernetes Mutating Webhook:
- внедрение дополнительного служебного контейнера sidecar-proxy;
- внедрение дополнительного init-контейнера для адаптации сетевой подсистемы (настройка DNAT для перехвата прикладного трафика);
- перенаправление readiness- и liveness-проб через sidecar-proxy.
- operator — компонент, отвечающий за установку всех ресурсов, необходимых для работы control plane определенной версии.
- kiali — панель управления и наблюдения за ресурсами Istio и пользовательскими сервисами под управлением Istio:
- визуализация связей между сервисами.
- диагностика проблемных связей.
- диагностика состояния control plane.
С включенным Istio поведение Ingress-контроллера изменяется следующим образом:
- К подам контроллера добавляется sidecar-proxy, который обслуживает только трафик от контроллера в сторону прикладных сервисов (параметр IngressNginxController
enableIstioSidecar
у ресурса IngressNginxController). - Сервисы, не находящиеся под управлением Istio, продолжают работать в прежнем режиме, без перехвата запросов сайдкаром контроллера.
- Запросы к сервисам под управлением Istio перехватываются сайдкаром и обрабатываются в соответствии с правилами Istio (подробнее о том, как активировать Istio для приложения).
Контроллер istiod и каждый контейнер sidecar-proxy экспортируют собственные метрики, которые собирает кластерный Prometheus.
Накладные расходы
Внедрение 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 ГБ RAM.
Data plane
На потребление ресурсов data plane (istio-сайдкары) влияет множество факторов:
- количество соединений,
- интенсивность запросов,
- размер запросов и ответов,
- протокол (HTTP/TCP),
- количество ядер CPU,
- сложность конфигурации сервис-меш.
Примерная оценка накладных расходов для экземпляра istio-сайдкара — 0.5 vCPU на 1000 запросов/сек и 50 МБ RAM.
Istio-сайдкары также вносят задержку в сетевые запросы — примерно 2.5 мс на запрос.