De engste foutmelding heeft meestal de banaalste oorzaak

De meeste mesh-incidents zijn niet moeilijk. Ze zien er alleen zo uit.

Datum
Onderwerp
Debugging
Leestijd
2 min
Versie
Vertaling

Lees het Duitse origineel

De meeste mesh-incidents die ik zie zijn niet moeilijk. Ze zien er alleen zo uit.

Grafiek: OMNI52 Afbeelding op volledige grootte openen
Afbeelding als tekst

Twee teams met hetzelfde symptoom bovenaan: team A gokt en volgt een chaotisch zigzagpad van ongeveer drie uur, team B volgt een recht, systematisch pad met istioctl-stappen en is in zo'n twintig minuten klaar.

Een voorbeeld dat bijna iedereen kent die Istio draait. Een service kan plotseling een andere niet meer bereiken. In de log van de sidecar staat dit:

“upstream connect error … WRONG_VERSION_NUMBER”

Wie dit voor het eerst ziet, denkt aan kapotte certificaten, aan een TLS-misconfiguratie, aan iets diep in de encryptie-stack. Teams verliezen er uren mee.

De oorzaak is bijna altijd banaal: de doel-pod heeft geen sidecar. Het namespace-label voor de injection is vergeten. De caller praat mTLS, het doel antwoordt plain HTTP, en de eerste byte ziet er voor de proxy uit als een ongeldige TLS-versie. Angstaanjagende melding, doodsimpele oorzaak.

Hetzelfde patroon bij 503’s. De status alleen zegt niets. Maar Envoy schrijft er een flag bij, en die flag is de halve diagnose. UF betekent upstream-verbinding mislukt, vaak een ontbrekende sidecar of mTLS-mismatch. NR betekent geen route, Gateway of VirtualService wijst nergens heen. UO betekent dat de circuit breaker is dichtgegaan. Drie letters, drie totaal verschillende problemen.

Het eigenlijke punt is niet de losse foutmelding. Het is het verschil tussen twee teams.

Het ene team gokt. Het herstart pods, sleutelt aan configs, opent tickets, en hoopt. Drie uur later draait alles weer, niemand weet precies waarom.

Het andere team heeft een vast pad. Symptoom, dan proxy-status: kent de mesh de pod überhaupt. Dan analyze en proxy-config: wat ziet de sidecar echt. Dan de Envoy-flag: op welke hop sterft de request. Twintig minuten, duidelijke oorzaak, gerichte fix.

Het verschil is geen talent. Het is methode. En methode is iets dat je als organisatie kunt invoeren, lang voordat het volgende incident komt.

Wie in de mesh regelmatig blind zit te debuggen, heeft geen personeelsprobleem. Die heeft een ontbrekend runbook.

Volgende week: het diagnosepad als concrete stap-voor-stap-sequentie die je het hele team in handen kunt geven.

Over de auteur

Portret van Uli Renz

Uli Renz bouwt en beveiligt sinds Istio 1.4 service meshes in sterk gereguleerde enterprise-omgevingen. De patronen in deze reports komen uit dat werk.

Draait je mesh al in productie, dan is de Posture Check de eerste stap: 13 controlegebieden, elke bevinding met een ernstniveau en een onderbouwing uit de configuratie. In 90 minuten lopen we de lijst samen door.

Strategiegesprek aanvragen

Het aanvraagformulier op istio-consulting.de is in het Duits.