Gateway to nie zawsze to samo gateway
- data
- kategoria
- Networking
- także w
- Containers
- czytanie
- 2 min / 309 słów
W rozmowie o migracji z ingress-nginx łatwo usłyszeć:
przechodzimy na gateway
To zdanie prawie nic nie mówi.
Gateway może być produktem, rolą w architekturze, proxy na brzegu klastra albo zestawem zasobów Kubernetes.
Jeżeli tego nie rozdzielimy, pytanie:
czy Gateway API zastąpi API gateway?
brzmi sensownie, ale miesza dwie warstwy.
API gateway
API gateway stoi zwykle przed aplikacjami i obsługuje zachowania aplikacyjne albo produktowe.
Typowe funkcje:
authentication
authorization
rate limiting
request validation
response transformation
API keys
developer portal
usage plans
To jest miejsce, w którym organizacja często koduje zasady korzystania z API.
Przykład problemu:
klient może wykonać 1000 requestów na minutę
partner ma inny limit
endpoint /admin wymaga innej polityki
To nie jest automatycznie problem Kubernetes.
Może być rozwiązany produktem typu Kong, Apigee, AWS API Gateway, Azure API Management albo własną warstwą przed usługami.
Ingress gateway
Ingress gateway jest wejściem ruchu do klastra.
Typowe funkcje:
listen on 80 and 443
terminate TLS
match Host header
match path
route to Service
Tu przez lata siedział ingress-nginx.
W takim modelu Ingress był deklaracją:
ten host i ten path kierują do tego Service
A kontroler robił z tego konfigurację proxy.
To jest bliżej warstwy platformowej niż produktowego API management.
Service mesh gateway
Service mesh ma własny problem.
Jeżeli ruch wchodzi do mesha albo wychodzi z mesha, trzeba kontrolować granicę pomiędzy:
świat poza meshem
świat wewnątrz mesha
Mesh gateway może więc obsługiwać:
mTLS
service identity
traffic policy
routing between clusters
egress control
To nadal może wyglądać jak gateway, bo gdzieś stoi proxy.
Ale stawka jest inna: nie tylko jak wejść do klastra, ale jak wejść do modelu z tożsamością usług i politykami mesha.
Cloud load balancer gateway
W chmurze gateway często jest także sposobem zamówienia infrastruktury.
Manifest w Kubernetes może spowodować powstanie zasobu poza klastrem:
external load balancer
public IP
managed certificate
WAF policy
regional backend
Wtedy gateway nie jest tylko proxy w Podzie.
Jest deklaracją infrastruktury, którą kontroler mapuje na usługi dostawcy chmury.
Kubernetes Gateway API
Kubernetes Gateway API to nie jest jeden gateway.
To model zasobów:
GatewayClass
Gateway
HTTPRoute
GRPCRoute
ReferenceGrant
policies
Implementacja może być oparta o Envoy, NGINX, HAProxy, Traefik, Cilium, Istio albo mechanizmy cloud providera.
Dlatego pytanie nie brzmi:
czy używamy Gateway API czy Envoy?
Tylko:
czy używamy Gateway API, a jeśli tak, która implementacja realizuje ten kontrakt?
Najprostszy porządek
Przy migracji z ingress-nginx warto trzymać prosty podział:
Gateway API
= język konfiguracji w Kubernetes
Gateway controller
= implementacja tego języka
Gateway
= konkretne wejście ruchu
API gateway
= często szerszy produktowy zestaw funkcji
To chroni przed złą migracją.
Bo celem nie jest wymiana słowa Ingress na słowo Gateway.
Celem jest decyzja, które zachowania powinny stać w przenośnym Kubernetes API, a które nadal należą do konkretnego produktu albo konkretnej implementacji.