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.
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.
- 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
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.
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 |
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 |
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.
- 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
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.
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í.
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.
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
.
Comentarios de Azure Kubernetes Service
Azure Kubernetes Service es un proyecto de código abierto. Seleccione un vínculo para proporcionar comentarios: