Kong for Kubernetes 0.8 hat Knative-Unterstützung an Bord

Die Version 0.8 unterstützt nun Knative und bringt zwei neue Plug-ins, durch die es auch als Eingangsschicht zu Knative fungieren können soll.

In Pocket speichern vorlesen Druckansicht 3 Kommentare lesen
Kong for Kubernetes 0.8 hat Knative-Unterstützung an Bord

(Bild: Shutterstock)

Lesezeit: 4 Min.
Von
  • Silke Hahn

Kong for Kubernetes ist in Version 0.8 erschienen. Das neue Release bringt eine vollständige Knative-Integration sowie zwei neue Custom Resource Definitions (CRDs), nämlich KongClusterPlugins und TCPIngress.

Die skalierbare Open-Source-API-Schicht Kong gehört zum Kubernetes-Ökosystem. Ihre Architektur besteht aus zwei Elementen: einem Controller zur Zustandsverwaltung für Kubernetes und einem Gateway, das eingehende und ausgehende API-Aufrufe verarbeitet. Um das neue Release zu nutzen, müssen Entwickler zuvor die aktuellen Versionen von Kong Gateway und Kong Enterprise installieren beziehungsweise ein Upgrade durchführen.

Kong for Kubernetes lässt sich am einfachsten mit einer Zeile Code auf dem Kubernetes-Cluster installieren: $ kubectl apply -f https://raw.githubusercontent.com/Kong/kubernetes-ingress-controller/master/deploy/single/all-in-one-dbless.yaml. Alternativ funktioniert auch folgender Code:

$ helm repo add kong https://charts.konghq.com

$ helm repo update

$ helm install kong/kong

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.

Mit dem neuen Release kann Kong jetzt auch 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 und Umwandlung übernehmen. Das bedeutet, dass HTTP-basierte "serverlose" Ereignisse von Knative automatisch durch Kong geleitet werden und sich entsprechend getrennt verwalten lassen. Die eigentlichen Knative-Dienste sollen dadurch "schlank" bleiben und sich auf die Geschäftslogik konzentrieren.

Kong als Ingress Layer für Knative-Workloads

(Bild: Kong)

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.

Darstellung "serverloser" Workloads mit Knative auf Kubernetes

(Bild: Kong)

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, und 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 identisch 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, wobei nur Nutzer mit entsprechenden Rechten die Befugnis zur Anpassung haben.

Version 0.8 unterstützt alle Dienste, die auf einem benutzerdefinierten Protokoll basieren – bislang war das nur für gRPC der Fall.

Funktionsweise des Plug-ins TCPIngress (Beta-Release)

(Bild: Kong)

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.

Update-Hinweis [30.03.2020]: Um die Transparenz zu erhöhen, haben wir den bit.ly-Link im Installationshinweis aufgelöst. (sih)