Trigger und Broker

Knative 0.5: Neue Objekte für die Eventing-Architektur und Apache Kafka Support

Dominik Mohilo

© Shutterstock / Digital Storm

Seit vergangenem Sommer mischt die Plattform Knative die Welt, zumindest ein wenig, auf. Die Plattform für das Entwickeln von Kubernetes-basierten Serverless-Anwendungen wurde seit dem initialen Release kontinuierlich weiterentwickelt, mit Knative 0.5 ist allerdings nun endlich wieder ein etwas größeres Update durchgeführt worden. Grund genug, sich einmal anzusehen, was die neue Version an Neuem im Gepäck hat.

Die Vorteile von Container- und Serverless-Technologie lassen sich mit Knative recht einfach nutzen. Die Plattform besteht architektonisch (derzeit) aus drei Komponenten: Der Build-Komponente für die Source-to-Container Build-Orchestrierung, der Eventing-Komponenten für das Management und die Auslieferung von Events und der Serving-Komponente für bedarfsgerechte Skalierung, auch auf 0 Instanzen.

Knative 0.5: Trigger- & Broker-Objekte, Apache Kafka

Zwar haben auch die Bereiche Serving und Buildung einige Bugfixes bzw. neue Features erhalten, doch die größte Neuigkeit von Knative 0.5 ist in der Eventing-Komponente zu verzeichnen: Die neuen Trigger- bzw. Broker-Objekte. Die neuen Objekte sollen es leichter machen, Events zu filtern.

Eventing: Broker, Trigger, Kafka

Der Broker stellt hierbei – ganz wie der Name bereits erkennen lässt – die zentrale Verteilstelle für Events dar. Er stellt einen Pool solcher zur Verfügung, die dann via Attribut ausgewählt werden können, nimmt Events in diesen Pool auf und leitet sie an die richtigen Stellen (basierend auf Triggern) weiter. Soll heißen: Der jeweilige Entwickler oder User schreibt Services (oder konfiguriert andere Quellen entsprechend), die einen Event zum Broker übertragen, der diesen dann verteilt. Um Events zu erhalten, müssen die Services lediglich einen zum gewollten Event passenden Trigger erstellen, schon liefert der Broker es.

Mit Trigger-Objekten lassen sich Events, wie oben beschrieben, nach einem gewünschten Filter automatisch anfordern. Für Entwickler bedeutet das, dass sie den Transport der benötigten Events nicht mehr selbst provisionieren und diese auch nicht mehr an die richtige Stelle (also den Knative-Service) routen müssen. Trigger können im Übrigen so viele erstellt werden, wie es das Herz begehrt.


Trigger- & Broker-Objekte in Knative / Quelle: Dokumentation von Knative.

Zu den oben erwähnten anderen Event-Quellen, die der Entwickler für die Nutzung konfigurieren kann, gehören ab Knative 0.5 auch Apache Kafka Events. Big Data wird damit auch im Knative- und damit im Serverless-Universum nach altbekanntem Muster des Kafka-Ökosystems verfügbar.

Weitere Änderungen

Während in der Build-Komponente nur kleinere Bugfixes stattfanden, wurden im Bereich Serving auch etwas größere Maßnahmen durchgeführt. Die automatische Skalierung läuft daher ab sofort ein wenig glatter und effizienter ab. Auch das Streaming von gRPC ist für Knative 0.5 verbessert worden. Beim Kaltstart, also nachdem ein Service auf 0 skaliert wurde, wird eine gRPC-Anfrage erfolgreich zurückgegeben.

Auch von der Task Force, die den Namen „v1beta1“ trägt, gibt es gute Neuigkeiten: Die URLs benannter Sub-Routen sind nun im Status der Service- und Route-Ressourcen sichtbar. Über die neue ConfigMap config-defaults lassen sich einige Standardwerte neuerdings konfigurieren.

Alle Informationen zum aktuellen Release gibt es einerseits im Blog-Beitrag von Mark Chmarny, andererseits auf GitHub (aufgeteilt in Serving, Eventing und Build). In der offiziellen Dokumentation von Knative gibt es übrigens eine Übersicht zu den neuen Trigger- und Broker-Objekten.

Geschrieben von
Dominik Mohilo
Dominik Mohilo
Dominik Mohilo studierte Germanistik und Soziologie an der Goethe-Universität in Frankfurt. Seit 2015 ist er Redakteur bei S&S-Media.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: