Привет, Хабр! Недавно я предложила вам перевод статьи о проблемах, связанных с использованием Service Mesh, и преимуществах Ambient Mesh. Сегодня я хочу привести несколько конкретных чисел в качестве дополнения. Представляю вашему вниманию перевод статьи "Istio Ambient Mesh Performance in Single vs Multiple Kubernetes Namespaces" автора Anupam Saha.
Существует множество статей о Service Mesh и Istio, включая Ambient Mesh, новейшем кандидате на роль Service Mesh в Kubernetes. Этот пост посвящен моему опыту оценки производительности Ambient Mesh от Istio, имитируя развертывание корпоративного уровня в нескольких неймспейсах Kubernetes.
Istio и Ambient Mesh
Для тех, кто не знаком с Service Mesh, это специальный инфраструктурный уровень в Kubernetes, позволяющий сделать взаимодействие между сервисами более безопасным, быстрым и надежным. Как правило, Service Mesh строятся с двухуровневой архитектурой, содержащей Control Plane для настройки сети и Data Plane для обеспечения функциональности сети. Data Plane состоит из sidecar-контейнера, который прикрепляется к поду микросервиса и потребляет дополнительные ресурсы процессора и памяти.
Хотя эта архитектура sidecar уже хорошо известна, сообщество разработчиков и пользователей Service Mesh проявляет большой интерес к улучшению ее ресурсопотребления. С этой целью компания solo.io, обладающая опытом работы с Service Mesh, создала новую архитектуру Data Plane под названием Ambient Mesh. Позже к этому проекту присоединилась компания Google, и версия с открытым исходным кодом стала доступна нам как часть Service Mesh от Istio. Если вам интересно почитать о новой архитектуре, то в блоге Istio есть несколько очень хороших отправных точек.
Настройка тестовой инфраструктуры
GCP остается для меня лучшим выбором облачного провайдера для этой оценки с демонстрационным микросервисным приложением Bank of Anthos (BOA) от Google. Настройка тестовой среды включает в себя инициализацию кластера Kubernetes и стека визуализации Grafana с помощью скриптов Terraform, а затем установку Istio. Затем с помощью Helm чартов были развернуты микросервисы, включая привязку фронтенд-микросервиса к ингресс-контроллеру Istio. Это дает возможность доступа к приложению извне кластера, что позволяет проводить нагрузочное тестирование с локальной рабочей станции.
Используются два сценария развертывания BOA для проведения тестов эффективности использования памяти и процессора в двух режимах Istio.
Сначала мы рассмотрим типичный пример небольшой организации, где 8 микросервисов приложения BOA развернуты в одном неймспейсе Kubernetes с двумя репликами.
Затем последует корпоративная модель развертывания, в которой обычно микросервисы развертываются в разных неймспейсах с доступом на уровне команды, ограниченным RBAC политиками Kubernetes. В нашем случае RBAC не применяется, так как это не влияет на производительность Service Mesh, но BOA микросервисы развернуты в 8 различных неймспейсах с 6 репликами.
Цель этого теста — проверить оба режима Istio в реальной среде развертывания.
Интересным фактором является влияние производительности прокси-сервера Waypoint в режиме Ambient, так как в кластере развернуто 8 прокси-серверов Waypoint, подключенных к каждому неймспейсу. В обоих случаях количество прокси-серверов Ztunnel варьировалось в зависимости от количества нод (node) кластера.
На следующем рисунке показана визуализация инфраструктуры GCP для развертываний BOA в нескольких неймспейсах. На диаграмме показано развертывание до 3 неймспейсов, чтобы снизить сложность рисунка, однако в реальном тесте используется 8 неймспейсов, каждый из которых представляет один микросервис. При развертывании в нескольких неймспейсах «Istio-System» и «Мониторинг» неймспейсы остаются неизменными, но компоненты Data Plane Istio немного изменяются. Ztunnel развертывается по одному на каждой ноде, в то время как экземпляр Waypoint прокси используется несколько раз, чтобы охватить несколько неймспейсов.
Оценка эффективности
Показатели результатов тестирования получены из Grafana, они отображают минимальное, максимальное и среднее значение потребления CPU и памяти за 10-минутный период времени для каждого теста. Эта оценка включает 12 различных тестовых ситуаций, охватывающих окружения с одним и несколькими неймспейсами.
Разница в производительности оценивалась путем сравнения средних значений использования CPU и памяти в режиме Istio sidecar (конфигурация по умолчанию) и в режиме Ambient (с включенным прокси L4 и L4+L7). Два разных сравнения проводятся между режимом sidecar и режимом Ambient в двух разных конфигурациях, чтобы отследить потребление ресурсов прокси-серверами Ztunnel и Waypoint.
В итоге использование процессора системой Istio улучшилось на 7,4% в тестовом сценарии с одним неймспейсом и на 39% в тестовом сценарии с несколькими неймспейсами.
Использование памяти системой Istio также показало значительное улучшение в Ambient режиме: 79,45% в одном неймспейсе и 74,98% в разных неймспейсах.
Заключение
Sidecarless модель Ambient Mesh демонстрирует заметные преимущества в производительности по сравнению с моделью sidecar и позволяет сэкономить на облачных ресурсах. Глядя на результаты тестирования, Ambient Mesh можно рассматривать как будущее Service Mesh, обеспечивающее неинвазивный дизайн. Если вас интересует настройка Ambient Mesh в вашем кластере Kubernetes, на сайте istio.io есть руководство. Также, если вы хотите взглянуть на скрипты, использованные для этой оценки, не стесняйтесь заглянуть в мой репозиторий Github.