Dépanner Cloud Service Mesh étape par étape

Cette section explique comment dépanner et résoudre les problèmes lors de l'utilisation 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:

1. Utilisez les outils automatisés de validation.
2. Vérifiez si vous rencontrez un problème courant dont la solution est connue.
3. Affinez le champ d'application du problème.
4. Examinez les informations et les journaux pertinents.
5. Recueillez les journaux de diagnostic et demandez de l'aide.

Remarque : Si vous ne parvenez pas à résoudre vos problèmes manuellement, consultez la section Collecter des journaux de diagnostic et obtenir de l'aide pour connaître les étapes suivantes.

L'outil de diagnostic de Cloud Service Mesh peut détecter les configurations courantes des problèmes. Installez l'outil de dépannage à l'aide de ces instructions.

Avant de commencer

1. 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

2. Vérifiez que les identifiants par défaut de l'application sont créées. 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 Plan de contrôle 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 . Vous pouvez vérifier la localisation de votre abonnement avec gcloud container fleet memberships list --project FLEET_PROJECT_ID Remplacement de FLEET_PROJECT_ID par le projet de parc 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.
  SYNCED	Le plan de contrôle a envoyé la configuration au client et reçu un accusé de réception de la part du client.
  ERREUR	⁣ Le plan de contrôle a envoyé la configuration au client et reçu un NACK de sa part.
  IGNORER	Le plan de contrôle a envoyé la configuration au client, mais n'a reçu aucun ACK ni NACK de sa part.
  NON ENVOYÉ	La configuration n'a pas été envoyée.
  N/A	Non applicable.
  Non compatible	L'état de 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 le proxy Cloud Service Mesh configurations:

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: l'un des éléments suivants: cluster, écouteurs, routes, points de terminaison, amorçage, journal, secret, tout.
• MEMBERSHIP_NAME: nom de votre abonnement.
• MEMBERSHIP_LOCATION: région de votre . Vous pouvez vérifier la localisation de votre abonnement avec gcloud container fleet memberships list --project FLEET_PROJECT_ID Remplacement de FLEET_PROJECT_ID par le projet de parc ID.
• PROJECT_NAME : nom du projet

Dans le cluster

Utiliser le istioctl proxy-config pour afficher les configurations de proxy pour le cluster les plans de contrôle. Pour en savoir plus, consultez 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 dans ces sections des problèmes et des résolutions, regroupées par fonctionnalité Cloud Service Mesh domaine:

• Problèmes d'installation
• Problèmes liés au plan de contrôle géré
• Problèmes d'observabilité
• Problèmes de déploiement hors de Google Cloud
• Problèmes de proxy
• Problèmes liés aux ressources
• Problèmes de scaling
• Problèmes de sécurité
• Problèmes de gestion du trafic
• Problèmes liés aux webhooks
• Problèmes liés aux proxys side-car

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 fonctionnels particuliers ou composants. 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 utilisés par Cloud Service Mesh génère et comment interpréter les informations qu'elles contiennent, consultez Interpréter les journaux Cloud Service Mesh