Chaque sidecar Envoy d’un mesh génère déjà des métriques détaillées et des données de trace comme effet secondaire du traitement du trafic ; rien d’extra n’a besoin d’être ajouté à vos applications pour que ces données existent. Ce qui manque sans composants supplémentaires, c’est un endroit où les envoyer, les stocker et les consulter. Ce guide installe les éléments qui font cela et rendent réellement visible le trafic d’un mesh.

À quoi sert chaque add-on

• Prometheus collecte et stocke les métriques exposées par chaque sidecar : taux de requêtes, taux d’erreurs, latences, par service et par route. Les guides Prometheus dédiés de cette bibliothèque couvrent l’outil lui-même en profondeur ; ici, c’est spécifiquement le backend interrogé par les propres tableaux de bord d’Istio.
• Grafana visualise ces données Prometheus via des tableaux de bord Istio prêts à l’emploi : vue d’ensemble du trafic du mesh, détail par service, santé du plan de contrôle.
• Un backend de tracing distribué (Jaeger est le choix le plus ancien parmi les add-ons d’exemple d’Istio ; certains environnements utilisent plutôt Zipkin ou un backend basé sur OpenTelemetry) collecte des traces montrant le chemin complet d’une requête à travers chaque service touché, ce qui permet de voir à quel endroit d’une requête multi-sauts un ralentissement s’est réellement produit, plutôt que de savoir seulement qu’il s’est produit quelque part.
• Kiali est une console de service mesh conçue spécifiquement pour Istio : un graphe de topologie en direct de la façon dont les services communiquent réellement entre eux, s’appuyant sur les mêmes métriques et données de trace, avec en plus la possibilité d’inspecter et, dans certains cas, de modifier la configuration du mesh directement depuis son interface.

Installer les add-ons d’exemple

Le bundle de release d’Istio inclut des manifestes prêts à appliquer pour tous ces éléments sous samples/addons :

cd istio-*  # le répertoire issu de l'installation d'istioctl
kubectl apply -f samples/addons
kubectl get pods -n istio-system

Vous devriez voir des Pods prometheus, grafana, kiali et un backend de tracing démarrer à côté d’istiod et des gateways déjà en cours d’exécution dans istio-system. Ces manifestes d’exemple sont destinés à l’évaluation et à l’apprentissage, pas à constituer un déploiement prêt pour la production de chaque outil : les limites de ressources, le stockage et la rétention par défaut sont tous modestes, et un vrai déploiement exécuterait généralement Prometheus et Grafana avec leur propre configuration dédiée et correctement dimensionnée plutôt que l’exemple fourni.

Accéder à Kiali

Aucun de ces add-ons n’est exposé en dehors du cluster par défaut. Utilisez un port-forward pour atteindre l’interface de Kiali :

kubectl port-forward svc/kiali -n istio-system 20001:20001

Ouvrez http://localhost:20001. Avec du trafic circulant à travers des services intégrés au mesh, la vue en graphe de Kiali s’affiche en direct : quels services parlent à quels autres, codés par couleur selon leur santé, avec le volume de requêtes et le taux d’erreurs visibles par connexion.

Pourquoi le graphe peut sembler faux, ou vide

Si la vue de topologie de Kiali est vide, clairsemée, ou montre des nœuds déconnectés qui devraient manifestement communiquer, la cause la plus courante est celle déjà traitée dans le guide précédent : un label app manquant sur les Deployments et Services sous-jacents. Kiali construit son graphe à partir de ce label ; les workloads qui en sont dépourvus existent dans le mesh et font circuler le trafic sans problème, mais Kiali n’a aucun moyen fiable de les identifier et de les relier dans sa visualisation. Vérifiez le label avant de supposer que le mesh lui-même est mal configuré.

La seconde cause la plus courante est simplement l’absence de trafic : le graphe de Kiali reflète le trafic observé sur une fenêtre de temps sélectionnée ; un service fraîchement intégré au mesh auquel aucune requête n’a encore été envoyée n’a donc rien à afficher. Envoyez quelques requêtes et rafraîchissez.

Les tableaux de bord préconstruits de Grafana

Utilisez un port-forward vers Grafana de la même manière :

kubectl port-forward svc/grafana -n istio-system 3000:3000

L’installation d’exemple est livrée avec des tableaux de bord spécifiques à Istio déjà provisionnés, trafic à l’échelle du mesh, détail par service, performances du plan de contrôle, au lieu de vous obliger à les construire de zéro. Ils constituent un très bon point de départ pour comprendre quelles métriques Istio expose et comment elles sont structurées ; le guide Grafana ailleurs dans cette bibliothèque couvre la personnalisation et l’extension de tels tableaux de bord une fois que vous avez fini d’explorer les valeurs par défaut.

Considérez l’installation d’exemple comme un point de départ, pas une destination

Une fois que vous avez confirmé que le mesh est observable et que vous comprenez ce que montre chaque outil, l’étape suivante naturelle pour tout ce qui dépasse l’évaluation locale est de remplacer les exemples fournis par des installations correctement configurées et gérées indépendamment, en vous appuyant probablement sur les guides dédiés à Prometheus et à Grafana ailleurs dans cette bibliothèque, plutôt que de vous fier indéfiniment à samples/addons. Les manifestes d’exemple existent pour vous mener rapidement à « je vois mon mesh », pas pour être la stack d’observabilité à long terme d’un cluster de production.