Die neueste Version von Kong for Kubernetes, Version 0․8, bietet eine vollständige Integration mit Knative und zwei zusätzliche Custom Resource Definitions: KongClusterPlugins & TCPIngress. Kong stellt eine Open-Source-API-Schicht dar die Teil des Kubernetes-Ökosystems ist. Die Architektur besteht aus einem Controller zur Zustandsverwaltung für Kubernetes und einem Gateway, das eingehende und ausgehende API-Aufrufe verarbeitet. Vor der Verwendung dieses neuen Releases müssen Entwickler die aktuellen Versionen von Kong Gateway & Kong Enterprise installieren und ein Upgrade durchführen.
Kong für Kubernetes lässt sich am einfachsten mit einer Zeile Code auf dem Kubernetes-Cluster installieren: $ kubectl apply -f bit.ly/k4k8s. Ob das neue Release kompatibel zu den bereits installierten Laufzeitumgebungen ist, lässt sich anhand einer Versionskonkordanz überprüfen. Interessierte können Kong kostenlos in einer Testumgebung ausprobieren. Zum Einstieg gibt es einen Leitfaden.
Kong als Ingress Layer für Knative einsetzen
Mit dem neuen Release kann Kong jetzt ebenfalls als Ingress Layer für Knative-Workloads fungieren. Knative ist eine auf Kubernetes basierende Plattform die es ermöglicht, "serverlose" Arbeitsabläufe auf Kubernetes auszuführen. Es verwaltet die automatische Skalierung, einschließlich der Skalierung auf Null, mithilfe sogenannter Kubernetes-Primitives. Zusätzlich kann Kong Plug-ins für Knative-Serving-Workloads ausführen und dabei die Verantwortung für Authentifizierung, Caching, Traffic Shaping & Umwandlung übernehmen. Das bedeutet, dass HTTP-basierte "serverlose" Ereignisse von Knative automatisch durch Kong geleitet werden und sich identisch getrennt verwalten lassen. Die eigentlichen Knative-Dienste sollen dadurch "schlank" bleiben und sich auf die Geschäftslogik konzentrieren.
Für Knative haben Entwickler bei der Wahl des Cloud-Providers freie Hand: Anders als bei den AWS Lambda Services oder Google Cloud Functions ermöglicht Knative "serverloses" Arbeiten mit Kubernetes-Clustern in jeglichem Cloud-Provider oder einem Bare-Metal-Deployment eigener Wahl.
Mit etwas Code lässt sich Kong als neuer Ingress Layer für Knative aktivieren:
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: helloworld-go
namespace: default
spec:
template:
metadata:
annotations:
konghq.com/plugins: free-tier-rate-limit, prometheus-metrics
spec:
containers:
- image: gcr.io/knative-samples/helloworld-go
env:
- name: TARGET
value: Go Sample v1
Hier wird immer dann, wenn für helloworld-go Traffic eingeht der Knative-Service empfangen & Kong führt zwei Plug-ins aus: free-tier-rate-limit und prometheus-metrics.
Bislang mussten Eigentümer von Services auch jeweils die Plug-in-Konfiguration selbst besitzen. Für Fälle in denen separate Teams übergreifende homogene Konfigurationen brauchten, hat dieser Umstand Probleme verursacht. Das neue Release umfasst als Lösungsangebot eine benutzerdefinierte Ressource auf Cluster-Ebene, das KongClusterPlugin.
Von den Eigenschaften her ist das Plug-in genauso viel mit dem bisherigen Plug-in, im Gegensatz dazu allerdings auf Cluster-Ebene. Entwickler können nun eigene Cluster-Plug-ins erstellen und sie über Namensräume hinweg nutzen. Die Konfigurationen des Plug-ins sind an Benutzerwünsche anpassbar, obwohl dabei nur Nutzer mit entsprechenden Rechten die Befugnis zur Anpassung haben.
Beta-Version von TCPIngress und Breaking Changes
Version 0․8 unterstützt alle Dienste die auf einem benutzerdefinierten Protokoll basieren ? bislang war das nur für gRPC der Fall.
Diese Version wird mit einer wichtigen Änderung ausgeliefert die das Ingress-Routing für ein Cluster unterbrechen kann, wenn es pfadbasiertes Routing verwendet. Bis zum letzten Release hat Kong den Request-Pfad standardmäßig entfernt. Mit dieser Version ist die Funktion standardmäßig deaktiviert. Es steht Entwicklern frei die KongIngress-Ressource oder die neue konghq.com/strip-path-Annotation auf der Ingress-Ressource zu verwenden um dieses Verhalten zu steuern. Wenn man ein Upgrade durchführt, sollte man sicherstellen, dass die beiden neuen Custom Resource Definitions (CRDs) bereits im Kubernetes-Cluster installiert sind.
Alle Neuerungen lassen sich ausführlich in den Release-Notes bei Kong nachlesen. Der komplette Code steht auf GitHub bereit.
Kommentare