© Excellent backgrounds/Shutterstock.com
Java Magazin
Knative Eventing

Sprudelnde Quellen

Nachdem wir im vorangegangenen Artikel gesehen haben, wie einfach Applikationen deployt und auf null skaliert werden können, widmen wir uns hier der Frage, welche Möglichkeiten existieren, Knative Services mit Event-Quellen zu verbinden. Knative Serving unterstützt ausschließlich HTTP als Service-Protokoll. Jedoch gibt es eine Vielzahl von Protokollen und Möglichkeiten des Datentransports, die über reine HTTP-Kommunikation hinausgehen. Eine typische Eigenschaft dieser Datenquellen ist auch, dass sie asynchron als Events ausliefern und nicht auf das Ergebnis der Verarbeitung warten. Hier setzt Knative Eventing an, das diese Datenquellen mit Knative Services flexibel verbindet und sich zudem um eine sichere und garantierte Auslieferung dieser Events kümmert.

Roland Huß


Je nach Anforderung gibt es verschiedene Ausprägung von Knative Eventing, die sich in ihrer Mächtigkeit und Komplexität unterscheiden. In diesem Artikel werden wir die drei wichtigsten Knative-Eventing-Topologien mit Beispielen kennenlernen und deren Vor- und Nachteile diskutieren.

Installation

Zunächst muss jedoch erst einmal Knative Eventing installiert werden, wozu es verschiedene Möglichkeiten gibt. Sie sind in der Knative Dokumentation [1] aufgelistet. Dazu gehören Installationsanleitungen für Minikube, AKS, GKS, PKS, Gardener und IBM Cloud Kubernetes Service.

Alternativ kann Knative Eventing bei OpenShift 4.1 als Development-Preview sehr leicht mit ein paar Klicks installiert werden. Hierbei werden eigene Operatoren benutzt, die aus dem integrierten Operator Hub heraus installiert werden.

Schließlich gibt es noch verschiedene Knative Tutorials, die bei der Installation von Knative Serving und Eventing helfen. Beispielsweise hat das Knative Tutorial [2] eine sehr detaillierte Installationsanleitung für Minikube und Minishift bereitgestellt.

Für den Rest des Artikels gehen wir davon aus, dass sowohl Knative Eventing als auch Knative Serving installiert sind.

Sprudelnde Quellen

Das Herzstück von Knative Eventing sind die sie sogenannten Event Sources, die Events an eine sogenannte Sink ausliefern. Eine Sink kann dabei ein Knative Service sein, aber, wie wir weiter unten sehen werden, auch andere Knative-Eventing-Elemente mit Channels oder Brokern. Dabei sind diese Sources (Kasten: „Note“) nicht unbedingt die eigentlichen Quellen, sondern eher Adapter, die die eigentliche Quelle wie z. B. Nachrichten von Message Brokern wie Kafka oder AMQ in CloudEvents transformieren. Cloud­Events [3] ist dabei eine Spezifikation zur Beschreibung von Event-Daten, in einem standardisierten Format. Die Spezifikation hat sich als Ziel gesetzt, Interoperabilität über die verschiedensten Dienste, Plattformen und System hinweg zu erreichen. Für CloudEvents existieren verschiedene Transport Bindings. Für Knative Eventing am wichtigsten ist das HTTP Binding, bei dem Events via HTTP POST übertragen werden. CloudEvents kennt mehrere Optionen, wie Metadaten übertragen werden: Entweder als Teil der JSON-Event-Struktur selbst (structured) oder als HTTP-Header (binary). Knative Eventing verwendet den Binary Mode so, dass zur Auswertung der Metadaten die HTTP-Header evaluiert werden müssen.

NoteEine Anekdote am Rande: Die Bezeichnung „Sources“ wurde zunächst in „Importer“ geändert, da, wie...

Java Magazin
Knative Eventing

Sprudelnde Quellen

Nachdem wir im vorangegangenen Artikel gesehen haben, wie einfach Applikationen deployt und auf null skaliert werden können, widmen wir uns hier der Frage, welche Möglichkeiten existieren, Knative Services mit Event-Quellen zu verbinden. Knative Serving unterstützt ausschließlich HTTP als Service-Protokoll. Jedoch gibt es eine Vielzahl von Protokollen und Möglichkeiten des Datentransports, die über reine HTTP-Kommunikation hinausgehen. Eine typische Eigenschaft dieser Datenquellen ist auch, dass sie asynchron als Events ausliefern und nicht auf das Ergebnis der Verarbeitung warten. Hier setzt Knative Eventing an, das diese Datenquellen mit Knative Services flexibel verbindet und sich zudem um eine sichere und garantierte Auslieferung dieser Events kümmert.

Roland Huß


Je nach Anforderung gibt es verschiedene Ausprägung von Knative Eventing, die sich in ihrer Mächtigkeit und Komplexität unterscheiden. In diesem Artikel werden wir die drei wichtigsten Knative-Eventing-Topologien mit Beispielen kennenlernen und deren Vor- und Nachteile diskutieren.

Installation

Zunächst muss jedoch erst einmal Knative Eventing installiert werden, wozu es verschiedene Möglichkeiten gibt. Sie sind in der Knative Dokumentation [1] aufgelistet. Dazu gehören Installationsanleitungen für Minikube, AKS, GKS, PKS, Gardener und IBM Cloud Kubernetes Service.

Alternativ kann Knative Eventing bei OpenShift 4.1 als Development-Preview sehr leicht mit ein paar Klicks installiert werden. Hierbei werden eigene Operatoren benutzt, die aus dem integrierten Operator Hub heraus installiert werden.

Schließlich gibt es noch verschiedene Knative Tutorials, die bei der Installation von Knative Serving und Eventing helfen. Beispielsweise hat das Knative Tutorial [2] eine sehr detaillierte Installationsanleitung für Minikube und Minishift bereitgestellt.

Für den Rest des Artikels gehen wir davon aus, dass sowohl Knative Eventing als auch Knative Serving installiert sind.

Sprudelnde Quellen

Das Herzstück von Knative Eventing sind die sie sogenannten Event Sources, die Events an eine sogenannte Sink ausliefern. Eine Sink kann dabei ein Knative Service sein, aber, wie wir weiter unten sehen werden, auch andere Knative-Eventing-Elemente mit Channels oder Brokern. Dabei sind diese Sources (Kasten: „Note“) nicht unbedingt die eigentlichen Quellen, sondern eher Adapter, die die eigentliche Quelle wie z. B. Nachrichten von Message Brokern wie Kafka oder AMQ in CloudEvents transformieren. Cloud­Events [3] ist dabei eine Spezifikation zur Beschreibung von Event-Daten, in einem standardisierten Format. Die Spezifikation hat sich als Ziel gesetzt, Interoperabilität über die verschiedensten Dienste, Plattformen und System hinweg zu erreichen. Für CloudEvents existieren verschiedene Transport Bindings. Für Knative Eventing am wichtigsten ist das HTTP Binding, bei dem Events via HTTP POST übertragen werden. CloudEvents kennt mehrere Optionen, wie Metadaten übertragen werden: Entweder als Teil der JSON-Event-Struktur selbst (structured) oder als HTTP-Header (binary). Knative Eventing verwendet den Binary Mode so, dass zur Auswertung der Metadaten die HTTP-Header evaluiert werden müssen.

NoteEine Anekdote am Rande: Die Bezeichnung „Sources“ wurde zunächst in „Importer“ geändert, da, wie...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang