Résoudre les problèmes de gestion du trafic 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.

Erreurs de connexion au serveur d'API dans les journaux Istiod

Istiod ne parvient pas à contacter apiserver si vous rencontrez des erreurs semblables à celles-ci :

error k8s.io/client-go@v0.18.0/tools/cache/reflector.go:125: Failed to watch *crd.IstioSomeCustomResource`…dial tcp 10.43.240.1:443: connect: connection refused

Vous pouvez utiliser la chaîne d'expression régulière /error.*cannot list resource/ pour rechercher cette erreur dans les journaux.

Cette erreur est généralement temporaire. Si vous avez pu accéder aux journaux de proxy à l'aide de kubectl, le problème est peut-être déjà être résolu. Cette erreur est généralement due à des événements qui rendent le serveur d'API temporairement indisponible, par exemple lorsqu'un serveur d'API ne figurant pas dans une configuration de haute disponibilité redémarre en raison d'une mise à niveau ou d'un autoscaling.

Le conteneur istio-init plante

Ce problème peut se produire lorsque les règles iptables du pod ne sont pas appliquées à l'espace de noms réseau du pod. Cela peut être dû aux raisons suivantes :

  • Règle de sécurité des pods trop restrictive
  • Installation istio-cni incomplète
  • Autorisations de pod de charge de travail insuffisantes (autorisation CAP_NET_ADMIN manquante)

Si vous utilisez une règle de sécurité des pods qui limite l'autorisation CAP_NET_ADMIN, passez au plug-in CNI Istio.

Si vous utilisez le plug-in CNI Istio, vérifiez que vous avez bien suivi les instructions. Vérifiez que le conteneur istio-cni-node est prêt et vérifiez les journaux. Si le problème persiste, établissez une interface système sécurisée (SSH) dans le nœud hôte, puis recherchez les commandes nsenter dans les journaux de nœud pour voir s'il existe des erreurs.

Si vous n'utilisez pas le plug-in CNI Istio ou une règle de sécurité des pods, vérifiez que le pod de la charge de travail dispose de l'autorisation CAP_NET_ADMIN, qui est automatiquement définie par l'injecteur side-car.

Connexion refusée après le démarrage du pod

Lorsqu'un pod démarre et obtient une réponse connection refused quand il tente de se connecter à un point de terminaison, le problème peut être dû au fait que le conteneur d'application a démarré avant le conteneur isto-proxy. Dans ce cas, le conteneur d'application envoie la requête à istio-proxy, mais la connexion est refusée, car istio-proxy n'écoute pas encore sur le port.

Dans ce cas, vous pouvez effectuer les modifications suivantes :

  • Modifiez le code de démarrage de votre application afin d'envoyer des requêtes continues au point de terminaison d'état "health" istio-proxy jusqu'à ce que l'application reçoive un code 200. Le point de terminaison d'état "health" istio-proxy est le suivant :

    http://localhost:15020/healthz/ready

  • Ajoutez un mécanisme de nouvelle tentative de requête à la charge de travail de votre application.