Feldnotizen aus dem Service-Mesh-Betrieb
Jeder Report beginnt mit einer realen Situation im Betrieb von Istio und Envoy, zeigt das Muster dahinter und was es für Plattform- und Sicherheitsverantwortliche bedeutet. Alle Reports erschienen zuerst auf LinkedIn.
Das Beste der Kubernetes Gateway API ist kein neues Feature. Es ist die Antwort auf eine Frage, die die alten APIs nie gestellt haben: Wem gehört das hier?
Vier Posts später und genauso weit wie davor? Was denn nun, Ambient oder Sidecar? Es kommt drauf an. Worauf, hier hilft folgendes Raster mit fünf Zeilen.
Beim Umzug auf Ambient kann Traffic aus dem Dashboard verschwinden, ohne weg zu sein. Ein Stufenplan mit Prüfpunkten fängt das ab.
Ambient macht vieles richtig. Für harte Enterprise-Anforderungen bleibe ich vorerst beim Sidecar. Der Grund dafür steht in keinem Benchmark.
Eine Policy, die im Review harmlos aussah, kappt in Ambient Verbindungen, die sie erlauben sollte. Der Grund liegt eine Schicht tiefer.
Ein Proxy-Update im Sidecar-Modell heißt: Jeder Pod startet neu oder jemand legt die Wartungsfenster von zwanzig Teams übereinander.
Die Freigabe kam aus Staging, grün über die ganze Linie. Drei Wochen später brennt in Prod ein Pfad, den Staging nie gesehen hat.
„Der Sidecar kostet uns zu viel.“ oder „Der fällt nicht ins Gewicht.“ Zwei Sätze aus fast jeder Mesh-Debatte. Gemessen hat sie kaum einer.
Sidecar-Upgrade klingt nach Infrastruktur. Für eure Pods heißt es: Restart. Für eure Clients heißt es: kommt drauf an.
Die wichtigste Frage bei einem Mesh-Upgrade ist nicht, wie ihr vorwärtskommt. Sondern wie ihr zurückkommt, wenn die erste Welle knirscht.
In vielen Backlogs gibt es ein Ticket, das bald Geburtstag feiert. Es heißt ‚Mesh-Upgrade‘ und wandert seit Monaten von Sprint zu Sprint.
Die Workload-Zertifikate in eurem Mesh sind kurzlebig und rotieren automatisch. Seit Jahren, ohne dass jemand hinschaut. Genau deshalb schaut auch auf den Rest der Kette niemand mehr.
Kaum liegt das Egress-Thema auf dem Tisch, kommt der Reflex: „Wir bauen ein Egress-Gateway, dann läuft alles über eine Stelle.“ Beschlossen ist es oft, bevor jemand fragt, was es eigentlich erzwingen soll.
Nach innen ist euer Mesh jetzt Zero Trust: mTLS auf STRICT, Default auf Deny. Und nach draußen? Da telefoniert es, mit wem es will.
Nach dem STRICT-Umbau aus der letzten Folge ist jede Verbindung im Mesh verschlüsselt und beidseitig authentifiziert. Klingt nach Ziel erreicht. Nur: Jeder Workload darf immer noch mit jedem reden.
„mTLS ist aktiviert“, sagt das Team. Auf Nachfrage steht der Mesh-Default seit der Einführung auf PERMISSIVE. Das ist kein Aktiviert. Das ist ein Vielleicht.
Am 30. September stellt AWS App Mesh ab. Das ist keine Deprecation-Warnung mehr, das ist ein Abschalttermin.
Fast jedes Mesh fährt denselben Motor. Heute zerlege ich ihn. Keine Angst vor der Tiefe, es sind genau vier Teile.
Istio, Kuma, Consul, App Mesh, Gloo. Fünf Namen, und unter der Haube fünfmal derselbe Proxy: Envoy.
Zehn Field Reports. Fast alle hatten dieselbe Wurzel. Und die saß nie in Istio.
Im Incident öffnen die meisten zuerst Grafana. Alles grün. Genau da bleibt das Team stehen.
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.
Die meisten Mesh-Incidents sind nicht schwer. Sie sehen nur so aus.
Die Lücke schließen, ohne dem Tenant seine Autonomie zu nehmen.
Wer Tenants eigene VirtualServices erlaubt, öffnet eine Tür für MITM im eigenen Mesh.
Aus Soltau, live von der CloudLand: Wer ist eigentlich zuständig im Mesh?
20, 100, 500+ Konfigurationsobjekte - und niemand traut sich, etwas zu löschen.
Istio macht alle drei Monate ein Minor Release. Klingt planbar.
mTLS überall aktiv, Dashboards grün - und niemand kann sagen, was wirklich verschlüsselt läuft.
Uli Renz baut und härtet seit Istio 1.4 Service Meshes in streng regulierten Enterprise-Umgebungen. Die Muster in diesen Reports stammen aus dieser Arbeit.
Läuft dein Mesh schon in Produktion, ist der Posture Check der Einstieg: 13 Prüfbereiche, jeder Befund mit Schweregrad und Config-Beleg. In 90 Minuten gehen wir die Liste gemeinsam durch.
