Résoudre les problèmes de gestion du trafic dans Cloud Service Mesh

Cette section explique les problèmes couramment rencontrés dans Cloud 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 :

  • Installation istio-cni incomplète
  • Autorisations de pod de charge de travail insuffisantes (autorisation CAP_NET_ADMIN manquante)

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 consultez les journaux. Si le problème persiste, établissez une connexion Secure Shell (SSH) au nœud hôte, recherchez les commandes nsenter dans les journaux du nœud et vérifiez si des erreurs sont présentes.

Si vous n'utilisez pas le plug-in CNI Istio, 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 Cloud 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.

Le proxy Envoy se bloque lors de l'initialisation

Si les journaux de débogage indiquent que le proxy Envoy se bloque lors de l'initialisation, vous pouvez utiliser la commande suivante pour identifier ce qui bloque le processus :

kubectl -n <ns> -c istio-proxy exec -it POD_NAME -- /usr/local/bin/pilot-agent request POST /init_dump

Résoudre les problèmes liés aux erreurs de réponse HTTP 5xx

Vous pouvez rencontrer des erreurs de réponse HTTP 5xx lorsque vous accédez à des applications via la passerelle d'entrée Istio. Suivez ces étapes pour diagnostiquer et résoudre le problème.

  1. Identifier le plan de contrôle
  2. Vérifier les erreurs de configuration potentielles
  3. Vérifier la découverte des pods
  4. Analyser les journaux d'accès

Identifier le plan de contrôle

Déterminez la version et la configuration du plan de contrôle, car différentes versions peuvent influencer les processus de diagnostic. Pour vérifier l'état du plan de contrôle géré, exécutez la commande suivante :

gcloud container fleet mesh describe --project PROJECT_ID

L'état ACTIVE indique que le plan de contrôle géré fonctionne normalement.

Vérifier les erreurs de configuration potentielles

Les erreurs de configuration courantes peuvent entraîner des échecs de routage :

  • Incompatibilité d'espace de noms : le VirtualService doit se trouver dans le même espace de noms que le service GKE de backend.
  • Incompatibilité de référence de passerelle : le VirtualService doit faire référence explicitement au Gateway approprié. Par exemple, si le VirtualService fait référence à istio-system/istio-ingressgateway, mais que la passerelle se trouve dans l'espace de noms default, le trafic ne sera pas routé correctement.

Vérifier la découverte des pods

Assurez-vous que le pod d'application est correctement détecté par le maillage :

istioctl proxy-config endpoints POD_NAME

Analyser les journaux d'accès

Activez les journaux d'accès pour déterminer si les erreurs proviennent de l'application de backend ou du proxy. Les champs clés incluent RESPONSE_FLAGS, UPSTREAM_LOCAL_ADDRESS et RESPONSE_CODE.

Si les journaux indiquent des erreurs en amont, effectuez un test curl direct sur le service GKE à partir d'un pod dans le même espace de noms. Si la requête curl renvoie la même erreur 5xx, le problème provient de l'application de backend elle-même.

Résoudre les problèmes liés aux certificats SSL

Les erreurs de certificat SSL au niveau de la passerelle d'entrée Istio peuvent être dues à des certificats expirés, à des incompatibilités de protocole ou à des configurations de secret incorrectes.

Identifier les erreurs SSL

Consultez les journaux du pod de la passerelle d'entrée Istio :

kubectl logs -l app=istio-ingressgateway -n GATEWAY_NAMESPACE

Vérifier les certificats et les clés

Assurez-vous que le certificat et la clé privée sont valides et correspondent à l'aide de hachages MD5 :

openssl x509 -noout -modulus -in CERTIFICATE.CRT | openssl md5
openssl rsa -noout -modulus -in PRIVATE_KEY | openssl md5

Vérifiez que le certificat n'a pas expiré et que le nom commun (CN) ou l'autre nom de l'objet (SAN) correspond au domaine.

Vérifier le protocole TLS et la configuration du secret

Vérifiez la version TLS et les suites de chiffrement dans le CRD Gateway. Assurez-vous que le secret Kubernetes contenant le certificat et la clé se trouve dans le même espace de noms que la passerelle d'entrée et que le credentialName correspond au nom du secret.

Résoudre les problèmes de délais d'attente intermittents pour les points de terminaison externes

Des délais d'attente intermittents peuvent se produire lorsque des requêtes sont envoyées à des points de terminaison externes (tels que le NLB tiers) qui sont résolus en plusieurs adresses IP.

Cause possible : résolution ServiceEntry

Si spec.resolution est défini sur DNS, Istio utilise le "DNS strict", qui équilibre la charge sur toutes les adresses IP résolues. Certains NLB ne sont pas compatibles avec cette fonctionnalité.

Solution

Pour résoudre ce problème, définissez la résolution sur ServiceEntry sur DNS_ROUND_ROBIN.

Résoudre les problèmes de distribution inégale du trafic

Si le trafic n'est pas réparti de manière égale entre les pods d'application, vérifiez les points suivants :

  • État du pod : assurez-vous que tous les pods d'application étaient opérationnels pendant le déséquilibre.
  • Algorithme d'équilibrage de charge : examinez la configuration DestinationRule pour le paramètre loadBalancer (par exemple, consistentHash ou ROUND_ROBIN).
  • Équilibrage de charge de la localité : vérifiez si localityLbSetting est activé. Notez que cette fonctionnalité n'est pas compatible avec le plan de contrôle TRAFFIC_DIRECTOR.

Résoudre les problèmes de propagation de service et de quota

Si les nouveaux services ou les nouvelles configurations réseau ne sont pas reflétés dans le maillage, cela peut être dû au fait que les quotas de ressources ont été atteints dans le projet de flotte.

Symptômes

  • Les configurations Mise en réseau (telles que VirtualService ou DestinationRule) ne sont pas transmises aux proxys side-car.
  • Les nouveaux services apparaissent "invisibles" pour le réseau maillé, même s'ils sont correctement définis.

Étapes pour identifier et résoudre le problème

  1. Vérifier les quotas de ressources : vérifiez si le projet de flotte a atteint son quota pour les ressources BackendService en consultant le quota Services de backend du Traffic Director interne mondial dans le projet de flotte. Cloud Service Mesh crée généralement un BackendService par port de service Kubernetes.
  2. Examiner les limites de scaling : assurez-vous que votre configuration respecte les limites de scaling compatibles pour Cloud Service Mesh.
  3. Augmenter les quotas : si les quotas ont été atteints, demandez une augmentation pour la ressource concernée dans le projet de flotte afin de rétablir la propagation normale du service.

Résoudre les problèmes d'évaluation VirtualService

Si un VirtualService ne se comporte pas comme prévu, n'oubliez pas que les routes sont évaluées dans l'ordre dans lequel elles sont listées. Lorsque vous avez plusieurs services virtuels pour le même hôte, leurs routes sont fusionnées. Les routes des services virtuels "plus anciens" sont prioritaires et sont donc placées avant les routes des services virtuels "plus récents" dans la liste fusionnée. Cela renforce la règle de "première correspondance".

Résoudre les problèmes d'équilibrage de charge de la localité

Par défaut, l'équilibrage de charge de la localité dirige le trafic client vers les points de terminaison de la même zone (la zone principale ou la priorité 0). Envoy ne route le trafic vers les zones de basculement (priorité 1 ou supérieure) que lorsque les points de terminaison de la zone principale ne sont pas opérationnels ou ne sont pas disponibles.

Si vous ne mettez pas à l'échelle vos points de terminaison pour gérer l'ensemble de la charge zonale ou si vous préférez répartir le trafic entre les zones, procédez de l'une des manières suivantes :

  • Mettez à l'échelle les pods dans les zones respectives pour gérer la charge de trafic local.
  • Désactivez le paramètre d'équilibrage de charge de la localité.

Identifier les paramètres d'équilibrage de charge de la localité

L'équilibrage de charge de la localité s'appuie sur des libellés de topologie de nœud pour regrouper les points de terminaison. Pour vérifier les libellés de nœud et les paramètres, utilisez les commandes suivantes :

  • Vérifiez les libellés de topologie de nœud :

    kubectl get nodes -o custom-columns=NAME:.metadata.name,\
    REGION:.metadata.labels."topology\\.kubernetes\\.io/region",\
    ZONE:.metadata.labels."topology\\.kubernetes\\.io/zone"

  • Pour les DestinationRules GKE, inspectez les paramètres de localité :

    kubectl get destinationrule DESTINATION_RULE_NAME -o yaml

    Recherchez localityLbSetting: enabled: true dans le résultat.

  • Pour vérifier les points de terminaison, les priorités et l'état du proxy Envoy :

    istioctl proxy-config endpoints POD_NAME.NAMESPACE \
    --cluster "outbound|PORT||SERVICE_FQDN" -o json

    Recherchez le champ priority dans la configuration du point de terminaison.

  • Pour afficher la configuration détaillée des clusters actifs :

    istioctl proxy-config cluster POD_NAME.NAMESPACE \
    --fqdn SERVICE_FQDN -o json