Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Resuelve problemas de escalamiento en Cloud Service Mesh
En esta sección, se explican los problemas comunes de Cloud Service Mesh y cómo resolverlos. Si necesitas asistencia adicional, consulta Obtén asistencia.
Factores del escalamiento
Istiod envía la configuración a cada sidecar mediante una transmisión de gRPC de larga duración. Tiene varias características que afectan el escalamiento:
El tamaño de la configuración que se generará:
La cantidad total de servicios/Pods y recursos de Istio
Para un gran escalamiento, ajusta la configuración del sidecar a fin de reducir el tamaño de la configuración.
La velocidad de cambio en el entorno:
Cuando se crea un nuevo servicio o se cambia la configuración de Istio, se envían las actualizaciones completas a los proxies.
Agregar nuevos extremos no es rentable para el rendimiento, porque solo se envían actualizaciones incrementales.
La cantidad de proxies para los que se genera la configuración:
Se ven afectados por la cantidad de puertas de enlace y Pods con un sidecar.
Consideraciones del escalamiento
Istio escala de forma vertical (solicitudes grandes) y horizontal (más réplicas). Asegúrate de que los límites de tu CPU no sean demasiado restrictivos. Si Istio alcanza el límite de CPU, puede ocurrir una limitación que afecte de forma negativa la distribución de la configuración. Si encuentras problemas de rendimiento, considera actualizar a la versión más reciente de Cloud Service Mesh, ya que cada versión tiene optimizaciones de rendimiento.
Los cambios grandes en el tamaño del clúster pueden provocar una carga temporalmente desequilibrada debido a las conexiones de larga duración. Esto se mitiga mediante una antigüedad de conexión máxima de 30 minutos, lo que puede provocar mensajes de error en Envoy, como gRPC config stream
closed: 13, que permite que la carga se vuelva a balancear de forma natural.
Mitiga este problema con varias réplicas de Istiod (la configuración predeterminada es 2 réplicas) y realiza un escalamiento previo si esperas escalamientos verticales extremos en el clúster.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-09-04 (UTC)"],[],[],null,["# Resolving scaling issues in Cloud Service Mesh\n==============================================\n\n| **Note:** This guide only supports Cloud Service Mesh with Istio APIs and does not support Google Cloud APIs. For more information see, [Cloud Service Mesh overview](/service-mesh/v1.24/docs/overview).\n\nThis section explains common Cloud Service Mesh problems and how to resolve\nthem. If you need additional assistance, see\n[Getting support](/service-mesh/v1.24/docs/getting-support).\n\nScaling factors\n---------------\n\n[Istiod](https://istio.io/v1.24/blog/2020/istiod/)\nsends configuration to each sidecar using a long-lived gRPC stream. It has\nseveral characteristics that affect scaling:\n\n- The size of the configuration to generate:\n - Total number of services/pods \\& Istio resources\n - For large scale, adjust settings for the [Sidecar](https://istio.io/v1.24/docs/reference/config/networking/sidecar/) to reduce the configuration size.\n- The rate of change in the environment:\n - When a new service is created or the Istio configuration is changed, full updates are sent to proxies.\n - Adding new endpoints is inexpensive for performance, because only incremental updates are sent.\n- The number of proxies for which configuration is generated:\n - Affected by the number of gateways and pods with a sidecar.\n\nScaling considerations\n----------------------\n\nIstiod scales well vertically (large requests) and horizontally (more\nreplicas). Ensure that your CPU limits are not too restrictive; if Istiod\nreaches the CPU limit, throttling may occur which will negatively affect\nconfiguration distribution. If you encounter performance issues, consider\nupgrading to the latest version of Cloud Service Mesh, as each version has\nperformance optimizations.\n\nFor more guidance on scaling your mesh, see the\n[Scalability best practices guide](/service-mesh/v1.24/docs/operate-and-maintain/scalability-best-practices).\n\nUnbalanced load\n---------------\n\nLarge changes in cluster size might cause a temporarily unbalanced load, due to\nthe long-lived connections. This is mitigated by a 30 minute maximum connection\nage, which might result in error messages in Envoy, such as `gRPC config stream\nclosed: 13`, which allows the load to naturally rebalance.\n\nMitigate this issue by having multiple replicas of Istiod (the default is 2\nreplicas), and pre-scaling if you expect extreme cluster scale-ups."]]
