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
Ricevere assistenza.
I problemi relativi al limite di risorse di Cloud Service Mesh possono essere causati da uno dei seguenti elementi:
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 dal piano di controllo, 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 impiegano 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:
Per Cloud Service Mesh all'interno del cluster, se gli strumenti di monitoraggio (Prometheus,
Stackdriver e così via) mostrano un elevato utilizzo di una risorsa da parte di istiod, aumenta
la relativa allocazione, ad esempio aumentando 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 o un deployment di grandi dimensioni, riduci la quantità di stato di configurazione inviata a ciascun proxy configurando le risorse sidecar.
Per Cloud Service Mesh nel cluster, se il problema persiste, prova a eseguire il scaling 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 e del numero di servizi.
[[["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\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\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."]]
