Service Mesh Field Report #7
Die gruseligste Fehlermeldung hat meist die banalste Ursache
Die meisten Mesh-Incidents, die ich sehe, sind nicht schwer. Sie sehen nur so aus.
Ein Beispiel, das fast jeder kennt, der Istio betreibt. Ein Service kann plötzlich einen anderen nicht mehr erreichen. Im Log des Sidecars steht das hier:
“upstream connect error … WRONG_VERSION_NUMBER”
Wer das zum ersten Mal sieht, denkt an kaputte Zertifikate, an eine TLS-Fehlkonfiguration, an irgendwas tief im Verschlüsselungs-Stack. Teams verlieren damit Stunden.
Die Ursache ist fast immer banal: Der Ziel-Pod hat kein Sidecar. Das Namespace-Label für die Injection wurde vergessen. Der Caller spricht mTLS, das Ziel antwortet Plain-HTTP, und das erste Byte sieht für den Proxy aus wie eine ungültige TLS-Version. Furchteinflößende Meldung, triviale Wurzel.
Das gleiche Muster bei 503ern. Der Status allein sagt nichts. Aber Envoy schreibt einen Flag dazu, und der Flag ist die halbe Diagnose. UF heißt Upstream-Verbindung gescheitert, oft fehlendes Sidecar oder mTLS-Mismatch. NR heißt keine Route, Gateway oder VirtualService zeigt ins Leere. UO heißt der Circuit Breaker hat zugemacht. Drei Buchstaben, drei völlig verschiedene Baustellen.
Der eigentliche Punkt ist nicht die einzelne Fehlermeldung. Es ist der Unterschied zwischen zwei Teams.
Das eine Team rät. Es startet Pods neu, dreht an Configs, öffnet Tickets, und hofft. Drei Stunden später läuft es wieder, niemand weiß genau warum.
Das andere Team hat einen festen Pfad. Symptom, dann proxy-status: kennt der Mesh den Pod überhaupt. Dann analyze und proxy-config: was sieht der Sidecar wirklich. Dann der Envoy-Flag: an welchem Hop stirbt der Request. Zwanzig Minuten, klare Ursache, gezielter Fix.
Der Unterschied ist nicht Talent. Es ist Methode. Und Methode ist etwas, das man als Organisation einführen kann, lange bevor der nächste Incident kommt.
Wer im Mesh regelmäßig im Blindflug debuggt, hat kein Personalproblem. Er hat ein fehlendes Runbook.
Nächste Woche: der Diagnose-Pfad als konkrete Schritt-für-Schritt-Sequenz, die man dem ganzen Team an die Hand geben kann.
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