Wer das Mesh besitzt, entscheidet, was bleibt
Aus Soltau, live von der CloudLand: Wer ist eigentlich zuständig im Mesh?
- Datum
- Thema
- Ownership
- Lesezeit
- 2 Min.
Ich schreibe das aus Soltau, gerade noch bei der CloudLand. Mittwoch habe ich hier gesprochen, in den Diskussionen kam mehrfach die gleiche Frage. Sie passt zu dem, was ich euch letzte Woche versprochen habe.
Abbildung als Text
Zwei-Bereiche-Modell für Mesh-Ownership: Das Plattform-Team besitzt mesh-weite Leitplanken wie Control Plane, Ingress-Gateway und strikte Policies, Tenants konfigurieren VirtualServices und DestinationRules im eigenen Namespace ohne Rückfrage. Eine GitOps-Schicht setzt die harte Namespace-Isolation durch, jede Änderung läuft als Pull-Request.
In Post 3 ging es darum, dass niemand weiß, welche Konfigurationen man wieder rausnehmen darf. Die Frage dahinter: Wer ist überhaupt zuständig?
In den meisten Setups gibt es keine Antwort, weil es nie eine Entscheidung gab. Ownership entsteht nicht aus Sprints, sondern aus einer Architektur-Entscheidung, die jemand bewusst trifft und festschreibt.
Das Modell, das in Production am besten trägt, ist eine harte Trennung in zwei Bereiche:
Das Plattform-Team baut die Leitplanken im istio-system und mesh-weit. Control-Plane, MeshConfig, Ingress-Gateway, PeerAuthentication STRICT, AuthorizationPolicy deny-all, outboundTrafficPolicy REGISTRY_ONLY. Diese Objekte sind nicht verhandelbar und werden ausschließlich vom Plattform-Team geändert.
Die Tenants bewegen sich in ihrem eigenen Namespace, isoliert. VirtualService, DestinationRule, ServiceEntry – per Policy auf den eigenen Namespace begrenzt. AuthorizationPolicy mit Selektor auf die eigenen Workloads, die festlegt, wer mit ihnen sprechen darf. Innerhalb der Leitplanken, ohne Rückfrage.
Kein Shared Contract, keine verhandelbare Zone dazwischen. Mit harter Namespace-Isolation zwingt sich die Grenze selbst durch. Wer im falschen Namespace deployen will, wird vom Mesh blockiert, bevor jemand eine Diskussion anfangen muss.
Ownership ohne Durchsetzung bleibt Theorie. Die zweite Hälfte des Modells ist GitOps. Flux und Helm sorgen dafür, dass der Cluster-Zustand aus Git kommt und nicht aus dem letzten kubectl apply, an das sich niemand mehr erinnert.
Jede Policy-Änderung läuft durch den gleichen Pull-Request-Prozess wie Anwendungscode. Wer eine Änderung im Platform-Bereich will, geht durch den Platform-Repo. Wer im Tenant-Namespace etwas anlegt, geht durch das Tenant-Repo. Beide getrennt, beide nachvollziehbar.
Drift erkennt die Reconciliation-Loop, nicht der nächste Audit. Manuelle Änderungen im Cluster fliegen beim nächsten Sync zurück in den Soll-Zustand. Rollbacks sind git revert, nicht Pager-Duty um 03:00.
Und für die Frage aus Post 3 – was darf gelöscht werden – gibt es jetzt eine klare Antwort: Was nicht in Git steht, gehört nicht in den Cluster. Aufräumen wird ein Reconciliation-Problem, nicht eine Audit-Diskussion.
Eine Beobachtung aus den Diskussionen hier: Die Teams, die das Ownership-Modell und GitOps von Anfang an festgeschrieben haben, sind nicht die, die mehr Zeit investiert haben. Es sind die, die einmal entschieden und dann konsequent durchgezogen haben.
Nächste Woche schauen wir auf einen konkreten Aspekt: Wie man dieses Ownership-Modell technisch absichert, sodass Tenants nicht aus ihrem Namespace ausbrechen können – auch nicht versehentlich.
