Service Mesh Field Report
Het archief van de serie
Elke week één report uit het draaien van Istio en Envoy in de enterprise: een echte situatie, het patroon erachter, en wat het betekent voor wie verantwoordelijk is. Geschreven door Uli Renz, OMNI52. Alle teksten verschenen eerst op LinkedIn, in het Duits.
- Vier vragen, en je leest elke Envoy-mesh
Bijna elke mesh draait op dezelfde motor. Vandaag haal ik hem uit elkaar. Wees niet bang voor de diepte, het zijn precies vier onderdelen.
- Bijna elke mesh draait op dezelfde motor
Istio, Kuma, Consul, App Mesh, Gloo. Vijf namen, en onder de motorkap vijf keer dezelfde proxy: Envoy.
- Het echte probleem was nooit Istio
Tien Field Reports. Bijna allemaal hadden ze dezelfde wortel. En die zat nooit in Istio.
- Observability die tijdens een incident echt helpt
Tijdens een incident openen de meesten eerst Grafana. Alles groen. Precies daar blijft het team steken.
- Het diagnosepad dat elk team krijgt
Vorige week twee teams: het ene gokt drie uur lang, het andere is in twintig minuten klaar. Het verschil is geen talent. Het is dit ene pad.
- De engste foutmelding heeft meestal de banaalste oorzaak
De meeste mesh-incidents zijn niet moeilijk. Ze zien er alleen zo uit.
- Lokaal toestaan, mesh-breed voorkomen
Het gat dichten zonder de tenant zijn autonomie af te nemen.
- Als een tenant de traffic van de anderen kaapt
Wie tenants eigen VirtualServices toestaat, zet de deur open voor MITM in het eigen mesh.
- Wie het mesh bezit, bepaalt wat blijft
Vanuit Soltau, live vanaf CloudLand: wie is er eigenlijk verantwoordelijk in het mesh?
- Wat niemand meer begrijpt, maar iedereen gebruikt
20, 100, 500+ configuratieobjecten - en niemand durft iets te verwijderen.
- Als de CVE komt, is het te laat
Istio brengt elke drie maanden een minor release uit. Klinkt planbaar.
- Als "veilig" alleen een onderbuikgevoel is
mTLS overal actief, dashboards groen - en niemand kan zeggen wat er werkelijk versleuteld draait.