Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Como resolver problemas de limite de recursos 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.
Os problemas de limite de recursos do Cloud Service Mesh podem ser causados por qualquer um dos
seguintes motivos:
Objetos LimitRange criados no namespace istio-system ou qualquer namespace com injeção automática de arquivo secundário ativada.
Limites definidos pelo usuário que são muito baixos.
Os nós ficam sem memória ou outros recursos.
Possíveis sintomas de problemas de recursos:
O Cloud Service Mesh repetidamente não recebe a configuração do plano de controle
indicado pelo erro Envoy proxy NOT ready. Ver esse erro algumas vezes
na inicialização é normal, mas, caso contrário, é uma preocupação.
Problemas de rede com alguns pods ou nós que se tornam inacessíveis.
istioctl proxy-status mostrando status STALE na saída.
Mensagens OOMKilled nos registros de um nó.
Uso da memória por contêineres: kubectl top pod POD_NAME --containers.
Uso da memória por pods em um nó: kubectl top node my-node.
Invocação de memória: kubectl get pods mostra o status OOMKilled na saída.
Os sidecars levam muito tempo para receber a configuração
A propagação de configuração lenta pode ocorrer devido a recursos insuficientes alocados para o istiod ou um tamanho de cluster excessivamente grande.
Há várias soluções possíveis para esse problema:
Para o Cloud Service Mesh no cluster, se suas ferramentas de monitoramento (Prometheus,
Stackdriver etc.) mostrarem a alta utilização de um recurso pelo istiod, aumente
a alocação desse recurso. Por exemplo, aumente o limite da CPU ou da memória
da implantação do istiod. Essa é uma solução temporária. Recomendamos
que você investigue métodos para reduzir o consumo de recursos.
Se você encontrar esse problema em um cluster ou implantação grande, reduza a
quantidade de estado de configuração enviada para cada proxy configurando
recursos do Sidecar.
Para o Cloud Service Mesh no cluster, se o problema persistir, tente
dimensionar horizontalmente o istiod.
Se todas as outras etapas de solução de problemas não resolverem o problema, informe um bug
detalhando a implantação e os problemas observados. Siga
estas etapas
para incluir um perfil de CPU/memória no relatório do bug, se possível, junto com uma
descrição detalhada do tamanho do cluster, número de pods e número de serviços.
[[["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-08-19 UTC."],[],[],null,["# Resolving resource limit issues in Cloud Service Mesh\n=====================================================\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\nCloud Service Mesh resource limit problems can be caused by any of the\nfollowing:\n\n- `LimitRange` objects created in the `istio-system` namespace or any namespace with automatic sidecar injection enabled.\n- User-defined limits that are set too low.\n- Nodes run out of memory or other resources.\n\nPotential symptoms of resource problems:\n\n- Cloud Service Mesh repeatedly not receiving configuration from the control plane indicated by the error, `Envoy proxy NOT ready`. Seeing this error a few times at startup is normal, but otherwise it is a concern.\n- Networking problems with some pods or nodes that become unreachable.\n- `istioctl proxy-status` showing `STALE` statuses in the output.\n- `OOMKilled` messages in the logs of a node.\n- Memory usage by containers: `kubectl top pod POD_NAME --containers`.\n- Memory usage by pods inside a node: `kubectl top node my-node`.\n- Envoy out of memory: `kubectl get pods` shows status `OOMKilled` in the output.\n\nSidecars take a long time to receive configuration\n--------------------------------------------------\n\nSlow configuration propagation can occur due to insufficient resources allocated\nto `istiod` or an excessively large cluster size.\n\nThere are several possible solutions to this problem:\n\n1. For in-cluster Cloud Service Mesh, if your monitoring tools (prometheus,\n stackdriver, etc.) show high utilization of a resource by `istiod`, increase\n the allocation of that resource, for example increase the CPU or memory limit\n of the `istiod` deployment. This is a temporary solution and we recommended\n that you investigate methods for reducing resource consumption.\n\n2. If you encounter this issue in a large cluster or deployment, reduce the\n amount of configuration state pushed to each proxy by configuring\n [Sidecar resources](https://istio.io/v1.26/docs/reference/config/networking/sidecar/).\n\n3. For in-cluster Cloud Service Mesh, if the problem persists, try\n horizontally scaling `istiod`.\n\n4. If all other troubleshooting steps fail to resolve the problem, report a bug\n detailing your deployment and the observed problems. Follow\n [these steps](https://github.com/istio/istio/wiki/Analyzing-Istio-Performance)\n to include a CPU/Memory profile in the bug report if possible, along with a\n detailed description of cluster size, number of pods, and number of services."]]
