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

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

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

Все сервисы из 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 мс на запрос.