Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Risolvere i problemi relativi ai limiti di risorse in Cloud Service Mesh
Questa sezione illustra i problemi comuni di Cloud Service Mesh e come risolverli.
Se hai bisogno di ulteriore assistenza, consulta la sezione Ricevere assistenza.
I problemi relativi al limite di risorse di Cloud Service Mesh possono essere causati da uno dei seguenti fattori:
Oggetti LimitRange creati nello spazio dei nomi istio-system o in qualsiasi spazio dei nomi con l'iniezione automatica di sidecar abilitata.
Limiti definiti dall'utente impostati su valori troppo bassi.
I nodi esauriscono la memoria o altre risorse.
Possibili sintomi di problemi relativi alle risorse:
Cloud Service Mesh non riceve ripetutamente la configurazione da istiod, come indicato dall'errore Envoy proxy NOT ready. È normale visualizzare questo errore alcune volte all'avvio, ma in caso contrario è un problema.
Problemi di rete con alcuni pod o nodi che diventano irraggiungibili.
istioctl proxy-status che mostra gli stati STALE nell'output.
OOMKilled nei log di un nodo.
Utilizzo della memoria da parte dei container: kubectl top pod POD_NAME --containers.
Utilizzo della memoria da parte dei pod all'interno di un nodo: kubectl top node my-node.
Envoy out of memory: kubectl get pods shows status OOMKilled in the output.
I sidecar Istio richiedono molto tempo per ricevere la configurazione
La propagazione della configurazione può essere lenta a causa di risorse insufficienti allocate
a istiod o a dimensioni eccessivamente grandi del cluster.
Esistono diverse possibili soluzioni a questo problema:
Se gli strumenti di monitoraggio (Prometheus, Stackdriver e così via) mostrano un utilizzo elevato di una risorsa da parte di istiod, aumenta l'allocazione di quella risorsa, ad esempio aumenta il limite di CPU o memoria del deployment di istiod. Si tratta di una soluzione temporanea e ti consigliamo di esaminare i metodi per ridurre il consumo di risorse.
Se riscontri questo problema in un cluster/un'implementazione di grandi dimensioni, riduci la quantità di stato di configurazione inviata a ciascun proxy configurando le risorse sidecar.
Se il problema persiste, prova a eseguire la scalatura orizzontale istiod.
Se tutti gli altri passaggi per la risoluzione dei problemi non risolvono il problema, segnala un bug descrivendo in dettaglio il deployment e i problemi osservati. Segui
questi passaggi
per includere, se possibile, un profilo CPU/memoria nella segnalazione di bug, insieme a una
descrizione dettagliata delle dimensioni del cluster, del numero di pod, del numero di servizi e così via.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-09-04 UTC."],[],[],null,["Resolving resource limit 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\nCloud Service Mesh resource limit problems can be caused by any of the following:\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 `istiod` 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\nIstio sidecars take a long time to receive configuration\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. If your monitoring tools (prometheus, stackdriver, etc.) show high\n utilization of a resource by `istiod`, increase the allocation of that resource,\n for example increase the CPU or memory limit of the `istiod` deployment. This is a\n temporary solution and we recommended that you investigate methods for reducing\n resource consumption.\n\n2. If you encounter this issue in a large cluster/deployment, reduce the amount\n of configuration state pushed to each proxy by configuring\n [Sidecar resources](https://istio.io/v1.26/docs/reference/config/networking/sidecar/).\n\n3. If the problem persists, try 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, number of services, etc."]]