Kubernetes: Gateway API

Manchmal hat es auch seine guten Seiten keine Zeit für gewisse Dinge zu haben – wie sich mit IT Themen auseinandersetzen und darüber zu schreiben. Das Thema Ingress mit Kubernetes bspw. habe ich länger vor mir hergeschoben, bzw. es falsch eingesetzt (u.a. aufgrund einer OnPrem Installation). Wie sich jetzt herausgestellt hat, ist Ingress abgekündigt und wird nicht weiterentwickelt. Die K8s Gateway API ist jetzt der Standard.

Ursprünglich hatte ich versucht Ingress zu nutzen, um meine AWX Installation auch über HTTPS betreiben zu können. Da ich es bis zum damaligen Zeitpunkt nicht besser wusste, war mein Plan einfach Ingress auf den Cluster zu werfen und den AWX Service darüber nach Außen bereitzustellen. Das hat natürlich so nicht funktioniert. Erst mit einem „dirty hack“, indem ich hostNetwork auf true im Deployment-File gesetzt hatte.

Das macht so natürlich keinen Sinn. So läuft der Ingress-Controller Pod nämlich immer nur auf einem Worker-Node. Ich wusste, dass das eine sehr unzufriedenstellende Lösung war und habe es aber erst einmal dabei belassen. Wie wir mittlerweile wissen, ist Ingress jetzt aber eh Geschichte.

Und wie die Entwickler/Maintainer im Artikel selber sagen, die Empfehlung geht klar zur Kubernetes Gateway API. Die API ist viel dynamischer, kann u.a. mehrere Protokolle routen und auch über Namespaces hinewg agieren. Ingress war da deutlich limitierter und konnte nur HTTP(S) bedienen.

Für den Einsatz der Gateway API werden zwei Hauptkomponenten und bestimmte Objekte benötigt:

• Gateway API CRDs (Custom Resource Definitions)
• Gateway API Controller
• Gateway API Objekte wie Gateways, Routen etc.

Der offizielle Artikel in der Doku beschreibt die API weitergehend.

Gateway API CRDs

Die Gateway API CRDs kommen nicht ootb mit Kubernetes zusammen. Diese müssen manuell nachinstalliert werden. Das Projekt findet man hier.

Die Installation findet wie gewohnt über das Manifest-File statt, welches man vorher herunterladen kann:

wget https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.4.1/standard-install.yaml

Die Version sollte natürlich entsprechend angepasst werden.

Anwenden des Files:

kubectl apply --server-side -f standard-install.yaml

Prüfen:

kubectl get crds | grep gateway

Gateway API Controller

Wie sonst gibt es hier auch mehrere Anbieter bzw. Lösungen, u.a. von Istio, Traefik oder Nginx. Ich habe mich für letzteres entschieden – Die NGINX Gateway Fabric.

Erstellen eines Namespaces:

kubectl create namespace nginx-gateway

Installation der Gateway API resources (auf Version achten):

kubectl kustomize "https://github.com/nginx/nginx-gateway-fabric/config/crd/gateway-api/standard?ref=v2.4.1" | kubectl apply -f -

Installation der Fabric CRDs (auf Version achten):

kubectl apply --server-side -f https://raw.githubusercontent.com/nginx/nginx-gateway-fabric/v2.4.1/deploy/crds.yaml

Installation von NGINX Gateway Fabric (auf Version achten):

kubectl apply -f https://raw.githubusercontent.com/nginx/nginx-gateway-fabric/v2.4.1/deploy/default/deploy.yaml

Nach einiger Zeit sollte ein Pod deployed worden sein:

kubectl get pods -n nginx-gateway

Und die Gateway-Classes (bzw. eine) sollte ebenfalls vorhanden sein:

kubectl get gatewayclasses

That’s it. Der Kubernetes Cluster ist vorbereitet um die Gateway API statt Ingress zu nutzen. Hierfür müssen natürlich noch bestimmte Objekte angelegt werden. Und Spoiler: MetalLB muss ebenfalls installiert sein und funktionieren (OnPrem). Im nächsten Artikel beschreibe ich dieses Verfahren mit AWX.