Модуль istio

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

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

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

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

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

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

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

Архитектура кластера с включенным 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 и сбор информации о прикладных сервисах.
  • Обработка и валидация с помощью механизма Kubernetes Validating Webhook всех Custom Resources, которые связаны с Istio.
  • Компоновка конфигурации для каждого сайдкар-прокси индивидуально:
    • генерация правил авторизации, маршрутизации, балансировки и прочих;
    • распространение информации о других прикладных сервисах в кластере;
    • выпуск индивидуальных клиентских сертификатов для организации схемы Mutual TLS. Эти сертификаты не связаны с сертификатами, которые использует и контролирует сам Kubernetes для своих служебных нужд.
  • Автоматическая подстройка манифестов, определяющих прикладные поды через механизм Kubernetes Mutating Webhook:
    • внедрение дополнительного служебного контейнера сайдкар-прокси;
    • внедрение дополнительного init-контейнера для адаптации сетевой подсистемы (настройка DNAT для перехвата прикладного трафика);
    • перенаправление readiness- и liveness-проб через сайдкар-прокси.
• operator — компонент, отвечающий за установку всех ресурсов, необходимых для работы control plane определенной версии.
• kiali — панель управления и наблюдения за ресурсами Istio и пользовательскими сервисами под управлением Istio, позволяющая следующее:
  • Визуализировать связи между сервисами.
  • Диагностировать проблемные связи между сервисами.
  • Диагностировать состояние control plane.

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

• К подам контроллера добавляется сайдкар-прокси, который обслуживает только трафик от контроллера в сторону прикладных сервисов (параметр IngressNginxController 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, который является значением по умолчанию.

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

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

  • При анализе HTTP- и HTTPS-запросов (в терминологии Istio) идентифицировать их и принять решение о дальнейшей маршрутизации, запрещении или разрешении возможно по заголовкам.
  • При анализе TCP-запросов (в терминологии Istio) идентифицировать их и принять решение о дальнейшей маршрутизации, запрещении или разрешении возможно только по IP-адресу назначения и номеру порта.

    Если IP-адреса сервисов или подов пересекутся между кластерами, то под маршрутизирующие, запрещающие или разрешающие правила istio могут попасть запросы других подов иных кластеров. Пересечение подсетей сервисов и подов жестко запрещено в single-network режиме, и допустимо, но не рекомендуется в режиме multi-networks (источник — документация Istio).

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

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

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

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

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

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

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

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

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

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

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

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

• Подсети сервисов и подов в параметрах serviceSubnetCIDR и podSubnetCIDR ресурса ClusterConfiguration должны быть уникальными для каждого кластера.

  • При анализе HTTP- и HTTPS-запросов (в терминологии Istio) идентифицировать их и принять решение о дальнейшей маршрутизации, запрещении или разрешении возможно по заголовкам.
  • При анализе TCP-запросов (в терминологии Istio) идентифицировать их и принять решение о дальнейшей маршрутизации, запрещении или разрешении возможно только по IP-адресу назначения и номеру порта.

    Если IP-адреса сервисов или подов пересекутся между кластерами, то под маршрутизирующие, запрещающие или разрешающие правила Istio могут попасть запросы других подов иных кластеров. Пересечение подсетей сервисов и подов не рекомендуется (источник — документация Istio).

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

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

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

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

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

• В кластер добавляется прокси для публикации доступа к API-серверу посредством стандартного Ingress-ресурса:
  • Доступ через данный публичный адрес ограничен авторизацией на основе Bearer-токенов, подписанных доверенными ключами. Обмен доверенными публичными ключами происходит автоматически средствами Deckhouse при взаимной настройке мультикластера.
  • Сам прокси имеет 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 (как установить…):

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

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

Внедрение 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.

• 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.