Производительность и масштабирование надстроек сетки службы Istio

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

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

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

• Поток pod: проверяет влияние оттока istiodмодулей pod. Для уменьшения переменных используется только одна служба для всех боксов.
• Несколько служб: проверяет влияние нескольких служб на максимальный объем обслуживания Istiod может управлять (емкость бокового автомобиля), где каждая служба имеет N боковики, суммируя общее максимальное значение.

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

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

Отток pod

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

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

Наложение Azure CNI

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

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

Отток (%)	Скорость оттока (боковики/с)	Емкость бокового автомобиля	Память Istiod (ГБ)	ЦП Istiod
0	--	30 000	41,2	15
25	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 и Наложения Azure CNI с помощью 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

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

Настройка автоматического масштабирования по горизонтали pod

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

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

Примечание.

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

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

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-сервера. Подходит для большинства вариантов использования.
• Увеличьте срок жизни (время в реальном времени), если вы управляете разрешением доменов.
• Ограничить область ServiceEntry с exportToпомощью .