Производительность и масштабирование дополнений сервисной сетки Istio

Надстройка service mesh на основе Istio логически разделена на вычислительную плоскость (istiod) и плоскость данных. Плоскость данных состоит из прокси-серверов Envoy внутри рабочих подов. Istiod управляет и настраивает эти прокси-серверы Envoy. В этой статье представлена производительность как управляющей плоскости, так и плоскости данных для ревизии asm-1-19, включая потребление ресурсов, емкость прокси-сервиса и накладные расходы на задержку. Кроме того, он предоставляет предложения по устранению потенциальной нагрузки на ресурсы в периоды тяжелой нагрузки. В этой статье также описывается настройка масштабирования для плоскости управления и шлюзов.

Производительность плоскости управления

Требования к ЦП и памяти Istiod соответствуют скорости развертывания и конфигурации и количеству подключенных прокси-серверов. Тестируемые сценарии:

• Отток pod: анализирует влияние оттока подов на istiod. Чтобы сократить количество переменных, используется только один сервис для всех сайдкаров.
• Несколько служб: исследуется влияние нескольких служб на максимальную емкость боковых процессов, которыми Istiod может управлять, где каждая служба имеет N боковых процессов, суммируя их в общее максимальное количество.

Спецификации тестирования

• Один istiod экземпляр с параметрами по умолчанию
• Горизонтальное автоматическое масштабирование pod отключено
• Протестировано с двумя сетевыми подключаемыми модулями: Azure Container Networking Interface (CNI) Overlay и Azure CNI Overlay с Cilium (рекомендуемые сетевые подключаемые модули для крупномасштабных кластеров)
• Номер SKU узла: Standard D16 версии 3 (16 виртуальных ЦП, 64 ГБ памяти)
• Версия Kubernetes: 1.28.5
• Редакция Istio: asm-1-19

Отток подов

Платформа ClusterLoader2 была использована для определения максимального количества боковых процессов, которыми Istiod может управлять при колебания таких процессов. Процент оттока определяется как процент боковичек, выкрученных вниз/вверх во время теста. Например, 50% оттока из 10 000 процессоров означают, что 5000 процессоров были отключены, а затем 5000 процессоров были заново подключены. Проценты оттока, которые подвергались тестированию, были определены на основе типичного процента оттока во время этапа развертывания (maxUnavailable). Скорость оттока была рассчитана путем определения общего количества колясок, оборачиваемых за фактическое время, затраченное на завершение процесса замены.

Емкость бокового автомобиля и Истиод ЦП и память

Капсуляция Azure CNI

Отток (%)	Скорость оттока (боковики/с)	Емкость модуля Sidecar	Память Istiod (ГБ)	ЦП Istiod
0	--	25 000	32,1	15
двадцать пять	31,2	15000	22.2	15
50	31,2	15000	25,4	15

Наложение Azure CNI с помощью Cilium

Отток (%)	Скорость оттока (боковики/с)	Емкость бокового автомобиля	Память Istiod (ГБ)	ЦП Istiod
0	--	30 000	41,2	15
двадцать пять	41.7	25 000	36.1	16
50	37,9	25 000	42,7	16

Несколько служб

Фреймворк ClusterLoader2 использовался для определения максимального количества сайдкаровistiod, которыми можно управлять с помощью 1000 служб. Результаты можно сравнить с тестом на 0% оттока одного сервиса в сценарии оттока pod. Каждая служба имела N побочные компоненты, способствующие достижению общего максимального количества вспомогательных модулей. Наблюдалось использование ресурсов сервера API, чтобы определить, возникла ли какая-либо серьезная нагрузка от надстройки.

Емкость бокового автомобиля

Оверлей Azure CNI	Наложение Azure CNI с помощью Cilium
20000	20000

ЦП и память

Ресурс	Наложение Azure CNI	Наложение Azure CNI с помощью Cilium
Память сервера API (ГБ)	38,9	9.7
ЦП сервера API	6.1	4,7
Память Istiod (ГБ)	40,4	42,6
ЦП Istiod	15	16

Производительность плоскости данных

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

Fortio использовался для создания нагрузки. Тест был проведен с репозиторием Istio benchmark, который был изменен для использования с данной надстройкой.

Спецификации тестирования

• Протестировано с использованием двух сетевых плагинов: Azure CNI Overlay и Azure CNI Overlay with Cilium (рекомендуемые сетевые плагины для крупномасштабных кластеров)
• Номер SKU узла: Standard D16 v5 (16 vCPU, 64-ГБ памяти)
• Версия Kubernetes: 1.28.5
• Два прокси-сотрудника
• Полезные данные размером 1 КБ
• 1000 запросов в секунду (QPS) при различных клиентских подключениях
• http/1.1 протокол и взаимная аутентификация на основе безопасности транспортного уровня (TLS) включены
• 26 точек данных, собранных

ЦП и память

Использование памяти и ЦПУ для прокси клиента и сервера при 16 клиентских подключениях и 1000 запросах в секунду (QPS) во всех сценариях сетевого плагина составляет примерно 0,4 виртуальных ЦПУ и 72 МБ.

Задержка

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

Следующие результаты оценивают влияние добавления сайдкар-прокси в путь данных, демонстрируя задержку P90 и P99.

• Путь трафика сайдкара: клиент --> клиент-сайдкар --> сервер-сайдкар --> сервер
• Базовый путь трафика: клиент -> сервер

Сравнение времени задержки канала данных между надстройками Istio и версиями AKS можно найти здесь.

Оверлей Azure CNI	Наложение Azure CNI с помощью Cilium
	Схема, сравнивающая задержку P90 для оверлея Azure CNI и Cilium.

Масштабирование

Настройка горизонтального автоматического масштабирования Pod (HPA)

Горизонтальное автоматическое масштабирование pod (HPA) включено для istiod развертываний шлюза входящего и исходящего трафика. Конфигурации по умолчанию для istiod и шлюзов:

• Минимальные реплики: 2
• Количество реплик: 5
• Загрузка ЦП: 80 %

Примечание.

Чтобы предотвратить конфликты с PodDisruptionBudget, расширение не позволяет установить minReplicas ниже установленного по умолчанию начального значения 2.

Ниже приведены ресурсы HPA шлюза istiod и входного шлюза.

NAMESPACE           NAME                                         REFERENCE
aks-istio-ingress   aks-istio-ingressgateway-external-asm-1-19   Deployment/aks-istio-ingressgateway-external-asm-1-19

aks-istio-ingress   aks-istio-ingressgateway-internal-asm-1-19   Deployment/aks-istio-ingressgateway-internal-asm-1-19

aks-istio-system    istiod-asm-1-19                              Deployment/istiod-asm-1-19

Конфигурацию HPA можно изменить с помощью исправлений и прямых изменений. Пример:

kubectl patch hpa aks-istio-ingressgateway-external-asm-1-19 -n aks-istio-ingress --type merge --patch '{"spec": {"minReplicas": 3, "maxReplicas": 6}}'

Примечание.

Дополнительные сведения о том, как параметры HPA применяются в обоих версиях во время обновления канарной версии, см. в документации по обновлению надстройки Istio.

Запись службы

Определение пользовательского ресурса Istio ServiceEntry позволяет добавлять другие службы в внутренний реестр служб Istio. ServiceEntry позволяет службам, уже находящимся в сетке, маршрутизировать или получать доступ к указанным службам. Однако конфигурация нескольких ServiceEntries с resolution заданным полем для DNS может вызвать тяжелую нагрузку на серверы системы доменных имен (DNS). Следующие предложения помогут уменьшить нагрузку:

• Переключитесь на resolution: NONE, чтобы полностью избежать обращения к прокси-серверу DNS. Подходит для большинства вариантов использования. Однако при использовании надстройки Istio для шлюза исходящего трафика необходимо установить разрешение ServiceEntry на DNS.
• Увеличьте TTL (время жизни), если вы управляете разрешением доменов.
• Ограничить область ServiceEntry с помощью exportTo.