DevOps verschmilzt die Grenzen zwischen Software-Entwicklung und IT-Betrieb. Für Developer ist die Bereitstellung der Infrastruktur für eine Software allerdings oftmals ein notwendiges Übel, um das es sich zu kümmern gilt. Dies betrifft nicht nur die Entwicklungs- und Testumgebung, sondern zählt ebenso, wenn es darum geht, die Software in die Produktion zu überführen und dort regelmäßig mit neuen Updates zu versorgen.

Kubernetes ist seit einigen Jahren der De-facto-Standard, wenn es um die Orchestrierung von Containern geht. In einer solchen Umgebung funktioniert das Deployment und Management von Containern recht einfach und ist nicht mit früheren Zeiten zu vergleichen, in der Software primär auf physischen Systemen wohnte. Trotzdem kostet es immer noch Zeit und erfordert nicht gerade wenig Know-how, um eine passende Umgebung für eine neue Container-Software bereitzustellen.

Das gilt insbesondere auch dann, wenn es darum geht, für die richtige Skalierung der notwendigen Ressourcen zu sorgen. Von daher gibt es schon seit einiger Zeit den Ansatz, diese Aufgabe zu automatisieren und die Skalierung Event-basiert zu gestalten. Die freie Software Knative [1] zielt genau in diese Richtung – auch mit der Idee, dass sich Software-Entwickler wieder auf Ihre eigentliche Arbeit, das Schreiben von Code, konzentrieren können und sich nicht mit der Infrastruktur herumschlagen müssen.

Knative wurde auf der Google Cloud Next Konferenz im Jahr 2018 von Google vorgestellt, tatsächlich beteiligen sich aber mehr als 50 Firmen aus der Open-Source-Welt an der Entwicklung. Neben Google selbst zählen beispielsweise auch Red Hat, IBM, Pivotal, SAP und diverse Startup-Unternehmen dazu. Der Name Knative setzt sich dabei aus "Kubernetes" und "native" zusammen, was verdeutlichen soll, dass Knative ein "First-class Citizen" [2] innerhalb einer Kubernetes-Landschaft ist.

Das bedeutet, dass die Software auf bestehende Kubernetes-APIs aufsetzt und Knative-Ressourcen – wie in der Kubernetes-Welt üblich – über YAML-Dateien oder Operatoren eingebunden werden. Das hat zudem den Nebeneffekt, dass die gleichen Tools wie auch für Kubernetes zur Verwaltung zum Einsatz kommen können. Die Software ist bereits Teil einiger Kubernetes-basierter Cloudlösungen wie beispielsweise der Google Kubernetes Engine oder Red Hat OpenShift Serverless. Vergleichbar ist sie mit ähnlichen Angeboten wie Microsoft Azure Functions, Google Cloud Functions oder AWS Lambda.

Ein Begriff fällt immer wieder im Zusammenhang mit Kubernetes und Knative, weshalb wir diesen kurz einordnen wollen: Serverless-Computing. Vereinfacht gesagt bedeutet dies eigentlich nichts anderes, als dass das Framework, auf dem die Software läuft, sich selbstständig darum kümmert, die zum Betrieb der Software notwendigen Ressourcen bereitzustellen und basierend auf dem tatsächlichen Bedarf zu skalieren. Im Zweifelsfall kann dies auch bedeuten, dass sämtliche Ressourcen wieder freigegeben werden, wenn die Software diese nicht benötigt. Da Anwender zumeist nur die Ressourcen bezahlen, die sie auch tatsächlich in Anspruch nehmen, kann dies am Ende eine große Kostenersparnis bedeuten. Wenn in diesem Artikel von Ressourcen die Rede ist, dann handelt es sich zumeist um typische Kubernetes-Objekte wie beispielsweise Container, Pods, Services, Netzwerke oder andere Kubernetes-Cluster-Ressourcen.

In jedem Fall ist es wichtig sich klar zu machen, dass Container-Anwendungen zumeist auf einer Mikroservice-Architektur basieren. Das heißt, es existieren viele unterschiedliche und wiederverwendbare Softwarebausteine (manchmal auch als Funktionen oder Module bezeichnet), die teilweise gar nicht alle aktiv sind, sondern Event-basiert starten. Ob die einzelnen Module oder Funktionen dabei lokal, innerhalb einer hybriden Cloudumgebung oder im Rechenzentrum eines Drittanbieters laufen, spielt dabei eigentlich gar keine Rolle mehr. Wichtig ist lediglich, dass Kontrolle über die notwendigen Ressourcen besteht, um diese bei Bedarf für die Ausführung eines Mikroservices oder einer Softwarefunktion zur Verfügung zu stellen.

Ein klassisches Beispiel ist die Anmeldung an einer Anwendung mithilfe von Social-Media-Accounts. Die Funktion lässt sich als eigenständiges Modul vom Rest der Anwendung kapseln. Aufrufen können Sie eine solche Funktion dann klassisch über ein synchrones Request-/ Response-Modell oder asynchron über dynamisch gesteuerte Events. Da die Funktion nur dann aktiv ist, wenn diese tatsächlich benötigt wird, kommen natürlich auch nur in diesem Fall Ressourcen zum Einsatz und letztendlich auch beim Cloudanbieter auf die Rechnung. Das ganze Konzept wird auch manchmal als Function-as-a-Service (FaaS) bezeichnet, was eine Art Programmiermodell für Cloudanwendungen darstellt. Dieses Modell eignet sich sehr gut beim Einsatz von Serverless-Computing, was wiederum eher als Deployment-Modell für eine solche Umgebung zu verstehen ist.

Beim Source-to-Image-(S2I)-Workflow geht es darum, aus dem Code einer Software ein reproduzierbares Container-Image zu erzeugen, auf dessen Basis Sie dann neue Container anlegen. Hierfür existiert zumeist ein sogenanntes Build-Template, das beschreibt, aus welcher Quelle der Programmcode kommt (beispielsweise ein Git-Repository) und wie der Zugriff hierauf funktioniert.

Der eigentliche Build-Vorgang erfolgt dann durch die Instanzierung eines solchen Build-Templates, was ein fertiges Image als Ergebnis liefert. In Knative kommt mittlerweile Tekton [3] als Buildtool zum Einsatz. Die Software ist bereits aus klassischen CI/CD-Umgebungen bekannt und hat mit der Knative Version 0.8.0 das native Knative-Buildtool abgelöst.

Eine Klippe, die es gerade in der Container-Welt immer wieder zu umschiffen gilt, stellt das Routing der Informationen zwischen den nur lose gekoppelten Mikroservices einer nativen Cloudanwendung dar. Des Weiteren muss natürlich auch sichergestellt werden, dass die Services innerhalb eines Clusters oder auch über Cluster-Grenzen hinweg korrekt gefunden werden. Ein Service Mesh können Sie sich als eine Art Reverse-Proxy und Loadbalancer vorstellen, der sich darum kümmert, die eingehenden Anfragen an die einzelnen Container und die darin laufenden Services zu verteilen. Ein solches Service Mesh kann aber auch dabei helfen, persistente Dienste wie beispielsweise Datenbanken zu integrieren.

Und auch das Deployment von neuen Versionen einer Software kann ein Service Mesh unterstützen. Stellen Sie sich vor, Sie haben eine neue Version des Programmcodes zur Authentifizierung an Ihrer Anwendung mithilfe eines Social-Media-Anbieters entwickelt und wollen diese neue Version nun in Produktion bringen. Zumeist läuft die neue Version dann parallel mit der alten und die eingehenden Anfragen werden dann nur nach und nach an die neue Anwendung geleitet. Somit können Sie neue Software im produktiven Betrieb erst einmal langsam einführen, ohne diese direkt der vollen Last auszusetzen. Knative setzt die Software Istio als Service Mesh ein [4].

Mit diesem Hintergrundwissen sollte es nun leichter fallen, zu verstehen, was Knative ist und wofür Sie es einsetzen können. Das Framework besteht aus den zwei primären Komponenten Serving und Eventing. Diese können bei Bedarf auch getrennt voneinander zum Einsatz kommen. Die Serving-Komponente stellt das Herzstück einer Knative-Installation dar und kümmert sich um alle Aufgaben, die für Serverless-Computing notwendig sind.

Dazu zählen das Bereitstellen der notwendigen Ressourcen, wie Container, Images, Pods, Netzwerke und die automatische Skalierung dieser Ressourcen. Werden mehrere Instanzen einer Software benötigt, so sind hierfür auch zusätzliche Container zu provisionieren. Hat die Anwendung eine geringe Last, kümmert sich Knative auch um die Skalierung bis auf Null und gibt sämtliche Ressourcen wieder frei. Die Ressourcen für eine Serverless-Anwendung definiert Knative als sogenannte Custom Resource Definitions (CRDs).

Die zweite Knative-Basiskomponente ist das Eventing. Wie der Name vermuten lässt, sorgt diese dafür, dass auf Basis von Events bestimmte Ereignisse ausgeführt werden. Unabhängig von der Event-Quelle (Event-Source) erwartet Knative die Beschreibung der Ereignisse auf Basis der CloudEvents-Spezifikation [5]. Die so formatierte Nachricht wird im einfachsten Fall von einer Event-Quelle mit einem Consumer verbunden. Ein solcher Consumer kann beispielsweise ein bestimmter Kubernetes-Service sein, der unter der Kontrolle des Knative Serving steht.

Durch das Eventing können Sie diesen Service also – je nach Art des eingetretenen Events – beliebig skalieren. Für komplexere Aufgaben eignet sich der Einsatz eines Channels zwischen Event-Source und dem Consumer. Dies erlaubt die Verwaltung von Events auch über eine Queue, auf die unterschiedliche Consumer zugreifen können. Channels können außerdem über Schnittstellen für externe Messaging- oder Data-Pipeline-Dienste wie beispielsweise Apache Kafka verfügen. Die Consumer der Channels bezeichnen wir in diesem Zusammenhang dann auch als Subscriber. Wie die Abarbeitung einer Channel-Queue erfolgt, legen die Subscriber selbst fest (Bild 2).

Möchten Sie die Software einmal ausprobieren, existieren hierfür unterschiedliche Möglichkeiten. In jedem Fall benötigen Sie eine bestehende Kubernetes-Umgebung. Haben Sie diese nicht im Zugriff und sind vom Zeitaufwand eines neuen Deployment abgeschreckt, können Sie zu Testzwecken ganz einfach auf ein Minikube-Setup [6] zurückgreifen und somit einen Single-Node-Kubernetes-Cluster auch auf einem Notebook installieren und dann Knative entweder über YAML-Dateien oder einen Operator deployen. Die Knative-Dokumentation [7] hält alle notwendigen Informationen hierfür bereit. Ein sehr umfangreiches Tutorial, das ein Setup auf Basis von Minikube durchführt, finden Sie im GitHub-Repository der "Red Hat Developer Demos" [8].

Alternativ zu diesem manuellen Ansatz können Sie ebenfalls auf eine der zahlreichen Cloudanbieter zurückgreifen und eine Knative-Installation innerhalb der jeweiligen Kubernetes-Management-

Umgebung starten. Dies ist zumeist komfortabler und weniger fehleranfällig, als ein komplettes Setup manuell durchzuführen. Unter [9] finden Sie beispielsweise die Anleitung zum Setup von

Knative als Teil der "Red Hat OpenShift Serverless Platform".

Mit Knative lassen sich sehr einfach Serverless-Anwendungen deployen, ohne sich Gedanken um die zu Grunde liegende Infrastruktur machen zu müssen. Nicht erst durch den Siegeszug von IoT-Geräten findet dieses Deployment-Modell immer mehr Anhänger, da es sich überall einsetzen lässt, wo bestimmte Aufgaben an externe Funktionen ausgelagert werden müssen. Anders als reine FaaS-Dienste wie beispielsweise AWS Lamba stellt Knative zusätzlich eine Reihe von Middleware-Komponenten zur Verfügung, die sich dann beispielsweise um das Netzwerk oder das Service-Discovery kümmern. Ein weiterer Vorteil von Knative ist, dass es auf einer beliebigen Kubernetes-Plattform lauffähig ist.