Betreibt man Anwendungen, möchte man meistens auch mit ihnen interagieren. Diese grundlegende Aussage stimmt fast immer: Egal ob Webshop, Datenbank, oder Cloudstorage, irgendwie muss man über ein Netzwerk auf die Dienste zugreifen. Die wenigsten Anwendungen laufen in einem Netzwerk-Vakuum.
In Kubernetes gibt es bereits einige Netzwerkabstraktionen, die die Einrichtung und Umsetzung dieser nötigen Konzepte abstrahieren und erleichtern sollen:
Services mit ihren verschiedenen Typen (ClusterIP, NodePort, LoadBalancer, ExternalName) erlauben dir den Zugriff auf deine Anwendung von innerhalb (East-West Traffic) und außerhalb (North-South Traffic) deines Clusters, und Ingresses geben dir noch einmal mehr Flexibilität in Sachen Routing und Traffic-Shaping. Mit der Kubernetes Gateway API kommt nun ein neuer, weiterer Standard mit ins Spiel. Doch warum?
Warum eine Gateway API?
Das Konzept der Ingress-Ressource in Kubernetes wirkt eigentlich so simpel wie genial: Entwickler betreiben ihre Anwendung in Kubernetes und definieren eine oder mehrere Ingress-Ressourcen. IngressController im Cluster lesen diese ein und routen Netzwerkverkehr entsprechend der Vorgaben.
Schaut man einmal in die realen Abläufe in (größeren) Unternehmen, offenbaren sich jedoch ein paar Schwächen: Zum Einen ist nicht jeder Angestellte ein Entwickler. Zum Anderen sollten evtl. nicht alle Feinheiten in einer einzigen Ressource beschrieben werden. Und zuletzt verhalten sich auch nicht alle IngressController gleich: So bauen manche auf CustomResourceDefinitions (CRDs) für mehr Kontrolle (Traefik, Contour), andere setzen auf Annotationen der Ingress-Ressourcen (ingress-nginx), usw.
Die Kubernetes Gateway API versucht, diese Umstände mit neuer Modellierung und geringfügig anderen Annahmen „neu zu denken“. Hierfür definiert sie vier Design Goals:
- Rollenorientierung: Die verschiedenen Ressourcen der Kubernetes Gateway API modellieren verschiedene Rollenprofile. Diese Rollenprofile finden sich in Organisationen in der Konfiguration und Administration von Kubernetes-Netzwerken wieder.
- Portabilität: Die Kubernetes Gateway API ist keine „Verbesserung“ der Ingress API. Sie bietet eine weitere, stabile Spezifikation, die von Anbietern implementiert werden kann.
- Ausdrucksstärke: Die Kubernetes Gateway API bietet von Haus aus viele Features, die mit Ingress-Ressourcen nur über Umwege möglich sind. Dazu gehören bspw. Traffic Weighting oder Header-basiertes Matching.
- Erweiterbarkeit: Benötigt man dennoch zusätzliche Funktionalität, kann diese extern ergänzt werden. CustomResources (CRs) können an verschiedenen Stellen der Gateway API andocken.
Das sind meiner Meinung nach hehre und sinnvolle Ziele, doch wie werden sie in der Praxis umgesetzt? Schauen wir uns die „Bausteine“ der Kubernetes Gateway API doch einmal an!
Komponenten der Gateway API
Im Großen und Ganzen besteht die Kubernetes Gateway API aus drei verschiedenen Klassen an CustomResources: GatewayClasses, Gateways und xRoutes. Diese orientieren sich – wie bereits erwähnt – an verschiedenen Rollenprofilen:
- GatewayClasses definieren Sets an Gateways, die die gleiche Konfiguration und Verhalten besitzen. Sie verhalten sich insofern analog zu IngressClasses der Ingress API.
Jede GatewayClass der Gateway API wird von einem spezifischen Controller operiert. Ein Controller kann hierbei mehrere GatewayClasses handlen, es handelt sich also um eine 1:n Beziehung. - Gateways definieren, wie Netzwerkverkehr auf Services im Cluster übertragen wird.
Der Netzwerkverkehr kann hierbei bspw. von einem externen Loadbalancer oder einem weiteren Proxy im Cluster stammen. Gateways können entweder von Nutzern/Operatoren des Clusters, oder von einem GatewayController selbst erstellt werden.
Gateways referenzieren eine oder mehrere xRoutes. - xRoutes umfassen verschiedene Route-Ressourcen, die für unterschiedliche Szenarien gedacht sind:
HTTPRoutes routen auf L7 anhand der HTTP(S)-Spezifikation. TLSRoutes können für verschlüsselten Netzwerkverkehr genutzt werden, bei dem Aspekte von HTTP nicht betrachtet werden.
TCPRoutes und UDPRoutes mappen einen oder mehrere Ports auf ein Backend, je nach gewähltem Protokoll. Hierbei kann auch TLS terminiert werden. GRPCRoutes sind für das Handling und Routing des gRPC-Protokolls gedacht. Hierfür muss das genutzte Gateway HTTP/2 unterstützen.
Eine Route kann einem oder mehreren Gateways zugeordnet sein. Die Beziehung zwischen Gateways und xRoutes ist also m:n.
Die Komponenten im Rollenmodell
Liest man sich diese Beschreibungen durch, lassen sie sich verschiedenen Rollen in einer IT-Organisation zuordnen.
Provider geteilter Infrastruktur könnten so bspw. für die Bereitstellung von GatewayClasses zuständig sein. So ist sichergestellt, dass Konfiguration und gewählte Controller mit der allgemeinen Netzwerkinfrastruktur (z.B. Hardware-/Cloud-Loadbalancern) kompatibel sind.
Clusteradministratoren stellen basierend auf diesen GatewayClasses dann konkrete Gateways bereit, die von Clusternutzern konsumiert werden können. Die Gateways können hierbei auf einzelne Namespaces bzw. Cluster-Tenants beschränkt werden.
Clusternutzer zu guter letzt definieren die Routes, die die tatsächlichen Routing-Regeln implementieren: Sie wissen am besten, wie die von ihnen betriebenen bzw. entwickelten Anwendungen sich im Netzwerk verhalten.
Nach dieser theoretischen Auseinandersetzung mit der Kubernetes Gateway API ist es höchste Zeit, sich das einmal in der Praxis anzuschauen!
Testen der Gateway API mit NGINX Gateway Fabric
Für unser Experiment werden wir Podinfo in einem Cluster deployen und via Gateway API außerhalb des Clusters verfügbar machen.
Du hast gerade kein Cluster zur Hand? Teste die Kubernetes Gateway API auf einem Managed Cluster von NETWAYS Web Services. Zuverlässig, kostengünstig, und in Minuten startbereit.
Als Implementierung der Gateway API nutzen wir NGINX Gateway Fabric, einen Open Source GatewayController, analog zu ingress-nginx. In der Dokumentation findet sich eine Anleitung, um die Gateway API lokal in einem KinD-Cluster zu testen.
Installation der Gateway API CRDs und des GatewayControllers
Zuerst müssen die CustomResourceDefinitions der Gateway API im Cluster installiert werden:
kubectl kustomize "https://github.com/nginx/nginx-gateway-fabric/config/crd/gateway-api/standard?ref=v2.0.0" | kubectl apply -f -Im Anschluss kann NGINX Gateway Fabric mit Helm installiert werden:
helm install ngf oci://ghcr.io/nginx/charts/nginx-gateway-fabric --create-namespace -n nginx-gateway
kubectl get gatewayclassesDer NGINX GatewayController wird hier im Namespace nginx-gateway installiert. Der GatewayController hat außerdem bereits eine GatewayClass namens nginx erstellt.
Konfiguration der Demo-Anwendung
Nun kann die Demo-Anwendung im Cluster deployed werden. Wir definieren ein Deployment mit 3 Replicas sowie einen Service, der das Deployment im Cluster verfügbar macht:
kubectl create deployment podinfo --replicas 3 --image stefanprodan/podinfo:latest
kubectl expose deployment podinfo --port 9898 --target-port 9898 --selector=app=podinfo
kubectl port-forward services/podinfo 9898:9898Durch den Port-Forward können wir testen, ob der Service und die Demo-Anwendung wie erwartet funktionieren. Die Anwendung sollte nun unter http://localhost:9898 verfügbar sein.
Nun geht es an die Definition des Gateways und der benötigten HTTPRoute, um den podinfo Service auch außerhalb des Clusters verfügbar zu machen. Kopiere hierzu die folgenden Kubernetes-Manifeste in eine Datei gateway.yaml:
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: nginx-gateway
spec:
gatewayClassName: nginx
listeners:
- name: http
port: 80
protocol: HTTP
hostname: "podinfo.example.com"
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: podinfo
spec:
parentRefs:
- name: nginx-gateway
sectionName: http
hostnames:
- "podinfo.example.com"
rules:
- matches:
- path:
type: PathPrefix
value: /
backendRefs:
- name: podinfo
port: 9898Diese Ressourcen definieren die folgenden zwei API-Objekte in unserem Kubernetes-Cluster:
- ein Gateway mit einem einzigen Listener
http, der HTTP-Netzwerkverkehr auf Port 80 für den Hostnamenpodinfo.example.comhandled. - eine HTTPRoute, die das definierte Gateway samt Listener referenziert, seinen eigenen Hostnamen als
podinfo.example.comdefiniert, und sämtlichen Verkehr anpodinfo.example.com/an das definierte Backendpodinfo:9898(unseren zuvor definiertenpodinfoService) routet.
Die Datei gateway.yaml kann nun ebenfalls ins Cluster deployed werden:
kubectl create -f gateway.yamlTesten der Gateway API
Wir können nun überprüfen, ob das Gateway und die HTTPRoute erfolgreich erstellt wurden – dadurch erfahren wir auch die öffentlich erreichbare IP-Adresse, die wir für den finalen Test benötigen:
kubectl get gateways,httproutes
NAME CLASS ADDRESS PROGRAMMED AGE
gateway.gateway.networking.k8s.io/nginx-gateway nginx 185.233.188.2 True 65m
NAME HOSTNAMES AGE
httproute.gateway.networking.k8s.io/podinfo ["podinfo.example.com"] 61mMit cURL können wir jetzt testen, ob sich unsere Demo-Anwendung von außerhalb des Clusters erreichen lässt:
curl -H "Host: podinfo.example.com" http://185.233.188.2 {
"hostname": "podinfo-5d89c6b9cc-9tmtm",
"version": "6.9.0",
"revision": "fb3b01be30a3f353b221365cd3b4f9484a0885ea",
"color": "#34577c",
"logo": "https://raw.githubusercontent.com/stefanprodan/podinfo/gh-pages/cuddle_clap.gif",
"message": "greetings from podinfo v6.9.0",
"goos": "linux",
"goarch": "amd64",
"runtime": "go1.24.3",
"num_goroutine": "6",
"num_cpu": "4"
}Der Test ist erfolgreich! Mit Hilfe der Gateway API haben wir unsere Demo-Anwendung außerhalb des Clusters verfügbar gemacht – ganz ohne Ingress.
Mit einem Eintrag in /etc/hosts in der Form 185.233.188.2 podinfo.example.com kannst du die Demo-Anwendung auch unter http://podinfo.example.com in deinem Browser aufrufen! Benutze für den Eintrag natürlich die IP, die dir in der Ausgabe des vorherigen Befehls angezeigt wurde.
Die Kubernetes Gateway API – ein Standard für die Zukunft?
Die Gateway API markiert einen wichtigen Schritt in der Weiterentwicklung der Netzwerk-konfiguration auf Kubernetes.
Mit ihrem rollenbasierten Design und dem Fokus auf Portabilität, Ausdrucksstärke und Erweiterbarkeit adressiert sie viele Schwächen des bisherigen Ingress-Modells. Hierbei wurde in der API-Spezifikation sowohl an Entwickler als auch an Plattformbetreiber gedacht.
Die klar getrennten Rollen und Ressourcen wie GatewayClass, Gateway und die verschiedenen xRoute-Typen erlauben eine feingranulare Kontrolle und bessere Verantwortlichkeit im Team.
Das praktische Beispiel mit NGINX Gateway Fabric und einem Podinfo-Deployment hat dabei hoffentlich gezeigt, wie schnell der Einstieg sein kann, trotz der erweiterten Möglichkeiten.
Gleichzeitig wird deutlich, dass die Gateway API aus den gleichen Gründen zusätzliche Komplexität bedeuten kann, dafür aber auch deutlich mehr Flexibilität bietet.
Hinzu kommen neue, standardisierte Wege der Konfiguration, die so bspw. in der Ingress-API nicht ohne Weiteres möglich sind.
Wer heute bereits auf Kubernetes setzt, sollte sich mit der Kubernetes Gateway API vertraut machen. Sie ist nicht nur eine Alternative für Ingress, sondern ein modernes Fundament für komplexere Routing-Szenarien, das mittelfristig zum dominanten Standard im Kubernetes-Ökosystem werden dürfte.
Wenn du bereits heute deine Kubernetes-Cluster auf die Gateway API umstellen möchtest, geht das ohne Weiteres in NETWAYS Managed Kubernetes. Bei Rückfragen oder Problemen stehen dir außerdem unsere MyEngineer® zur Verfügung.
0 Kommentare