Anthos Service Mesh et Traffic Director sont désormais Cloud Service Mesh. Pour en savoir plus, consultez la page Présentation de Cloud Service Mesh.

Cette page a été traduite par l'API Cloud Translation.

Résolvez les problèmes de Cloud Service Mesh étape par étape

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 ces étapes générales 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 de Cloud Service Mesh peut détecter les problèmes de configuration courants. Installez l'outil de dépannage en suivant 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:
```
gcloud container clusters get-credentials CLUSTER_NAME \
    --location=CLUSTER_LOCATION --project=PROJECT_NAME
```
Remplacez les éléments suivants :
- CLUSTER_NAME : nom du cluster
- CLUSTER_LOCATION: zone ou région de votre cluster.
- PROJECT_NAME : nom du projet
Vérifiez que les identifiants par défaut de l'application sont créés. Si ce n'est pas le cas, exécutez l'une des commandes suivantes:
```
gcloud auth application-default login --billing-project=PROJECT_NAME
```
```
gcloud auth application-default set-quota-project PROJECT_NAME
```
Remplacez PROJECT_NAME par le nom de votre projet.

Afficher l'état du plan de contrôle

Les commandes suivantes peuvent vous aider à comprendre l'état du plan de contrôle de Cloud Service Mesh:

Géré

Obtenez la liste des états de connexion des clients au plan de contrôle Cloud Service Mesh:

gcloud beta container fleet mesh debug proxy-status \
    --membership=MEMBERSHIP_NAME \
    --location=MEMBERSHIP_LOCATION \
    --project=PROJECT_NAME

Remplacez les éléments suivants :

MEMBERSHIP_NAME: nom de votre abonnement.
MEMBERSHIP_LOCATION: région de votre abonnement. Vous pouvez vérifier l'emplacement de votre adhésion en remplaçant FLEET_PROJECT_ID par l'ID de projet de parc dans gcloud container fleet memberships list --project FLEET_PROJECT_ID.
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 du client.
ERREUR	⁣Le plan de contrôle a envoyé la configuration au client et a reçu du client un message NACK.
STALE (STALE)	Le plan de contrôle a envoyé la configuration au client, mais n'a reçu ni ACK, ni ACK du client.
NON ENVOYÉ	La configuration n'a pas été envoyée.
Non disponible	Non applicable.
Non compatible	L'état de synchronisation n'est pas compatible avec 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 du proxy Cloud Service Mesh:

Géré

gcloud beta container fleet mesh debug proxy-config POD_NAME.NAMESPACE \ 
    --type=TYPE \
    --membership=MEMBERSHIP_NAME \
    --location=MEMBERSHIP_LOCATION \
    --project=PROJECT_NAME

POD_NAME : nom de votre pod.
NAMESPACE : espace de noms de votre pod.
TYPE : cluster, écouteurs, routes, points de terminaison, amorçage, journal, secret, tout.
MEMBERSHIP_NAME: nom de votre abonnement.
MEMBERSHIP_LOCATION: région de votre abonnement. Vous pouvez vérifier l'emplacement de votre adhésion en remplaçant FLEET_PROJECT_ID par l'ID de projet de parc dans gcloud container fleet memberships list --project FLEET_PROJECT_ID.
PROJECT_NAME : nom du projet

Dans le cluster

Utilisez istioctl proxy-config pour afficher les configurations de proxy pour les plans de contrôle dans le cluster. Pour en savoir plus, consultez la section Débogage 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 dans ces sections sur les problèmes courants et leurs résolutions, regroupé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 domaines ou composants 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 sur l'interprétation des informations qu'ils contiennent, consultez la page Interpréter les journaux Cloud Service Mesh.