Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Résoudre les problèmes liés à Cloud Service Mesh
Cette section explique comment résoudre les problèmes liés à l'utilisation de Cloud Service Mesh. Si vous avez besoin d'une aide supplémentaire, consultez la page Obtenir de l'aide.
Procédure de dépannage
Suivez les étapes générales ci-dessous pour résoudre les problèmes liés à Cloud Service Mesh:
Utilisez les outils automatisés de validation.
Vérifiez si vous rencontrez un problème courant dont la solution est connue.
Affinez le champ d'application du problème.
Examinez les informations et les journaux pertinents.
Recueillez les journaux de diagnostic et demandez de l'aide.
L'outil de diagnostic Cloud Service Mesh peut détecter les problèmes de configuration courants. Installez l'outil de dépannage en suivant ces instructions.
Avant de commencer
Assurez-vous que le contexte kubeconfig de votre cluster est disponible dans votre fichier kubeconfig. Si ce n'est pas le cas, exécutez la commande suivante:
MEMBERSHIP_LOCATION: région de votre adhésion. Vous pouvez vérifier l'emplacement de votre appartenance avec gcloud container fleet memberships list --project FLEET_PROJECT_ID en remplaçant FLEET_PROJECT_ID par l'ID du projet de parc.
PROJECT_NAME : nom du projet
Le tableau suivant décrit les réponses possibles.
INCONNU
(Par défaut) Les informations sur l'état ne sont pas disponibles ou sont inconnues.
SYNCHRONISÉ
Le plan de contrôle a envoyé la configuration au client et a reçu un ACK de sa part.
ERREUR
Le plan de contrôle a envoyé la configuration au client et a reçu un NACK de sa part.
STALE
Le plan de contrôle a envoyé la configuration au client, mais n'a pas reçu d'ACK ni de NACK de sa part.
NON ENVOYÉ
La configuration n'a pas été envoyée.
N/A
Non applicable.
Non compatible
L'état de la synchronisation n'est pas pris en charge par notre API de dépannage.
Dans le cluster
kubectl get pods -n istio-system
kubectl describe -n istio-system
Pour tous les pods dans 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
Utilisez les commandes suivantes pour comprendre l'ampleur du déploiement :
kubectl get nodes
kubectl get services --all-namespaces
kubectl get pods --all-namespaces
Afficher les configurations de proxy
La commande suivante peut vous aider à comprendre les configurations de proxy Cloud Service Mesh:
TYPE: l'un des éléments suivants: cluster, écouteurs, routes, points de terminaison, bootstrap, journal, secret, tout.
MEMBERSHIP_NAME: nom de votre abonnement.
MEMBERSHIP_LOCATION: région de votre adhésion. Vous pouvez vérifier l'emplacement de votre appartenance avec gcloud container fleet memberships list --project FLEET_PROJECT_ID en remplaçant FLEET_PROJECT_ID par l'ID du projet de parc.
PROJECT_NAME : nom du projet
Dans le cluster
Utilisez istioctl proxy-config pour afficher les configurations de proxy pour les plans de contrôle au sein du cluster. Pour en savoir plus, consultez la section Déboguer Envoy et istiod.
Si le problème persiste, consultez la section suivante pour vérifier si votre problème est déjà connu.
Rechercher des problèmes courants et leurs solutions
Vous pouvez gagner du temps en vérifiant si vos symptômes correspondent à un problème figurant déjà dans les sections sur les problèmes courants et leurs solutions, qui sont groupées par domaine fonctionnel Cloud Service Mesh:
Si le problème persiste, consultez la section suivante.
Affiner le champ d'application du problème
Cloud Service Mesh repose sur plusieurs technologies qui fonctionnent ensemble, ce qui signifie que certains types de problèmes sont associés à des composants ou domaines fonctionnels spécifiques. Chacun de ces composants génère des journaux utiles. Avant de tenter d'analyser manuellement la grande quantité d'informations qu'ils fournissent, affinez le champ d'application de dépannage en répondant aux questions suivantes :
Le problème se produit-il dans le plan de contrôle ou le plan de données, par exemple istiod ou les proxys Envoy ?
Dans quel domaine fonctionnel rencontrez-vous le problème, par exemple la mise en réseau, la télémétrie, la sécurité, etc. ?
Y a-t-il une perte de trafic à l'échelle du maillage de services ou dans un déploiement spécifique ?
Le problème apparaît-il ou s'aggrave-t-il en raison d'une incapacité à adapter le trafic au maillage de services ?
Le problème peut-il causer une latence ou d'autres problèmes de performances ?
Pouvez-vous reproduire le problème sur demande ?
Le problème a-t-il commencé après une modification récente de la configuration dans Istio, GKE, etc. ?
Y a-t-il une augmentation ou un pic de trafic dans le maillage de services ?
Des fonctionnalités notables sont-elles activées pour ce cluster, ou celui-ci comporte-t-il des déploiements inhabituels ?
Observez-vous une utilisation intensive du processeur ou de la mémoire ? Si oui, quelle est l'utilisation prévue à grande échelle ?
Existe-t-il des restrictions de quota à prendre en compte ?
Examiner les informations et les journaux pertinents
Une fois que vous avez déterminé le champ d'application du problème, vous pouvez vous concentrer sur certains journaux et certaines informations de manière plus efficace. Pour en savoir plus sur les journaux générés par Cloud Service Mesh et apprendre à interpréter les informations qu'ils contiennent, consultez la page Interpréter les journaux Cloud Service Mesh.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/04 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/04 (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/v1.24/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/v1.24/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/v1.24/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/v1.24/docs/troubleshooting/troubleshoot-installation)\n- [Managed control plane issues](/service-mesh/v1.24/docs/managed/troubleshoot-managed-anthos-service-mesh)\n- [Observability issues](/service-mesh/v1.24/docs/troubleshooting/troubleshoot-observability)\n- [Off-Google Cloud deployment issues](/service-mesh/v1.24/docs/troubleshooting/troubleshoot-off-gcp)\n- [Proxy issues](/service-mesh/v1.24/docs/troubleshooting/troubleshoot-proxy)\n- [Resource issues](/service-mesh/v1.24/docs/troubleshooting/troubleshoot-resources)\n- [Scaling issues](/service-mesh/v1.24/docs/troubleshooting/troubleshoot-scaling)\n- [Security issues](/service-mesh/v1.24/docs/troubleshooting/troubleshoot-security)\n- [Traffic management issues](/service-mesh/v1.24/docs/troubleshooting/troubleshoot-traffic)\n- [Webhook issues](/service-mesh/v1.24/docs/troubleshooting/troubleshoot-webhook)\n- [Sidecar proxies issues](/service-mesh/v1.24/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/v1.24/docs/observability/accessing-logs#interpret_anthos_service_mesh_logs)."]]