Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Como resolver problemas de escalonamento do Istio no Cloud Service Mesh
Esta seção explica problemas comuns do Cloud Service Mesh e como resolvê-los.
Se você precisar de mais ajuda, consulte Como receber suporte.
Fatores de escalonamento
O Istiod
envia uma configuração para cada sidecar usando um fluxo gRPC de longa duração. Ele tem várias características que afetam
o escalonamento:
O tamanho da configuração a ser gerada:
Número total de serviços/pods e recursos do Istio
Para larga escala, ajuste as configurações do Sidecar
para reduzir o tamanho da configuração.
A taxa de alteração no ambiente:
Quando um novo serviço é criado ou a configuração do Istio é alterada, as atualizações completas são enviadas aos proxies.
A adição de novos endpoints não é cara porque apenas atualizações incrementais são enviadas.
O número de proxies para que a configuração é gerada:
Afetados pelo número de gateways e pods com um sidecar.
Considerações de escalonamento
O Istio é escalonado verticalmente corretamente (solicitações grandes) e horizontalmente (mais
réplicas). Verifique se os limites da CPU não são muito restritivos. Se o Istio
atingir o limite de CPU, poderá haver uma diminuição que afeta
a distribuição da configuração de forma negativa. Se você encontrar problemas de desempenho, faça upgrade
para a versão mais recente do Cloud Service Mesh, porque cada versão tem
otimizações de desempenho.
Carga não balanceada
Grandes mudanças no tamanho do cluster podem causar uma carga temporariamente desalocada devido às
conexões de longa duração. Isso é minimizado por uma idade máxima de conexão de 30 minutos,
o que pode resultar em mensagens de erro no Envoy, como gRPC config stream
closed: 13, que permite que a carga seja rebalanceada naturalmente.
Reduza esse problema com várias réplicas do Istio (o padrão é duas
réplicas) e faça o pré-escalonamento se você espera aumentar o número de escalonamentos verticais.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-09-04 UTC."],[],[],null,["Resolving Istiod scaling issues in Cloud Service Mesh\n\nThis section explains common Cloud Service Mesh problems and how to resolve them.\nIf you need additional assistance, see [Getting support](/service-mesh/v1.20/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\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 re-balance.\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."]]
