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ésoudre les problèmes liés au proxy ou au webhook side-car dans le maillage de services Cloud

Cette section décrit les problèmes courants liés à Cloud Service Mesh et comment les résoudre. Si vous avez besoin d'une aide supplémentaire, consultez la page Obtenir de l'aide.

Cloud Service Mesh contient deux webhooks:

Le webhook de validation vérifie que la configuration d'Istio appliquée est valide.
Le webhook de mutation définit l'injection side-car automatique sur les nouveaux pods.

Si un problème de configuration se produit dans l'un de ces webhooks, cela peut entraîner l'échec du démarrage des nouveaux pods ou la génération de messages d'erreur par kubectl apply.

Problèmes d'injection side-car

Si vous avez provisionné le maillage de services Cloud géré, contactez l'assistance.

L'injection sidecar ne fonctionne pas correctement si vous rencontrez certains des problèmes suivants :

Pods planifiés sans side-car
Les pods qui doivent avoir des side-cars injectés n'apparaissent jamais lorsque vous utilisez kubectl get pods, mais l'instance répliquée correspondante définie à partir de kubectl get replicaset existe.

Procédez comme suit pour résoudre les problèmes d'injection de side-car.

Vérifiez que l'espace de noms ou le pod comportent le bon libellé d'injection.

Si vous exécutez une seule version d'Istio (par défaut), vérifiez que votre spécification d'espace de noms ou de pod comporte le libellé istio-injection=enabled.

Si vous exécutez plusieurs révisions d'Istio (pour des migrations sans temps d'arrêt, plusieurs plans de contrôle, etc.), vérifiez que votre spécification d'espace de noms ou de pod comporte le libellé istio.io/rev=REVISION approprié, où REVISION correspond au numéro de révision Cloud Service Mesh sur istiod correspondant à la version Cloud Service Mesh sélectionnée. Pour en savoir plus sur les libellés de révision, consultez la page Injecter des proxys side-car.
Vérifiez que le webhook d'injection side-car Istio est présent et dispose d'un groupe d'autorités de certification.

Le webhook d'injecteur side-car (utilisé pour l'injection side-car automatique) nécessite un groupe d'autorités de certification pour établir des connexions sécurisées avec le serveur d'API et istiod. Ce groupe d'autorités de certification est ajouté dans la configuration par istiod, mais peut parfois être écrasé (par exemple, si vous relancez la configuration du webhook).

Vous pouvez vérifier la présence du groupe d'autorités de certification à l'aide de la commande suivante. La commande inclut istio-sidecar-injector-, qui est spécifique à cette version de Cloud Service Mesh. Assurez-vous d'utiliser votre révision réelle si elle diffère.
```
kubectl get mutatingwebhookconfigurations.admissionregistration.k8s.io istio-sidecar-injector- -o=jsonpath='{.webhooks[0].clientConfig.caBundle}'
```
Si le résultat n'est pas vide, le groupe d'autorités de certification est configuré. Si le groupe d'autorités de certification est absent, redémarrez istiod pour qu'il analyse à nouveau le webhook, puis réinstallez le groupe d'autorités de certification.
Recherchez les échecs d'injection side-car.

Si l'injection est activée mais que vous ne voyez pas la planification des pods, vérifiez l'état du niveau supérieur d'abstraction. Par exemple, si vous exécutez un déploiement, mais qu'aucun pod n'est programmé, vérifiez l'état des ensembles d'instances dupliquées correspondants à l'aide de la commande suivante :
```
kubectl -n my-namespace describe replicaset your-deployment-name
```
Si l'ensemble d'instances dupliquées est présent, cherchez d'éventuelles erreurs dans le journal des événements en bas de la description. Si l'erreur concerne l'injection side-car, consultez les journaux istiod pour obtenir une indication de l'origine de l'erreur.
Si le problème persiste, il peut s'agir de l'un des problèmes suivants :
- Configuration incorrecte transmise à l'injecteur
- Problèmes de configuration du pare-feu
- Problème dans le code Istio lui-même
Consultez la page Résoudre les problèmes liés à Istio pour découvrir d'autres étapes de diagnostic.

Les proxys Envoy ne reçoivent pas la configuration d'`istiod`

Plusieurs problèmes peuvent empêcher les proxys de recevoir la configuration d'istiod.

istiod ne transmettra pas la configuration aux proxys Envoy en cas de problème, par exemple un problème RBAC qui l'empêche de lire sa ressource de configuration.
L'adresse de découverte est incorrecte (erreurs "pas de flux opérationnel en amont")
Adresse de découverte fournie à l'injecteur side-car incorrecte. Si vous voyez des journaux mentionnant gRPC config stream closed, no healthy upstream, vérifiez que l'adresse de découverte dans le maillage ProxyConfig est correcte et pointe vers votre service istiod.
Configuration non valide transmise au proxy. Dans ce cas, la configuration est transmise au proxy, mais elle n'est pas valide. Vous verrez des messages récurrents semblables à celui-ci :
```
Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 1 successful, 0 rejected; lds updates: 0 successful, 1 rejected
```
Dans cet exemple, cds est le service de découverte de clusters (qui signale 1 mise à jour transmise à partir de istiod) et lds est le service de détection d'écouteurs (qui signale 1 mise à jour refusée depuis istiod). Vous verrez souvent un message d'erreur plus ancien qui explique la raison du refus, qui commence généralement par un avertissement concernant la configuration Envoy ou similaire.

Pour résoudre le problème, examinez la cause de refus de la configuration. Les ressources EnvoyFilter sont une cause fréquente. Si aucun motif n'est évident, envoyez un rapport de bug avec un vidage de configuration du proxy.

Échec de création du pod

Si vous constatez que des pods ne sont pas correctement créés, recherchez des messages d'erreur pouvant donner des indications sur le problème racine, à l'aide de la commande suivante :

kubectl describe replicaset YOUR_REPLICA_SET

Messages d'erreur courants du webhook

Les messages d'erreur associés à l'utilisation de la commande kubectl apply peuvent fournir des indications sur l'origine du problème. Consultez le tableau suivant pour connaître les messages d'erreur courants, leurs causes et les solutions potentielles.

Message d'erreur	Cause	Solution
`net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)`	Il peut s'agir d'un problème de connectivité réseau.	Vérifiez que vos règles de pare-feu fournissent une connectivité à "istiod" sur le port 15017.
`no endpoints available for service 'istiod'`	Cela peut se produire si le pod "istiod" n'est pas disponible ou n'est pas prêt.	Vérifiez les pods "istiod" pour vous assurer qu'ils sont en cours d'exécution et prêts.
`Service "istiod" not found`	Cela peut se produire si le service "Istiod" n'existe pas.	Vérifiez que l'installation d'Istio a bien été effectuée et qu'elle est correcte.
`x509: certificate signed by unknown authority`	Il peut s'agir d'un problème de certificat de webhook.	Vérifiez que `caBundle` est correctement défini sur le webhook.
`Failed to update validatingwebhookconfiguration istio-validator-asm-[version-n]-istio-system (failurePolicy=Fail, resourceVersion=[version]): Operation cannot be fulfilled on validatingwebhookconfigurations.admissionregistration.k8s.io "istio-validator-asm-[version-n]-istio-system": the object has been modified; please apply your changes to the latest version and try again.`	Un webhook de validation issu d'une ancienne version d'Istio ou de Cloud Service Mesh qui a été désinstallée peut interférer avec une mise à niveau ou une installation.	Vérifiez que tous les webhooks sont toujours présents dans le cluster et supprimez tous les webhooks qui font référence à des versions qui ne sont plus installées.
`Error from server (InternalError): Internal error occurred: failed calling webhook "rev.namespace.sidecar-injector.istio.io": Post "https://istiod-asm-1122-0.istio-system.svc:443/inject?timeout=10s": context deadline exceeded`	Pour les clusters privés, le port 15017 doit être ouvert. Ce message d'erreur indique que le port 15017 n'est peut-être pas ouvert.	Assurez-vous que vos règles de pare-feu fournissent une connectivité à Istiod sur le port 15017. Pour plus d'informations, consultez la section Ouvrir un port sur un cluster privé.