Die API, die Ownership ernst nimmt
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?
- Datum
- Thema
- Gateway-api
- Quellen
- 6
- Lesezeit
- 2 Min.
In Post 27 war die Gateway API Stufe null vor dem Ambient-Umzug. Sie lohnt sich aber auch ohne ihn.
Abbildung als Text
Diagramm der drei Ressourcen der Gateway API als Stapel mit ihren Besitzern: GatewayClass (Infrastruktur, welche Implementierung gefahren wird), Gateway (Platform-Team: Listener, Ports, TLS und der Riegel allowedRoutes) und HTTPRoute (Anwendungsteam). Eine HTTPRoute aus dem Namespace team-a dockt per parentRef am Gateway an und wird akzeptiert (Accepted: True), eine Route aus einem fremden Namespace endet am allowedRoutes-Riegel (Accepted: False). Daneben drei Folgerungen: Default nur der eigene Namespace, jede Namespace-Grenze braucht die Zustimmung beider Seiten, die Grenze lässt sich per kubectl nachlesen. Darunter zwei Kästen: der Handshake (die Route nennt per parentRef das Gateway, das Gateway lässt sie über allowedRoutes zu) und der ehrliche Teil (das Schloss schließt nur, wenn RBAC mitzieht; wer selbst Gateways oder VirtualServices anlegen darf, geht daran vorbei). Pointe: Die Organisationsfrage steht nicht im Wiki, sondern im API-Server.
Ein VirtualService beschreibt das Routing. Wie weit der VS wirkt, entscheidet im Default der Autor: ohne weitere Angabe mesh-weit (Post 5). Ownership war bisher immer nur ein Zettel an der Tür, keine Tür mit Schloss: Konvention plus Stellschrauben, die jemand erst drehen muss (Post 6).
Die Gateway API baut die Grenze ins API-Design selbst. Drei Ressourcen, drei Besitzer:
GatewayClass gehört der Infrastruktur: welche Implementierung überhaupt gefahren wird.
Gateway gehört dem Platform-Team: Listener, Ports, TLS. Und die entscheidende Zeile: allowedRoutes.
HTTPRoute gehört dem Anwendungsteam, im eigenen Namespace.
Eine Route hängt sich per parentRef an ein Gateway. Ob sie dort wirkt, entscheidet dessen Besitzer über allowedRoutes: aus welchen Namespaces, mit welchen Route-Typen. Der Default lässt nur den eigenen Namespace zu. Die Doku nennt das einen Handshake: Jede Namespace-Grenze braucht die Zustimmung beider Seiten. Diese Grenze muss keine Policy-Engine mehr nachbauen, sie steckt direkt im Objektmodell.
Das kennen wir aus vorherigen Posts: lokale Wirkung gehört dem Team, mesh-weite der Platform (Post 4 und 6). Das Umleitungs-Muster aus Post 5, ein Tenant kapert fremden Traffic, wird strukturell schwerer: Am Gateway wirkt eine Route nur, wo ihr jemand das Andocken erlaubt hat. Hängt sie im Mesh direkt an einem fremden Service, gilt sie nur für Aufrufe aus dem eigenen Namespace.
Der ehrliche Teil: Das Schloss schließt nur, wenn RBAC mitzieht. Wer selbst Gateways anlegen darf, baut sich sowieso einen eigenen Eingang. Wer weiter VirtualServices schreiben darf, hat das Muster aus Post 5 noch in der Hand, dort bleiben die Stellschrauben aus Post 6 Pflicht. Und an einem geteilten Listener können mehrere Teams denselben Hostnamen beanspruchen. Das klärt ein Listener je Hostname oder eine geeignete Admission-Policy.
Für Entscheider heißt das: Die Ownership-Frage, die sonst in Betriebsmeetings eskaliert, ist hier eine Eigenschaft der API. Weniger Policy-Kleber, der gepflegt werden will, und die eigentliche Grenze lässt sich einfach per kubectl nachlesen.
Die Organisationsfrage steht damit zum ersten Mal nicht im Wiki, sondern direkt im API-Server.
Istio will die Gateway API laut eigener Doku künftig zur Standard-API fürs Traffic-Management machen. Was es heißt, ein gewachsenes VirtualService-Inventar dorthin umzuziehen, kommt nächste Woche. TL/DR: mehr, als die einschlägigen Mapping-Tabellen versprechen.
