Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Risolvere i problemi di Cloud Service Mesh passo passo
Questa sezione spiega come risolvere i problemi relativi all'utilizzo di Cloud Service Mesh. Se hai bisogno di ulteriore assistenza, consulta
Ricevere assistenza.
Passaggi per la risoluzione dei problemi
Per risolvere i problemi di Cloud Service Mesh, segui questi passaggi generali:
Utilizza gli strumenti di convalida della configurazione automatica.
Controlla se hai un problema comune con una soluzione nota.
Restringi l'ambito del problema.
Esamina i log e le informazioni pertinenti.
Raccogli i log di diagnostica e richiedi assistenza.
Lo strumento di diagnostica di Cloud Service Mesh può rilevare problemi di configurazione comuni. Installa lo strumento per la risoluzione dei problemi seguendo queste
istruzioni.
Prima di iniziare
Assicurati che il contesto kubeconfig per il tuo cluster sia disponibile nel
file kubeconfig. In caso contrario, esegui il seguente comando:
MEMBERSHIP_LOCATION: la regione per il tuo abbonamento. Puoi controllare la posizione del tuo abbonamento con
gcloud container fleet memberships list --project FLEET_PROJECT_ID
sostituendo FLEET_PROJECT_ID con l'ID progetto del fleet.
PROJECT_NAME: il nome del progetto.
La seguente tabella descrive le possibili risposte.
SCONOSCIUTO
(Valore predefinito) Le informazioni sullo stato non sono disponibili o sono sconosciute.
SINCRONIZZATO
Il piano di controllo ha inviato la configurazione al client e ha ricevuto un ACK dal client.
ERRORE
Il piano di controllo ha inviato la configurazione al client e ha ricevuto un NACK dal client.
STALE
Il piano di controllo ha inviato la configurazione al client, ma non ha ricevuto un ACK o un NACK dal client.
NON INVIATO
La configurazione non è stata inviata.
N/D
Non applicabile.
Non supportata
Lo stato di sincronizzazione non è supportato dalla nostra API per la risoluzione dei problemi.
All'interno del cluster
kubectl get pods -n istio-system
kubectl describe -n istio-system
Per tutti i pod in istio-system: kubectl logs -n istio-system -l istio --all-containers
istioctl version
istioctl proxy-status
kubectl get configmap istio -o yaml && kubectl get configmap istio-sidecar-injector -o yaml
kubectl top pods -n istio-system
Utilizza i seguenti comandi per comprendere la scala del deployment:
kubectl get nodes
kubectl get services --all-namespaces
kubectl get pods --all-namespaces
Visualizzare le configurazioni proxy
Il seguente comando può aiutarti a comprendere le configurazioni del proxy Cloud Service Mesh:
TYPE: uno dei seguenti: cluster, listeners, route, endpoint, bootstrap, log, secret, all.
MEMBERSHIP_NAME: il nome del tuo abbonamento.
MEMBERSHIP_LOCATION: la regione per il tuo abbonamento. Puoi controllare la posizione del tuo abbonamento con
gcloud container fleet memberships list --project FLEET_PROJECT_ID
sostituendo FLEET_PROJECT_ID con l'ID progetto del fleet.
PROJECT_NAME: il nome del progetto.
All'interno del cluster
Utilizza istioctl proxy-config per visualizzare le configurazioni dei proxy per i piani di controllo all'interno del cluster. Per ulteriori informazioni, consulta la sezione Eseguire il debug di Envoy e istiod.
Se il problema persiste, consulta la sezione successiva per verificare se è già noto.
Problemi e soluzioni comuni
Per risparmiare tempo, controlla se i sintomi corrispondono a un problema descritto in queste sezioni relative a problemi e soluzioni comuni, raggruppate per area funzionale di Cloud Service Mesh:
Se il problema persiste, consulta la sezione successiva.
Restringi l'ambito del problema
Cloud Service Mesh è costituito da diverse tecnologie che operano insieme, il che significa che determinati tipi di problemi sono associati a particolari aree funzionali o componenti. Ciascuno di questi componenti genera i propri log utili. Prima di tentare di analizzare manualmente il volume di informazioni fornite, limita l'ambito della risoluzione dei problemi rispondendo alle seguenti domande:
Il problema si verifica nel piano di controllo o nel piano dati, ad esempio nei proxy istiod o Envoy?
In quale area funzionale si verifica il problema, ad esempio Networking, Telemetry, Security e così via?
Si verifica una perdita di traffico a livello di service mesh o in un deployment specifico?
Il problema si verifica o peggiora a causa della mancanza di capacità di scalare il traffico nel mesh di servizi?
Il problema causa latenza o altri problemi di prestazioni?
Puoi riprodurre il problema su richiesta?
Il problema è iniziato dopo una recente modifica della configurazione in Istio, GKE e così via?
Si è verificato un aumento o un picco di traffico all'interno del service mesh?
Questo cluster ha funzionalità notevoli abilitate o implementazioni non standard?
Noti un utilizzo elevato di CPU o memoria? In caso affermativo, qual è l'utilizzo previsto su larga scala?
Ci sono limitazioni relative alle quote da considerare?
Esamina log e informazioni pertinenti
Dopo aver ristretto l'ambito del problema, puoi concentrarti su determinati log e informazioni in modo più efficace. Per informazioni sui log generati da Cloud Service Mesh e su come interpretare le informazioni in essi contenute, consulta Interpretazione dei log di Cloud Service Mesh.
[[["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-02 UTC."],[],[],null,["# Troubleshoot Cloud Service Mesh step-by-step\n============================================\n\nThis section explains how to troubleshoot and resolve problems when using\nCloud Service Mesh. If you need additional assistance, see\n[Getting support](/service-mesh/docs/getting-support).\n\nTroubleshooting steps\n---------------------\n\nFollow these general steps to troubleshoot Cloud Service Mesh:\n\n1. Use the automated configuration validation tools.\n2. Check if you have a common problem with a known solution.\n3. Narrow the scope of the problem.\n4. Review relevant logs and information.\n5. Gather diagnostic logs and seek help.\n\n| **Note:** If you are unable to troubleshoot manually, see [Gather diagnostic logs and seek help](/service-mesh/docs/troubleshooting/troubleshoot-collect-logs) for next steps.\n\nThe Cloud Service Mesh diagnostic tool can detect common configuration\nproblems. Install the troubleshooting tool using these\n[instructions](/service-mesh/docs/downloading-istioctl).\n\nBefore you begin\n----------------\n\n1. Make sure the kubeconfig context for your cluster is available in your\n kubeconfig file. If not, then run the following command:\n\n gcloud container clusters get-credentials \u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e \\\n --location=\u003cvar translate=\"no\"\u003eCLUSTER_LOCATION\u003c/var\u003e --project=\u003cvar translate=\"no\"\u003ePROJECT_NAME\u003c/var\u003e\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e: the name of your cluster.\n - \u003cvar translate=\"no\"\u003eCLUSTER_LOCATION\u003c/var\u003e: the zone or region for your cluster.\n - \u003cvar translate=\"no\"\u003ePROJECT_NAME\u003c/var\u003e: the project name.\n2. Verify that the [Application Default Credentials](/authentication/provide-credentials-adc)\n are created. If they are not, run one of the following commands:\n\n gcloud auth application-default login --billing-project=\u003cvar translate=\"no\"\u003ePROJECT_NAME\u003c/var\u003e\n\n gcloud auth application-default set-quota-project \u003cvar translate=\"no\"\u003ePROJECT_NAME\u003c/var\u003e\n\n Replacing \u003cvar translate=\"no\"\u003ePROJECT_NAME\u003c/var\u003e with the your project name.\n\nView control plane status\n-------------------------\n\nThe following commands can help you understand the status of the\nCloud Service Mesh control plane: \n\n### Managed\n\n- Get the list of clients connection status to the Cloud Service Mesh control plane:\n\n gcloud beta container fleet mesh debug proxy-status \\\n --membership=\u003cvar translate=\"no\"\u003eMEMBERSHIP_NAME\u003c/var\u003e \\\n --location=\u003cvar translate=\"no\"\u003eMEMBERSHIP_LOCATION\u003c/var\u003e \\\n --project=\u003cvar translate=\"no\"\u003ePROJECT_NAME\u003c/var\u003e\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003eMEMBERSHIP_NAME\u003c/var\u003e: the name of your membership.\n - \u003cvar translate=\"no\"\u003eMEMBERSHIP_LOCATION\u003c/var\u003e: the region for your membership. You can check your membership's location with `gcloud container fleet memberships list --project `\u003cvar translate=\"no\"\u003eFLEET_PROJECT_ID\u003c/var\u003e replacing \u003cvar translate=\"no\"\u003eFLEET_PROJECT_ID\u003c/var\u003e with the fleet project ID.\n - \u003cvar translate=\"no\"\u003ePROJECT_NAME\u003c/var\u003e: the project name.\n\n The following table describes the possible responses.\n\n### In-cluster\n\n- `kubectl get pods -n istio-system`\n- `kubectl describe -n istio-system`\n- For all pods in istio-system: `kubectl logs -n istio-system -l istio --all-containers`\n- `istioctl version`\n- `istioctl proxy-status`\n- `kubectl get configmap istio -o yaml && kubectl get configmap istio-sidecar-injector -o yaml`\n- `kubectl top pods -n istio-system`\n\nUse the following commands to understand the scale of the deployment:\n\n- `kubectl get nodes`\n- `kubectl get services --all-namespaces`\n- `kubectl get pods --all-namespaces`\n\nView proxy configurations\n-------------------------\n\nThe following command can help you understand the Cloud Service Mesh proxy\nconfigurations: \n\n### Managed\n\n gcloud beta container fleet mesh debug proxy-config \u003cvar translate=\"no\"\u003ePOD_NAME\u003c/var\u003e.\u003cvar translate=\"no\"\u003eNAMESPACE\u003c/var\u003e \\ \n --type=\u003cvar translate=\"no\"\u003eTYPE\u003c/var\u003e \\\n --membership=\u003cvar translate=\"no\"\u003eMEMBERSHIP_NAME\u003c/var\u003e \\\n --location=\u003cvar translate=\"no\"\u003eMEMBERSHIP_LOCATION\u003c/var\u003e \\\n --project=\u003cvar translate=\"no\"\u003ePROJECT_NAME\u003c/var\u003e\n\n- \u003cvar translate=\"no\"\u003ePOD_NAME\u003c/var\u003e: the name of your Pod.\n- \u003cvar translate=\"no\"\u003eNAMESPACE\u003c/var\u003e: the namespace of your Pod.\n- \u003cvar translate=\"no\"\u003eTYPE\u003c/var\u003e: One of for following: cluster, listeners, routes, endpoints, bootstrap, log, secret, all.\n- \u003cvar translate=\"no\"\u003eMEMBERSHIP_NAME\u003c/var\u003e: the name of your membership.\n- \u003cvar translate=\"no\"\u003eMEMBERSHIP_LOCATION\u003c/var\u003e: the region for your membership. You can check your membership's location with `gcloud container fleet memberships list --project `\u003cvar translate=\"no\"\u003eFLEET_PROJECT_ID\u003c/var\u003e replacing \u003cvar translate=\"no\"\u003eFLEET_PROJECT_ID\u003c/var\u003e with the fleet project ID.\n- \u003cvar translate=\"no\"\u003ePROJECT_NAME\u003c/var\u003e: the project name.\n\n### In-cluster\n\nUse the `istioctl proxy-config` to see proxy configurations for in-cluster\ncontrol planes. For more information, see\n[Debugging Envoy and istiod](https://istio.io/latest/docs/ops/diagnostic-tools/proxy-cmd/).\n\nIf the problem persists, see the next section to check if your problem is\nalready known.\n\nCheck for common problems and solutions\n---------------------------------------\n\nYou can save time by checking if your symptoms match an issue in these common\nproblems and resolutions sections, grouped by Cloud Service Mesh functional\narea:\n\n- [Installation issues](/service-mesh/docs/troubleshooting/troubleshoot-installation)\n- [Managed control plane issues](/service-mesh/docs/managed/troubleshoot-managed-anthos-service-mesh)\n- [Observability issues](/service-mesh/docs/troubleshooting/troubleshoot-observability)\n- [Off-Google Cloud deployment issues](/service-mesh/docs/troubleshooting/troubleshoot-off-gcp)\n- [Proxy issues](/service-mesh/docs/troubleshooting/troubleshoot-proxy)\n- [Resource issues](/service-mesh/docs/troubleshooting/troubleshoot-resources)\n- [Scaling issues](/service-mesh/docs/troubleshooting/troubleshoot-scaling)\n- [Security issues](/service-mesh/docs/troubleshooting/troubleshoot-security)\n- [Traffic management issues](/service-mesh/docs/troubleshooting/troubleshoot-traffic)\n- [Webhook issues](/service-mesh/docs/troubleshooting/troubleshoot-webhook)\n- [Sidecar proxies issues](/service-mesh/docs/troubleshooting/troubleshoot-sidecar-proxies)\n\nIf this does not resolve your issue, see the next section.\n\nNarrow the scope of the problem\n-------------------------------\n\nCloud Service Mesh consists of several technologies working together, which means\nthat certain types of problems are associated with particular functional areas\nor components. Each of these components generate helpful logs of their own. Before\nyou attempt to manually analyze the volume of information they provide, narrow\nthe scope of your troubleshooting by answering the following questions:\n\n- Does the issue occur within the control plane or the data plane, for example `istiod` or Envoy proxies?\n- In which functional area are you experiencing the issue, for example Networking, Telemetry, Security, etc.?\n- Is there service-mesh wide traffic loss or in a specific deployment?\n- Does the problem appear or worsen due to lack of ability to scale traffic in service mesh?\n- Does the issue cause latency or other performance issues?\n- Can you reproduce the issue on demand?\n- Did the problem begin after a recent configuration change in Istio, GKE, etc.?\n- Is there an increase or spike in traffic within the service mesh?\n- Does this cluster have any noticeable features enabled or non-typical deployments?\n- Do you observe high CPU or memory utilization? If so, what is the expected usaged at scale?\n- Are there quota restrictions to consider?\n\nReview relevant logs and information\n------------------------------------\n\nAfter you narrow the scope of the problem, you can focus on certain logs and\ninformation more effectively. To learn about the logs that Cloud Service Mesh\ngenerates and how to interpret the information they contain, see\n[Interpreting Cloud Service Mesh logs](/service-mesh/docs/observability/accessing-logs#interpret_anthos_service_mesh_logs)."]]
