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

Cette section explique les problèmes couramment rencontrés dans Anthos Service Mesh et indique comment les résoudre. Si vous avez besoin d'une aide supplémentaire, consultez la page Assistance.

Anthos 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

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

  • Pods planifiés sans side-car
  • Pods qui devraient être dotés de side-cars injectés, mais qui ne s'affichent jamais lors de l'exécution de la commande kubectl get pods alors que l'instance dupliquée correspondante définie par kubectl get replicaset existe.

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

  1. 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 versions d'Istio (pour les migrations sans interruption, plusieurs plans de contrôle, etc.), vérifiez que votre spécification de l'espace de noms ou du pod dispose du libellé istio.io/rev=REVISION approprié, où REVISION est le numéro de révision d'Anthos Service Mesh sur istiod, qui correspond à la version d'Anthos Service Mesh sélectionnée. Pour en savoir plus sur les libellés de révision, consultez la section Injecter des proxys side-car.

  2. 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 :

    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.

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

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

  1. En cas de problèmes, par exemple un problème RBAC qui empêche la lecture de sa ressource de configuration, istiod ne transfère pas la configuration aux proxys Envoy.

  2. L'adresse de découverte est incorrecte (erreurs "pas de flux opérationnel en amont")

  3. 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 du maillage ProxyConfig est correcte et pointe vers votre service istiod.

  4. 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étection de clusters (qui signale une mise à jour transmise depuis istiod) et lds est le service de détection d'écouteurs (qui signale une mise à jour refusée par istiod). Souvent, un message d'erreur plus détaillé s'affiche et explique la raison du refus. Il commence généralement par un avertissement sur 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 provenant d'une ancienne version d'Istio ou d'Anthos Service Mesh désinstallé 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é.