© Avesun/Shutterstock.com
Serverless Workloads auf Kubernetes mit Knative

Knative: Eine Einführung


Das Stichwort Serverless ist heutzutage in aller Munde. Man kann den Begriff mögen oder nicht, wichtig ist jedoch, was er beschreibt. Kurz und bündig beschrieben bedeutet Serverless, dass eine Anwendung von der Skalierung her fortwährend so angepasst wird, dass immer genau die Ressourcen zur Verfügung stehen, die gerade benötigt werden. Im Zweifelsfall bedeutet das auch: gar keine! Für den Nutzer heißt das, dass er stets nur für die Kapazität bezahlt, die für das Beantworten der Anfragen zu seiner Anwendung benötigt werden. Ohne Nutzer bzw. Anfragen zahlt er eben gar nichts.

Video: Container vs. Serverless - The Good, the Bad and the Ugly

Ein zweiter Themenbereich, an dem man heute nicht mehr vorbeikommt, sind Container. Und damit zusammenhängend an der Containerorchestrierung. Diese beschäftigt sich mit dem effizienten Verteilen und Managen von Containern innerhalb eines Clusters von Maschinen. Im gleichen Atemzug kann man eigentlich auch schon Kubernetes erwähnen, da es den De-facto-Standard [1] für die Orchestrierung von Containern darstellt.

Was wäre nun, wenn man die Möglichkeiten beider Welten zusammenführen würde und eine Plattform hätte, die die Eigenschaften von Serverless und das ausgereifte Container- und Anwendungsmanagement von Kubernetes verbindet? Es gibt einige, die das versuchen: Zum einen gibt es sogenannte Function-as-a-Service-(FaaS-)Frameworks wie OpenWhisk, Kubeless und OpenFaaS oder Platform-as-a-Service-(PaaS-)Frameworks wie CloudFoundry.

FaaS-Frameworks bieten dem Nutzer die Möglichkeit, eine Funktion buchstäblich im programmatischen Sinne zu deployen. Diese Funktion wird dann als Antwort auf ein Event ausgeführt. PaaS-Frameworks hingegen sind eher auf langlaufende Prozesse fokussiert, die über eine HTTP-Schnittstelle verfügbar sind. Beide Ansätze haben in der Regel einen Mechanismus, der aus einem Stück Quellcode eine deploybare Einheit erzeugt. All diese Frameworks konzentrieren sich also letztlich auf einen bestimmten Typus von Workload und unterscheiden sich in der Art und Weise ihrer Nutzung teilweise erheblich.

Und was wäre nun, wenn es eine Plattform geben würde, die sowohl langlaufende Anwendungen als auch sehr kurzlebige Funktionen und generell Anwendungen jeglicher Größe in einer gemeinsamen Topologie und Terminologie vereint?

Willkommen bei Knative!

Knative ist ein Open-Source-Projekt, das von Google inittiert und von einigen weiteren Riesen der Branche unterstützt wird. Dazu zählen unter anderem Pivotal, IBM, Red Hat und SAP, um nur einige zu nennen. Die Beteiligten bezeichnen Knative als einen Satz von Kubernetes-basierten Middlewarekomponenten, die den Bau moderner, quellcodezentrierter und containerbasierter Anwendungen ermöglichen. Es wurde inspiriert von anderen Kubernetes-basierten Frameworks im selben Umfeld (s. o.), fasst all deren Best Practices in einem Framework zusammen und erfüllt die folgenden Anforderungen:

  1. Es ist Kubernetes-nativ (daher auch der Name Knative) und arbeitet wie eine Erweiterung von Kubernetes.

  2. Es deckt alle möglichen Arten von Serverless Workloads ab.

  3. Es fasst all diese Workloads unter einer gemeinsamen Topologie und Terminologie zusammen.

Über die Serverless-Komponente hinaus erfüllt es aber noch weitere Anforderungen an eine moderne Entwicklungsplattform:

  1. Es ist für den Entwickler leicht zu bedienen (siehe Beispiel).

  2. Es unterstützt verschiedenste Build-Methoden, um aus Quellcode eine deploybare Einheit (in diesem Fall ein Container-Image) zu erstellen.

  3. Es unterstützt moderne Deployment-Methoden (z. B. automatisiertes Deployment nach Commits).

Wie funktioniert Knative?

Um genauer darauf einzugehen, wie Knative funktioniert und wie es aufgebaut ist, muss zunächst eingegrenzt werden, über welchen Teil von Knative denn eigentlich gerade gesprochen wird. Die Knative-Organisation setzt sich aus einigen Repositories zusammen. Inhaltlich für den Nutzer relevant sind die drei Hauptkomponenten Serving, Build und Eventing.

  • Serving: Das Serving-Projekt ist verantwortlich für sämtliche Belange, die sich um das Deployment und die Skalierung der zu deployenden Anwendungen drehen. Das umfasst auch das Aufsetzen einer geeigneten Netzwerktopologie, um eine Anwendung unter einem gegebenen Hostnamen erreichbar zu machen. Mit der oben getroffenen Beschreibung von Serverless hat dieser Teil sicherlich die größte inhaltliche Überlappung.

  • Build: Wie der Name schon sagt, ist das Build-Projekt dafür verantwortlich, aus Programmcode ein Container-Image zu „bauen“. Dieses Container-Image kann dann beispielsweise von Serving übernommen und deployt werden. Eine interessante Eigenschaft ist hier, dass Build und Serving im gleichen Cluster laufen. Das gebaute Image muss also nicht erst über eine externe Registry transportiert werden, sondern ist direkt an Ort und Stelle.

  • Eventing: Das Eventing-Projekt deckt die ereignisgetriebene Natur von Serverless-Anwendungen ab. Es bietet die Möglichkeiten, eine Event Source mit einem Consumer gepuffert zu verbinden. Ein solcher Consumer kann beispielsweise ein durch Serving verwalteter Service sein.

In diesem Artikel werden wir uns im Speziellen mit dem Serving-Projekt auseinandersetzen, da es, wie aus der obigen Beschreibung ersichtlich wird, das zentralste Projekt von Knative ist. Die beiden Projekte Build und Eventing können sowohl ergänzend zu Serving als auch eigenständig genutzt werden.

Die Interaktion mit dem Knative API findet über das Erstellen von Entitäten mit dem Kubernetes-eigenen kubectl CLI statt. Serving, Build und Eventing definieren jeweils eigene CRDs (Custom Resource Definitions), um die verschiedenen Funktionalitäten des jeweiligen Projekts abzubilden. Die Serving CRDs sind:

Configuration

Eine Configuration legt dar, wie das entsprechende Deployment der Anwendung auszusehen hat. Es legt diverse Parameter fest, darunter etwa schlicht den Namen der Anwendung, das zu verwendende Container-Image oder die maximale Anzahl paralleler Verbindungen, die zu einer Instanz der Anwendung offen sein dürfen. Die Configuration beschreibt also im Wesentlichen die zu deployende Anwendung und ihre Eigenschaften.

Revision

Wie der Name bereits sagt, bildet eine Revision den Status einer Configuration zu einem bestimmten Zeitpunkt ab. Eine Revision wird also aus der Configuration erstellt. Das bedeutet auch, dass eine Revision nicht veränderlich ist, die Configuration aber sehr wohl. Möchte die Nutzerin beispielsweise eine neue Version ihrer Anwendung deployen, so könnte sie das Image aktualisieren. Um diese Aktualisierung dem System bekannt zu machen, verändert sie das Image der Configuration, was wiederum das Erstellen einer neuen Revision auslöst. Die Nutzerin löst durch jede Änderung, die ein neues Deployment benötigt (etwa Änderung des Image, Veränderung von Umgebungsvariablen etc.) das Erstellen einer neuen Revision aus, indem sie die Configuration anpasst. Die Nutzerin agiert für Änderungen niemals mit der Revision selbst. Für welche Änderungen genau eine neue Revision notwendig wird, darum kümmert sich Knative Serving.

Zu jedem Zeitpunkt können also pro Configuration mehrere Revisions aktiv sein. Der Name einer Revision entsprich...

Neugierig geworden?

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