Erreur UNAVAILABLE: io exception lors de la communication avec le service d'inventaire

Gwen Quinn 0 Points de réputation
2026-09-16T15:16:41.53+00:00

Le microservice de traitement des commandes génère une erreur "UNAVAILABLE: io exception" lorsqu'il tente de joindre le service d'inventaire. Comment vérifier le routage au sein du service mesh ?

Windows pour les entreprises | Windows 365 Business
0 commentaires Aucun commentaire

1 réponse

Trier par : Plus récent
  1. Harry Phan 33,805 Points de réputation Conseiller(ère) indépendant(e)
    2026-09-16T15:52:26.76+00:00

    Bonjour Gwen,

    L’erreur UNAVAILABLE: io exception indique que le microservice de traitement des commandes ne parvient pas à établir une connexion réseau stable avec le service d’inventaire. Dans un environnement basé sur un service mesh (par exemple Istio ou Linkerd), la première étape est de vérifier si le routage et la résolution DNS interne fonctionnent correctement.

    Commencez par exécuter un kubectl exec dans le pod du microservice de traitement des commandes et tentez un curl http://inventory-service:PORT/health ou l’endpoint équivalent. Si cela échoue, cela signifie que le routage au sein du mesh n’est pas correctement configuré. Vérifiez ensuite les règles de VirtualService et DestinationRule dans Istio : assurez-vous que le host correspond bien au nom DNS du service d’inventaire défini dans Kubernetes (inventory-service.namespace.svc.cluster.local). Une erreur fréquente est un mismatch entre le nom du service déclaré dans le mesh et celui utilisé par le client.

    Il est également important de contrôler les ServiceEntry si le trafic sortant est nécessaire, ainsi que les Sidecar envoyés par Istio qui peuvent restreindre le routage. Si vous utilisez Linkerd, vérifiez que le proxy sidecar est injecté dans les deux pods et que le service est bien découvert via le DNS interne. Enfin, inspectez les logs du proxy envoy (Istio) ou du proxy Linkerd pour voir si des erreurs de type connection refused ou no healthy upstream apparaissent, ce qui confirmerait un problème de routage ou de configuration de cluster.

    En résumé, concentrez-vous sur la résolution DNS interne, la configuration des VirtualService/DestinationRule, et les logs du proxy sidecar. C’est là que vous verrez si le routage est correctement établi ou bloqué.J'espère que vous avez trouvé ici des informations utiles. Si cela vous a permis de mieux comprendre le problème, n'hésitez pas à accepter la réponse. Si vous avez d'autres questions, n'hésitez pas à laisser un message. Bonne journée !

    HP.

    Cette réponse vous a-t-elle été utile?

    0 commentaires Aucun commentaire

Votre réponse

Les réponses peuvent être marquées comme « Acceptées » par l’auteur(e) de la question et « Recommandées » par les modérateurs, ce qui aide les utilisateurs à savoir que la réponse a résolu le problème de l’auteur(e).