#Ограничение области действия Service Mesh

Для программирования service mesh, управляющая плоскость Istio (Istiod) считывает различные конфигурации, включая основные типы Kubernetes, такие как Service и Node, а также собственные типы Istio, например Gateway. Затем эти данные отправляются в плоскость данных (подробнее см. в разделе Architecture).

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

Такое поведение по умолчанию обеспечивает корректную работу из коробки, но сопровождается затратами на масштабируемость. Каждая конфигурация требует ресурсов (в первую очередь CPU и памяти) для поддержки и актуализации. При больших масштабах критически важно ограничить область действия конфигурации, чтобы избежать чрезмерного потребления ресурсов.

#Механизмы ограничения области действия

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

• Sidecar предоставляет механизм для конкретных рабочих нагрузок импортировать набор конфигураций
• exportTo предоставляет механизм экспортировать конфигурацию для набора рабочих нагрузок
• discoverySelectors предоставляет механизм, позволяющий Istio полностью игнорировать набор конфигураций

#Часто задаваемые вопросы

#Что произойдет, если я подключусь к сервису вне моей области действия?

При подключении к сервису, который был исключён с помощью одного из механизмов ограничения области действия, плоскость данных не будет иметь информации о назначении, поэтому такой трафик будет рассматриваться как Unmatched traffic.

#А как насчёт Gateways?

Хотя Gateways учитывают exportTo и discoverySelectors, объекты Sidecar не влияют на Gateways. Однако, в отличие от sidecar, gateways по умолчанию не имеют конфигурации для всего кластера. Вместо этого каждая конфигурация явно привязывается к gateway, что в основном предотвращает эту проблему.

Тем не менее, в настоящее время часть конфигурации плоскости данных (так называемый «cluster» в терминах Envoy) всегда отправляется для всего кластера, даже если она явно не используется.