Service Mesh Field Report #8
Der Diagnose-Pfad, den jedes Team bekommt
Letzte Woche habe ich zwei Teams beschrieben. Eins rät drei Stunden, eins ist in zwanzig Minuten fertig. Der Unterschied ist kein Talent. Es ist dieser eine Pfad, und hier ist er.
Schritt 0: Erst lesen, nicht handeln. Die exakte Fehlermeldung und den Envoy-Flag notieren, bevor irgendwer einen Pod neu startet. Ein Neustart, der “es wieder zum Laufen bringt”, löscht die Spur. Beim nächsten Mal steht ihr wieder am Anfang.
Schritt 1: istioctl proxy-status. Kennt die Control Plane den Pod überhaupt, und ist seine Config SYNCED? Taucht der Pod nicht auf, fehlt das Sidecar, und ihr seid beim banalen WRONG_VERSION_NUMBER von letzter Woche. Steht da STALE, hat der Proxy die neue Config nicht gezogen. Ein Verteilungsproblem, kein Config-Fehler.
Schritt 2: istioctl analyze. Die statische Prüfung fängt in Sekunden, was man sonst stundenlang sucht: vergessenes Injection-Label, ein VirtualService, der ins Leere zeigt, zwei Regeln, die sich gegenseitig überschreiben.
Schritt 3: istioctl proxy-config. Jetzt schaut ihr, was der Sidecar wirklich sieht, nicht was im YAML steht. cluster und endpoints: gibt es hinter dem Ziel überhaupt gesunde Adressen. route: trifft die Route dahin, wo ihr sie vermutet. secret: sind die mTLS-Zertifikate ausgerollt.
Schritt 4: Zurück zum Flag. Jetzt zeigt er auf den Hop. UF führt euch zu endpoints und mTLS. NR zur Route. UO zur DestinationRule und ihren Limits. Der Flag war von Anfang an die halbe Diagnose. Jetzt ist er die ganze.
Schritt 5: Fix, dann mit demselben Pfad gegenprüfen. proxy-status wieder SYNCED, Flag weg.
Fünf Schritte, immer dieselben, in jedem Incident. Ein Team mit diesem Pfad ist nicht mehr davon abhängig, dass zufällig die richtige Person Schicht hat. Den Pfad anzuwenden, kann jeder lernen. Zu wissen, welche fünf Schritte es sind und was der Flag im konkreten Mesh bedeutet, ist die Erfahrung dahinter.
Ein Runbook ist unspektakulär. Genau deshalb trägt es um drei Uhr nachts, wenn niemand Lust auf Heldentum hat.
Genau dieses Runbook baue ich mit Teams in Assessments, aus den Incidents, die sie schon hatten. Die Methode bleibt im Team. Die Erfahrung, die entscheidet, welche Schritte es sind, bringe ich mit.
Welche Fehlermeldung hat euch zuletzt am längsten aufgehalten? Schreibt sie in die Kommentare, ich ordne den Flag ein.
Diskussion zu diesem Report auf LinkedIn
Aus der Praxis, für die Praxis
Hinter jedem Report stehen Muster aus echten Mesh-Setups. Wenn eines davon nach eurem Cluster klingt: Im Architekturgespräch schauen wir gemeinsam drauf.
Architekturgespräch anfragen