© Javier Calvete/Shutterstock.com
Einführung zu Knative und seinen Komponenten

Knative: Serverless Apps deployen


Knative schließt die Lücke zwischen der Containerorchestrierung mit Kubernetes und Serverless Computing. Die Komponenten Serving, Build und Eventing, die die Open-Source-Plattform mitbringt, um Event-getriebene Funktionen zu deployen, beschreibt dieser Artikel im Überblick.

Dass Serverless Computing nicht ohne Server funktioniert, ist klar. Hinter dem Buzzword steckt aber eine Philosophie, die sich in der Entwicklung des Cloud-Computings und dem Wunsch der Entwickler, sich mehr um Code und weniger um Infrastrukturen zu kümmern, begründet. Denn auch wenn Cloud-Services den Administratoren und Developern einiges an Arbeit abnehmen – selbst bei Platform-as-a-Service-(PaaS-)Diensten muss der Nutzer mit den APIs interagieren. Nur dann kann die Skalierung bei Bedarf sichergestellt werden. So entfällt in der Praxis durch die Nutzung von weitgehend gemanagten Cloudressourcen zwar einiges an Aufwand für das Aufsetzen und Betreiben der notwendigen Infrastruktur und entsprechenden Backend Services. Dennoch müssen sich Entwickler noch immer mit benötigten Laufzeitumgebungen, Deployment-Parametern und Ähnlichem befassen.

Serverless will das ändern. Der Serverless Service, weiterhin durch Server im Backend des Clouddienstleisters betrieben, stellt automatisch alle notwendigen Ressourcen bereit, und zwar genau dann, wenn die Anwendung sie anfordert. Entstanden ist diese Event-getriebene Abarbeitung vor allem durch Anwendungen und Services, die immer wieder oder tausendfach hintereinander ausgeführt werden müssen. Wenn etwa Daten aus einer Public Cloud in einen Data Warehouse geladen werden sollen – typisch dafür sind beispielsweise ETL-Prozesse – führt das System immer wieder denselben Prozess durch. Knative sorgt dann dafür, dass jederzeit genügend Rechenkapazitäten zur Verfügung stehen, ohne dass sich der Entwickler jedes Mal neu darum kümmern muss.

Containerorchestrierung mit Kubernetes

Trends wie die Entwicklung hin zu Microservices sowie die Containerisierung untermauern den Serverless-Gedanken. In einem Container werden mit der eigentlichen Anwendung zusätzliche Informationen (Laufzeitparameter, Bibliotheken etc.) verpackt, die notwendig sind, um die App zu starten. Der Vorteil: Man kann vorgefertigte Basisbetriebssysteme verwenden. Ein eigenes Betriebssystem mit eigener virtueller Maschine ist nicht notwendig, die App startet dadurch schneller, und das Container-Image ist einfacher portierbar. Für einzelne Anwendungen bleibt dieser Prozess leicht überschaubar. Verwendet man viele Container, wird ein Orchestrierungstool notwendig. Kubernetes automatisiert das Einrichten, Betreiben und Skalieren von containerisierten Anwendungen. Eine große Community unterstützt das Docker-nahe Tool, namhafte Cloudanbieter von Microsoft bis Amazon tun dies ebenso. Zwischen der Containerorchestrierung mit Kubernetes und einem Serverless Deployment fehlt jedoch noch das verbindende Element.

Knative schließt die Lücke

Knative soll genau diese Plattform dazwischen sein: Es soll ein Standard entstehen, damit Functions oder Microservices sowohl innerhalb einer Public Cloud als auch beliebig zwischen mehreren Clouds unterschiedlicher Ausprägung hin und her portiert werden können. Nur so kann der Prozess flexibel und automatisch auf weitere Ressourcen zugreifen. Wer containerbasierte Functions und Microservices in Serverless-Umgebungen nutzen wollte, scheiterte bisher an den verschiedenen Anforderungen der Cloudanbieter – hier fehlen schlicht die Standards.

Knative ist als Open-Source-Projekt konzipiert. Von Google und Pivotal ins Leben gerufen, hat die Initiative zahlreiche namhafte Unterstützer gefunden, darunter IBM und Red Hat, die teilweise sogar Entwickler in Vollzeit für die Weiterentwicklung abstellen. Knative ist als Rundumunterstützung gedacht: Mit Kubernetes und Istio als Basis soll es Nutzern dabei helfen, Anwendungen zu entwickeln, in Container zu packen, die Apps auszuführen und schließlich die Infrastruktur zu skalieren. Dabei konzentriert sich Knative vor allem auf drei Kernbereiche (Kasten: „Knative und die beschriebenen Komponenten im Überblick“): die Erstellung der Anwendung im Container (Build), die Bereitstellung des Containers und somit der Anwendung (Serving) sowie die Möglichkeit, dass Anwendungen einfach auf Ereignisse reagieren und sie somit leicht konsumieren und produzieren können (Eventing).

Knative und die beschriebenen Komponenten im Überblick

  • Knative Serving: Configuration, Revision, Route, Service

  • Knative Build: Build, Build Templates (als Beispiele Buildpacks, kaniko, jib), Service Accounts, Pipelines

  • Knative Eventing: Source, Channels, Subscriptions

Ein ausführlicher Überblick über Knative-Komponenten ist auf GitHub [1] hinterlegt.

Die Serving-Komponente

Knative Serving kümmert sich um die Bereitstellung und Ausführung von Serverless Workloads, indem es die einfache Bereitstellung eines vorkonfigurierten Image für den darunter liegenden Kubernetes-Cluster ermöglicht. Dafür wird ein Satz von Objekten als Custom Resource Definitions (CRD) festgelegt. In Kubernetes ist eine Resource gewissermaßen der Endpunkt der API-Schnittstelle, an dem verschiedene API Objects gespeichert sind. Eine Custom Resource ist hingegen eine Extension eines Kubernetes API, die nicht zwingend in der Defaultversion von Kubernetes enthalten ist – es handelt sich um spezielle Anpassungen, die Kubernetes modularer machen. Ist eine Custom Resource einmal installiert, können Nutzer ihre Objekte wie gewohnt (Command Line Interface kubectl) kreieren und ansprechen.

Die CRD-Objekte (Configuration, Revision, Route und Service) steuern, wie sich der Serverless Workload verhält. Knative Serving verwaltet zum Beispiel Point in Time Snapshots, sorgt für das schnelle Deployment von Serverless-Containern, bietet eine automatische, von Anfragen gesteuerte Skalierung (sowohl nach oben als auch nach unten, bei Bedarf bis auf null) und übernimmt das notwendige Routing sowie die Netzwerkprogrammierung für die Istio-Komponenten.

Die Objekte Configuration und Revision haben folgende Funktionalitäten: Mit Configuration wird definiert, welches der gewünschte Status (Desired State) des Deployments sein soll. Dafür wird mindestens e...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang