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.

Répertorier des passerelles renvoie des valeurs vides

Problème constaté : lorsque vous répertoriez des passerelles à l'aide de kubectl get gateway --all-namespaces après avoir créé une passerelle Anthos Service Mesh, la commande renvoie No resources found.

Ce problème peut survenir sur GKE 1.20 et versions ultérieures, car le contrôleur de passerelle GKE installe automatiquement la ressource GKE Gateway.networking.x-k8s.io/v1alpha1 dans les clusters. Pour contourner ce problème, procédez comme suit :

  1. Vérifiez si le cluster comporte plusieurs ressources personnalisées de passerelle :

    kubectl api-resources | grep gateway

    Exemple de résultat : 

    gateways                          gw           networking.istio.io/v1beta1            true         Gateway
gatewayclasses                    gc           networking.x-k8s.io/v1alpha1           false        GatewayClass
gateways                          gtw          networking.x-k8s.io/v1alpha1           true         Gateway

  2. Si la liste affiche des entrées autres que des passerelles avec apiVersionnetworking.istio.io/v1beta1, utilisez le nom complet de la ressource ou les noms courts qui se distinguent facilement dans la commande kubectl. Par exemple, exécutez kubectl get gw ou kubectl get gateways.networking.istio.io au lieu de kubectl get gateway pour vous assurer que les passerelles Istio sont répertoriées.

Pour en savoir plus sur ce problème, consultez la page Passerelles Kubernetes et passerelles Istio.