Ein falsch konfiguriertes Mesh schlägt oft nicht laut fehl: Traffic routet einfach nicht so, wie du es erwartet hast, oder ein Pod bekommt nie einen Sidecar, von dem du es annahmst. istioctl hat eigene Befehle genau dafür: Probleme abzufangen, bevor sie verwirrende Symptome verursachen. Diese Anleitung behandelt die, die sich lohnen, routinemäßig auszuführen.

istioctl analyze: Konfigurationsprobleme finden, bevor sie zuschlagen

istioctl analyze
istioctl analyze -n my-namespace
istioctl analyze -A

analyze untersucht die tatsächliche Istio-Konfiguration deines Clusters, nicht nur eine Datei, die du gleich anwendest, und meldet echte Probleme: ein Namespace, der nicht für Injection gelabelt ist, obwohl du es klar beabsichtigt hattest, ein VirtualService, der auf einen nicht existierenden Host verweist, widersprüchliche Konfiguration zwischen zwei Ressourcen. Führe es ohne Namespace-Flag für den Standard-Namespace des aktuellen Kontexts aus, mit -n für einen bestimmten oder mit -A über jeden Namespace im Cluster. Mache das nach jeder Konfigurationsänderung zur Gewohnheit, nicht nur, wenn etwas sichtbar kaputt ist; es fängt regelmäßig ein Problem ab, bevor es zu einem Symptom wird.

istioctl validate: eine Datei prüfen, bevor du sie anwendest

istioctl validate -f my-virtualservice.yaml

Wo analyze inspiziert, was bereits im Cluster live ist, prüft validate ein Manifest, bevor du es anwendest, und fängt Schemafehler und ungültige Feldwerte ab. Führe es selbstverständlich vor kubectl apply an allem aus, was mit Istio zu tun hat, derselbe Reflex wie kubectl apply --dry-run bei einfachen Kubernetes-Ressourcen.

istioctl proxy-status: ist jeder Sidecar synchron?

istioctl proxy-status

Das listet jeden Sidecar auf, den istiod kennt, und ob jeder die neueste Konfiguration hat (SYNCED) oder zurückliegt (STALE, oder einen Fehler zeigt). Ein Sidecar, der in STALE hängt, ist oft die tatsächliche Erklärung, wenn eine gerade angewendete Routing-Änderung auf einem bestimmten Pod nicht zu greifen scheint, und es lohnt sich, das zu prüfen, bevor du annimmst, dass die Konfiguration selbst falsch ist.

istioctl proxy-config: was läuft auf diesem einen Sidecar tatsächlich?

Um direkt in die Envoy-Konfiguration eines einzelnen Pods zu schauen, statt aus dem Verhalten zu raten:

istioctl proxy-config routes <pod-name> -n <namespace>
istioctl proxy-config clusters <pod-name> -n <namespace>
istioctl proxy-config listeners <pod-name> -n <namespace>

Das ist dieselbe zugrunde liegende Idee wie in den Envoy-Anleitungen dieser Bibliothek zum Untersuchen einer laufenden Konfiguration, nur über Istios eigenen Wrapper statt über Envoys rohe Admin-API direkt.

Das app-Label: leicht zu übersehen, bricht die Visualisierung stillschweigend

Eine bestimmte Falle ist häufig genug, um sie gesondert hervorzuheben. Istio (und darauf aufbauende Werkzeuge wie Kiali, in der nächsten Anleitung behandelt) verlassen sich auf ein app-Label an deinen Deployments und Services, um ein genaues Bild davon zu erstellen, welche Workloads mit welchen sprechen:

metadata:
  labels:
    app: reviews

Lässt du es weg, bricht nichts laut: Pods werden weiter deployt, Sidecars weiter eingeschleust, Traffic fließt weiter. Was stillschweigend aufhört zu funktionieren, ist alles, was von diesem Label abhängt, um einen Workload zu identifizieren: Kialis Service-Graph rendert die Verbindung nicht korrekt, und einige Funktionen für Traffic-Management und Telemetrie, die auf app schauen, verhalten sich unvorhersehbar. Sieht ein Mesh sonst gesund aus, aber sein Observability-Tooling zeigt ein verwirrendes oder unvollständiges Bild, gehören fehlende app-Labels an den zugrunde liegenden Deployments und Services zu den ersten Dingen, die man prüfen sollte, genau weil der Fehlermodus keine Fehlermeldung liefert, die auf die Ursache zeigt.

Eine vernünftige Gewohnheit aufbauen

Führe istioctl analyze nach jeder Konfigurationsänderung aus, istioctl validate vor dem Anwenden von allem Neuen und istioctl proxy-status, wann immer eine Änderung irgendwo Bestimmtes nicht zu greifen scheint. Keines davon fängt alles ab, Istios Konfigurationsoberfläche ist groß, aber zusammen fangen sie die Fehler ab, die sowohl häufig als auch mühsam zu debuggen sind, wenn man nur auf YAML starrt.