Jeder Envoy-Sidecar in einem Mesh erzeugt als Nebeneffekt der Traffic-Verarbeitung bereits detaillierte Metriken und Trace-Daten; dafür muss deinen Anwendungen nichts Zusätzliches hinzugefügt werden. Ohne weitere Komponenten fehlt ein Ort, an den diese Daten gesendet, wo sie gespeichert und angesehen werden. Diese Anleitung installiert die Teile, die das tun und den Traffic eines Mesh tatsächlich sichtbar machen.

Wofür jedes Add-on da ist

• Prometheus holt und speichert die Metriken, die jeder Sidecar bereitstellt: Anfrageraten, Fehlerraten, Latenzen, pro Service und pro Route. Die eigenen Prometheus-Anleitungen dieser Bibliothek behandeln das Werkzeug selbst ausführlich; hier ist es speziell das Backend, das Istios eigene Dashboards abfragen.
• Grafana visualisiert diese Prometheus-Daten über vorgefertigte Istio-Dashboards: mesh-weiter Traffic-Überblick, Details pro Service, Gesundheit der Control Plane.
• Ein Backend für verteiltes Tracing (Jaeger war die am längsten bestehende Wahl in Istios Beispiel-Add-ons; manche Umgebungen nutzen stattdessen Zipkin oder ein OpenTelemetry-basiertes Backend) sammelt Traces, die den vollständigen Weg einer einzelnen Anfrage über jeden berührten Service zeigen. Damit lässt sich sehen, wo in einer Anfrage über mehrere Hops tatsächlich eine Verlangsamung auftrat, statt nur zu wissen, dass sie irgendwo auftrat.
• Kiali ist eine speziell für Istio gebaute Service-Mesh-Konsole: ein Live-Topologiegraph, wie Services tatsächlich miteinander sprechen, gestützt auf dieselben Metrik- und Trace-Daten, plus die Möglichkeit, Mesh-Konfiguration direkt aus ihrer UI zu inspizieren und teilweise zu bearbeiten.

Die Beispiel-Add-ons installieren

Istios Release-Bundle enthält gebrauchsfertige Manifeste für all diese unter samples/addons:

cd istio-*  # das Verzeichnis aus der Installation von istioctl
kubectl apply -f samples/addons
kubectl get pods -n istio-system

Du solltest Pods für prometheus, grafana, kiali und ein Tracing-Backend sehen, die neben istiod und allen bereits laufenden Gateways in istio-system starten. Diese Beispielmanifeste sind zur Evaluierung und zum Lernen gedacht, nicht als produktionsreifes Deployment jedes Werkzeugs: Standard-Ressourcenlimits, Speicher und Aufbewahrung sind bescheiden, und ein echtes Deployment würde Prometheus und Grafana typischerweise mit eigener, dedizierter und angemessen dimensionierter Konfiguration betreiben statt mit dem mitgelieferten Beispiel.

Kiali erreichen

Keines dieser Add-ons ist standardmäßig außerhalb des Clusters erreichbar. Richte ein Port-Forward ein, um Kialis UI zu erreichen:

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

Öffne http://localhost:20001. Fließt Traffic durch gemeshte Services, wird Kialis Graphansicht live gerendert: welche Services mit welchen sprechen, farbcodiert nach Gesundheit, mit Anfragevolumen und Fehlerrate pro Verbindung.

Warum der Graph falsch oder leer aussehen kann

Ist Kialis Topologieansicht leer, dünn besetzt oder zeigt getrennte Knoten, die offensichtlich miteinander sprechen sollten, ist die häufigste Ursache dieselbe wie in der vorherigen Anleitung: ein fehlendes app-Label an den zugrunde liegenden Deployments und Services. Kiali baut seinen Graphen aus diesem Label; Workloads ohne es existieren im Mesh und tragen Traffic problemlos, aber Kiali hat keinen verlässlichen Weg, sie zu identifizieren und in seiner Visualisierung zu verbinden. Prüfe auf das Label, bevor du annimmst, das Mesh selbst sei falsch konfiguriert.

Die zweithäufigste Ursache ist schlicht noch kein Traffic: Kialis Graph spiegelt über ein gewähltes Zeitfenster beobachteten Traffic, ein frisch gemeshter Service, an den noch keine Anfragen gesendet wurden, hat also nichts anzuzeigen. Sende ein paar Anfragen hindurch und lade neu.

Grafanas vorgefertigte Dashboards

Richte ein Port-Forward zu Grafana auf dieselbe Weise ein:

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

Die Beispielinstallation liefert Istio-spezifische Dashboards bereits provisioniert mit, mesh-weiter Traffic, Details pro Service, Performance der Control Plane, statt dass du sie von Grund auf bauen musst. Sie sind ein wirklich guter Ausgangspunkt, um zu verstehen, welche Metriken Istio bereitstellt und wie sie strukturiert sind; die Grafana-Anleitung an anderer Stelle in dieser Bibliothek behandelt das Anpassen und Erweitern solcher Dashboards, sobald du über das Erkunden der Standardeinstellungen hinaus bist.

Betrachte die Beispielinstallation als Ausgangspunkt, nicht als Ziel

Sobald du bestätigt hast, dass das Mesh beobachtbar ist, und verstehst, was jedes Werkzeug zeigt, ist der natürliche nächste Schritt für alles jenseits lokaler Evaluierung, die mitgelieferten Beispiele durch angemessen konfigurierte, unabhängig verwaltete Installationen zu ersetzen, wahrscheinlich mit den eigenen Anleitungen zu Prometheus und Grafana an anderer Stelle in dieser Bibliothek, statt sich auf unbestimmte Zeit auf samples/addons zu verlassen. Die Beispielmanifeste existieren, um dich schnell zu „ich kann mein Mesh sehen“ zu bringen, nicht um der langfristige Observability-Stack eines produktiven Clusters zu sein.