Feldnotizen aus dem Service-Mesh-Betrieb

Service Mesh Field Report

Das Archiv der Serie

Jede Woche ein Report aus dem Enterprise-Betrieb von Istio und Envoy: eine reale Situation, das Muster dahinter, und was es für Verantwortliche bedeutet. Geschrieben von Uli Renz, OMNI52. Alle Texte erschienen zuerst auf LinkedIn.

  1. Vier Fragen, und du liest jedes Envoy-Mesh

    Fast jedes Mesh fährt denselben Motor. Heute zerlege ich ihn. Keine Angst vor der Tiefe, es sind genau vier Teile.
  2. Fast jedes Mesh fährt denselben Motor

    Istio, Kuma, Consul, App Mesh, Gloo. Fünf Namen, und unter der Haube fünfmal derselbe Proxy: Envoy.
  3. Das eigentliche Problem war nie Istio

    Zehn Field Reports. Fast alle hatten dieselbe Wurzel. Und die saß nie in Istio.
  4. Observability, die im Incident wirklich hilft

    Im Incident öffnen die meisten zuerst Grafana. Alles grün. Genau da bleibt das Team stehen.
  5. Der Diagnose-Pfad, den jedes Team bekommt

    Letzte Woche zwei Teams: eins rät drei Stunden, eins ist in zwanzig Minuten fertig. Der Unterschied ist kein Talent. Es ist dieser eine Pfad.
  6. Die gruseligste Fehlermeldung hat meist die banalste Ursache

    Die meisten Mesh-Incidents sind nicht schwer. Sie sehen nur so aus.
  7. Lokal erlauben, mesh-weit verhindern

    Die Lücke schließen, ohne dem Tenant seine Autonomie zu nehmen.
  8. Wenn ein Tenant den Traffic der anderen kapert

    Wer Tenants eigene VirtualServices erlaubt, öffnet eine Tür für MITM im eigenen Mesh.
  9. Wer das Mesh besitzt, entscheidet, was bleibt

    Aus Soltau, live von der CloudLand: Wer ist eigentlich zuständig im Mesh?
  10. Was niemand mehr versteht, aber alle benutzen

    20, 100, 500+ Konfigurationsobjekte - und niemand traut sich, etwas zu löschen.
  11. Wenn das CVE kommt, ist es zu spät

    Istio macht alle drei Monate ein Minor Release. Klingt planbar.
  12. Wenn "sicher" nur ein Bauchgefühl ist

    mTLS überall aktiv, Dashboards grün - und niemand kann sagen, was wirklich verschlüsselt läuft.