Rendimiento y escalado del complemento de malla de servicio de Istio

El complemento de malla de servicio basado en Istio se divide lógicamente en un plano de control (istiod) y un plano de datos. El plano de datos se compone de servidores proxy sidecar de Envoy dentro de pods de carga de trabajo. Istiod administra y configura estos servidores proxy de Envoy. En este artículo se presenta el rendimiento del plano de datos y de control para la revisión asm-1-19; se incluye el consumo de recursos, la capacidad de sidecar y la sobrecarga de latencia. Además, se proporcionan sugerencias para abordar posibles tensiones en los recursos durante períodos de carga pesada. En este artículo también se explica cómo personalizar el escalado para el plano de control y las puertas de enlace.

Rendimiento del plano de control

Los requisitos de CPU y memoria de Istiod se correlacionan con la tasa de cambios de implementación y configuración y el número de servidores proxy conectados. Los escenarios probados fueron:

• Cambios en pods: se examina el impacto de los cambios en los pods en istiod. Para reducir las variables, solo se usa un servicio para todos los sidecars.
• Varios servicios: se examina el impacto de varios servicios en el número máximo de sidecars que Istiod puede administrar (capacidad sidecar), donde cada servicio tiene N sidecars, totalizando el máximo total.

Especificaciones de prueba

• Una instancia de istiod con la configuración predeterminada
• Escalado automático horizontal de pods deshabilitado
• Probado con dos complementos de red: Superposición de Azure Container Networking Interface (CNI) y Superposición de Azure CNI con Cilium (complementos de red recomendados para clústeres a gran escala)
• SKU de nodo: Standard D16 v3 (16 vCPU, 64 GB de memoria)
• Versión de Kubernetes: 1.28.5
• Revisión de Istio: asm-1-19

Cambios en pods

Se usó el marco de trabajo ClusterLoader2 para determinar el número máximo de sidecars que Istiod puede administrar cuando se producen cambios en los sidecars. El porcentaje de cambios se define como el porcentaje de los sidecars que han aumentado o disminuido durante la prueba. Por ejemplo, cambios del 50 % con respecto a 10 000 sidecars significaría que ha habido una disminución de 5000 sidecars y un aumento de 5000 sidecars. Los porcentajes de cambios probados se determinaron a partir del porcentaje típico de cambios durante los lanzamientos de implementaciones (maxUnavailable). La tasa de cambios se calculó mediante la determinación del número total de sidecars con cambios (que han aumentado o disminuido) durante el tiempo real necesario para completar el proceso de cambios.

Capacidad de sidecars y CPU y memoria de Istiod

Superposición de Azure CNI

Cambios (%)	Tasa de cambios (sidecars/s)	Capacidad de sidecar	Memoria de Istiod (GB)	CPU de Istiod
0	--	25000	32,1	15
25	31,2	15000	22.2	15
50	31,2	15000	25.4	15

Superposición de Azure CNI con Cilium

Cambios (%)	Tasa de cambios (sidecars/s)	Capacidad de sidecar	Memoria de Istiod (GB)	CPU de Istiod
0	--	30000	41.2	15
25	41.7	25000	36,1	16
50	37.9	25000	42,7	16

Varios servicios

Se usó el marco de trabajo ClusterLoader2 para determinar el número máximo de sidecars que istiod puede administrar con 1000 servicios. Los resultados se pueden comparar con la prueba de cambios del 0 % (un servicio) en el escenario de cambios en los pods. Cada servicio tenía N sidecars que contribuyen al recuento total máximo de sidecars. Se observó el uso de recursos del servidor de API para determinar si había alguna carga significativa del complemento.

Capacidad de sidecar

Superposición de Azure CNI	Superposición de Azure CNI con Cilium
20000	20000

CPU y memoria

Resource	Superposición de Azure CNI	Superposición de Azure CNI con Cilium
Memoria del servidor de API (GB)	38,9	9.7
CPU del servidor de API	6.1	4.7
Memoria de Istiod (GB)	40,4	42.6
CPU de Istiod	15	16

Rendimiento del plano de datos

Varios factores afectan al rendimiento de sidecars, como el tamaño de la solicitud, el número de subprocesos de trabajo de proxy y el número de conexiones de cliente. Además, cualquier solicitud que fluya a través de la malla atraviesa el proxy del lado cliente y, a continuación, el proxy del lado servidor. Por lo tanto, se miden la latencia y el consumo de recursos para determinar el rendimiento del plano de datos.

Se usó Fortio para crear la carga. La prueba se realizó con el repositorio de pruebas comparativas de Istio que se modificó para que se pudiera usar con el complemento.

Especificaciones de prueba

• Probado con dos complementos de red: Superposición de Azure CNI y Superposición de Azure CNI con Cilium (complementos de red recomendados para clústeres a gran escala)
• SKU de nodo: Standard D16 v5 (16 vCPU, 64 GB de memoria)
• Versión de Kubernetes: 1.28.5
• Dos trabajos de proxy
• Carga de 1 KB
• 1000 consultas por segundo (QPS) en conexiones de cliente variables
• Protocolo http/1.1 y Seguridad de la capa de transporte (TLS) mutua habilitados
• 26 puntos de datos recopilados

CPU y memoria

El uso de memoria y CPU para el proxy de cliente y servidor con 16 conexiones de cliente y 1000 QPS en todos los escenarios del complemento de red es aproximadamente de 0,4 vCPU y 72 MB.

Latencia

El proxy sidecar Envoy recopila datos de telemetría sin procesar después de responder a un cliente, lo que no afecta directamente al tiempo total de procesamiento de la solicitud. Sin embargo, este proceso retrasa el inicio de la gestión de la siguiente solicitud, lo que contribuye a tiempos de espera en cola e influye en latencias media y de cola. Según el patrón de tráfico, la latencia de cola real varía.

Los siguientes resultados evalúan el impacto de agregar servidores proxy sidecar a la ruta de acceso de datos, que muestra la latencia P90 y P99.

• Ruta de acceso de tráfico de Sidecar: client --> client-sidecar --> server-sidecar --> server
• Ruta de acceso de tráfico de línea base: client --> server

Puede encontrar una comparación del rendimiento de latencia del plano de datos entre el complemento Istio y las versiones de AKS aquí.

Superposición de Azure CNI	Superposición de Azure CNI con Cilium

Ampliación

Personalización del escalado automático horizontal de pods

El Escalado automático horizontal de pods (HPA) está habilitado para los pods de puerta de enlace de entrada y istiod. Las configuraciones predeterminadas para istiod y las puertas de enlace son:

• Réplicas mínimas: 2
• Número máximo de réplicas: 5
• Uso de CPU: 80 %

Nota:

Para evitar conflictos con el PodDisruptionBudget, el complemento no permite establecer el minReplicas por debajo del valor predeterminado inicial de 2.

A continuación se muestran los recursos de istiod y puerta de enlace de entrada de 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

La configuración de HPA se puede modificar mediante revisiones y modificaciones directas. Ejemplo:

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

Nota:

Consulte la documentación de actualización del complemento Istio para obtener detalles sobre cómo se aplican las configuraciones de HPA en ambas revisiones durante una actualización canaria.

Entrada de servicio

La definición de recursos personalizados de ServiceEntry de Istio permite agregar otros servicios al registro de servicios internos de Istio. Una entrada ServiceEntry permite a los servicios ya en la malla enrutar o acceder a los servicios especificados. Sin embargo, la configuración de varias ServiceEntries con el campo resolution establecido en DNS puede provocar una carga pesada en los servidores de Sistema de nombres de dominio (DNS). Las sugerencias siguientes pueden ayudarle a reducir la carga:

• Cambie a resolution: NONE para evitar por completo búsquedas de DNS de proxy. Adecuado para la mayoría de los casos de uso.
• Aumente el TTL (período de vida) si controla los dominios que se resuelven.
• Limite el ámbito de ServiceEntry con exportTo.