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

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

Résoudre les problèmes de proxy side-car/webhook dans Cloud Service Mesh

Cette section décrit les problèmes courants liés à Cloud Service Mesh et explique comment les résoudre de l'IA générative. 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 service géré Cloud Service Mesh, 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 auxquels des side-cars injectés ne s'affichent jamais lors de l'utilisation kubectl get pods, mais l'ensemble d'instances répliquées correspondant 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 Istio (pour les migrations sans temps d'arrêt, plusieurs plans de contrôle, etc.), vérifiez que la spécification de votre espace de noms ou de votre pod l'étiquette istio.io/rev=REVISION appropriée, où REVISION est le numéro de révision de Cloud Service Mesh dans istiod correspondant à la version de Cloud Service Mesh sélectionnée. Pour plus Pour plus d'informations sur les étiquettes de révision, consultez la section 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 inclut istio-sidecar-injector-asm-1214-5, qui est spécifique à cette version de Cloud Service Mesh. Assurez-vous d'utiliser votre véritable révision s'il diffère.
```
kubectl get mutatingwebhookconfigurations.admissionregistration.k8s.io istio-sidecar-injector-asm-1214-5 -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. tel qu’un problème RBAC l’empêchant 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 réseau maillé 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 correspond au service de découverte de cluster (qui signale 1 mise à jour transmise depuis istiod) et lds est le service de détection d'écouteurs. (qui signale 1 mise à jour refusée par istiod). Vous verrez souvent un message d'erreur précédent qui explique la raison du refus, ce 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 à partir d'une ancienne version d'Istio Cloud Service Mesh désinstallé peut interférer avec un 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 en savoir plus, consultez Ouvrir un port sur un cluster privé