De API die ownership serieus neemt
Het beste aan de Kubernetes Gateway API is geen nieuwe feature. Het is het antwoord op een vraag die de oude API’s nooit hebben gesteld: Van wie is dit?
- Datum
- Onderwerp
- Gateway-api
- Bronnen
- 6
- Leestijd
- 3 min
- Versie
- Vertaling
In report #27 was de Gateway API stap nul voor de Ambient-verhuizing. Maar ze loont ook zonder die verhuizing.
Afbeelding als tekst
Diagram van de drie resources van de Gateway API als stapel met hun eigenaren: GatewayClass (infrastructuur, welke implementatie draait), Gateway (platformteam: Listener, poorten, TLS en de grendel allowedRoutes) en HTTPRoute (applicatieteam). Een HTTPRoute uit de namespace team-a koppelt zich via parentRef aan de Gateway en wordt geaccepteerd (Accepted: True), een route uit een vreemde namespace strandt op de allowedRoutes-grendel (Accepted: False). Ernaast drie gevolgen: standaard alleen de eigen namespace, elke namespace-grens heeft de instemming van beide kanten nodig, de grens is met kubectl na te lezen. Daaronder twee vakken: de handshake (de route noemt via parentRef de Gateway, de Gateway laat haar via allowedRoutes toe) en het eerlijke verhaal (het slot sluit alleen als RBAC meedoet; wie zelf Gateways of VirtualServices mag aanmaken, loopt eromheen). Pointe: De organisatievraag staat niet in de wiki, maar in de API-server.
Een VirtualService beschrijft de routing. Hoe ver de VS reikt, bepaalt standaard de auteur: zonder verdere opgave mesh-breed (report #5). Ownership was tot nu toe altijd alleen maar een briefje op de deur, geen deur met slot: conventie plus knoppen waar iemand eerst aan moet draaien (report #6).
De Gateway API bouwt de grens in het API-ontwerp zelf in. Drie resources, drie eigenaren:
GatewayClass is van de infrastructuur: welke implementatie er überhaupt wordt gedraaid.
Gateway is van het platformteam: Listener, poorten, TLS. En de beslissende regel: allowedRoutes.
HTTPRoute is van het applicatieteam, in de eigen namespace.
Een route koppelt zich via parentRef aan een Gateway. Of ze daar werkt, bepaalt de eigenaar ervan via allowedRoutes: uit welke namespaces, met welke route-typen. De default laat alleen de eigen namespace toe. De documentatie noemt dat een handshake: elke namespace-grens heeft de instemming van beide kanten nodig. Deze grens hoeft geen policy engine meer na te bouwen, ze zit direct in het objectmodel.
Dat kennen we uit eerdere reports: lokale werking is van het team, mesh-brede werking van het platform (report #4 en #6). Het omleidingspatroon uit report #5, een tenant die vreemd verkeer kaapt, wordt structureel moeilijker: op de Gateway werkt een route alleen waar iemand haar het aankoppelen heeft toegestaan. Hangt ze in de mesh direct aan een vreemde Service, dan geldt ze alleen voor aanroepen uit de eigen namespace.
Het eerlijke verhaal: het slot sluit alleen als RBAC meedoet. Wie zelf Gateways mag aanmaken, bouwt sowieso een eigen ingang. Wie nog VirtualServices mag schrijven, heeft het patroon uit report #5 nog in handen, daar blijven de knoppen uit report #6 verplicht. En op een gedeelde Listener kunnen meerdere teams dezelfde hostnaam claimen. Dat los je op met een Listener per hostnaam of een geschikte admission policy.
Voor beslissers betekent dit: de ownership-vraag die anders in beheeroverleggen escaleert, is hier een eigenschap van de API. Minder policy-lijm die onderhouden wil worden, en de eigenlijke grens is gewoon met kubectl na te lezen.
De organisatievraag staat daarmee voor het eerst niet in de wiki, maar direct in de API-server.
Istio wil de Gateway API volgens de eigen documentatie in de toekomst de standaard-API voor traffic management maken. Wat het betekent om een gegroeid VirtualService-bestand daarheen te verhuizen, volgt volgende week. TL;DR: meer dan de gangbare mapping-tabellen beloven.
