Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Résoudre les problèmes de scaling dans Cloud Service Mesh
Cette section explique les problèmes courants rencontrés avec Cloud Service Mesh et indique comment les résoudre. Si vous avez besoin d'une aide supplémentaire, consultez la page Obtenir de l'aide.
Facteurs de scaling
Istiod envoie une configuration à chaque side-car à l'aide d'un flux gRPC de longue durée. Plusieurs caractéristiques affectent le scaling :
La taille de la configuration à générer :
Nombre total de services/pods et ressources Istio
À grande échelle, ajustez les paramètres du side-car pour réduire la taille de la configuration.
La vitesse à laquelle l'environnement évolue :
Lorsqu'un service est créé ou que la configuration d'Istio est modifiée, des mises à jour complètes sont envoyées aux proxys.
L'ajout de nouveaux points de terminaison a peu d'impact sur les performances, car seules des mises à jour incrémentielles sont envoyées.
Le nombre de proxys pour lesquels la configuration est générée :
Est affecté par le nombre de passerelles et de pods avec un side-car.
Remarques concernant le scaling
Istiod s'adapte bien verticalement (requêtes volumineuses) et horizontalement (plus d'instances dupliquées). Vérifiez que votre limite de processeur n'est pas trop restrictive. Si Istiod atteint cette limite, une limitation peut survenir et avoir un impact négatif sur la distribution de la configuration. Si vous rencontrez des problèmes de performances, envisagez de passer à la dernière version de Cloud Service Mesh, car chaque version bénéficie d'optimisation des performances.
Des modifications importantes de la taille du cluster peuvent entraîner un déséquilibre temporaire de la charge, en raison des connexions de longue durée. Ce problème est atténué par un âge de connexion maximal de 30 minutes, ce qui peut entraîner des messages d'erreur dans Envoy, tels que gRPC config stream
closed: 13, ce qui permet de rééquilibrer la charge naturellement.
Atténuez ce problème en utilisant plusieurs instances dupliquées d'Istiod (la valeur par défaut étant de deux instances dupliquées) et la fonctionnalité de pré-scaling si vous prévoyez des scalings à la hausse extrêmes des clusters.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/04 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/04 (UTC)."],[],[],null,["Resolving scaling issues in Cloud Service Mesh **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/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/docs/getting-support).\n\nScaling factors\n\n[Istiod](https://istio.io/v1.26/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.26/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\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/docs/operate-and-maintain/scalability-best-practices).\n\nUnbalanced load\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."]]
