Seite 3: Ein Blick auf die Build-Komponente

Inhaltsverzeichnis

Die Knative-Build-Komponente übernimmt das Erstellen von Containern aus dem Sourcecode. Die Übergabe eines Dockerfile ist nicht notwendig. Die Buildpacks (https://buildpacks.io), Bazel (https://bazel.build) oder Buildah (https://github.com/knative/build-templates) erzeugen die Container auf dem Kubernetes-Cluster. Ziel ist es, eine standardisierte, portable, wiederverwendbare und performante Methode dafür zur Verfügung zu stellen.

Während Build-Template (build-template.build.knative.dev) Parameter und Abarbeitungsschritte definiert, stellt Build (build.build.knative.dev) die Verbindung zu einer Quelle her, definiert die Argument Values für die Parameter und berichtet den Status jedes Schritts. Ein Builder (builder.build.knative.dev) ist ein Container-Image, mit dem sich Steps und Prozesse vollendet ausführen lassen, und mit einem Service-Account (serviceaccount.build.knative.dev) findet eine Authentifizierung mit Kubernetes Secrets statt. Knative Builds ist auf das Erstellen, Testen und Deployen von Sourcecode spezialisiert – es gibt noch einige Dinge, um die sich Entwickler kümmern müssen. Zwar übernimmt das Buildpack etwa die Abfrage des Sourcecode, dafür ist aber die Übergabe der Repository-URL notwendig.

Da Knative Custom Resource Definitions (CRD) nutzt, ist der Aufruf eines Build unkompliziert: und zwar durch ein Kubernetes-Manifest, das das Build-Template (im Beispiel das Template Kaniko, das Docker Images erzeugen kann, ohne dass Docker installiert ist) und die Source Location spezifiziert.

apiVersion: build.knative.dev/v1alpha1
kind: Build
metadata:
name: kaniko-build
spec:
serviceAccountName: build-bot
source:
git:
url: https://github.com/my-user/my-repo
revision: master
template:
name: kaniko
arguments:
    • name: IMAGE
value: us.gcr.io/my-project/my-app

Eventing mit Knative

Um das Deployment und das Management von Events kümmert sich die Knative-Eventing-Komponente. Knative basiert grundsätzlich auf einem eventgetriebenen Modell für das Ausführen von Funktionen, sodass der Komponente eine besondere Bedeutung zukommt. Laut ihrer Definition sollen sich ihre Ressourcen um die üblichen Herausforderungen der Cloud-nativen Entwicklung kümmern. Dazu gehören etwa die lose Kopplung zwischen Event-Bereitstellern und den Event-Empfängern oder flexibel kombinierbare Workflows (flow.eventing.knative.dev), die über unabhängig voneinander skalierende Komponenten hinweg funktionieren. Sie sind notwendig, um Events wie Channels (channel.eventing.knative.dev) oder Subscriptions (subscription.eventing.knative.dev) zu transportieren.

Zudem stellt Knative-Eventing Schnittstellen für Messaging/Data-Pipeline-Dienste wie Apache Kafka und Google Cloud Pub/Sub bereit. Mit den Bausteinen lassen sich komplexe Enterprise Integration Patterns umsetzen. Das folgende Beispiel erzeugt einen Feed an Kubernetes-Events und reicht ihn an die Applikation weiter, die auf Basis einer Serving-Komponente namens read-k8s-events läuft:

apiVersion: flows.knative.dev/v1alpha1
kind: Flow
metadata:
name: k8s-event-flow
namespace: default
spec:
serviceAccountName: feed-sa
trigger:
eventType: dev.knative.k8s.events
resource: k8sevents/dev.knative.k8s.event
service: k8events
parameters:
namespace: default
action:
target:
kind: Route
apiVersion: serving.knative.dev/v1alpha1
name: read-k8s-events

Alle Knative-Komponenten funktionieren unabhängig voneinander, ergänzen sich aber. Auf GitHub sind zahlreiche Samples und Issue-Listen verfügbar, weitere Entwicklungen aus der Open-Source-Community sind zu erwarten.

Kommunikationssicherheit dank Istio

Vor allem Google macht sich stark für die Idee, unterhalb einer Container-Plattform eine flache Netzwerkhierarchie, also weniger Firewalls, zu implementieren. Der Verminderung von Hardwaresicherheit müssen Entwickler mit erhöhter Sicherheit auf Softwareebene begegnen. Istio ist ein Service-Mesh, das Microservices ein Vehikel an die Hand geben will, damit sie die Vertrauenswürdigkeit einer Quelle beurteilen können. Die softwaredefinierte Kommunikationsmöglichkeit basiert auf Zertifikaten, die eine zentrale Autorität ausstellt. Dadurch können Sender und Empfänger sicher sein, dass der andere wirklich der ist, der er vorgibt zu sein.

Gerade bei nativ in der Cloud entwickelten Microservices wird das Aufrufverhalten untereinander schnell komplex. Istio hilft, den Überblick und die Kontrolle zu behalten. Das macht es zu einer guten Basis für Knative.

Was bedeutet das für Entwickler?

Knative kommt aus dem Universum der Microservices und Container. Entwickler, die aus der klassischen Anwendungsentwicklung stammen und jetzt vermehrt Microservices entwickeln, mussten ihre Denkweise umstellen. Trafen sie früher stets Annahmen, dass bestimmte Bedingungen wie Betriebssystem, Hardware und Ähnliches für die Anwendung vorhanden sind, geht es bei der Entwicklung von Microservices um das Übergeben von Daten und das Auslösen von Events.

Mit Knative erstellen Entwickler keine kompletten Anwendungen. Für diejenigen, die sich im Microservices-Kosmos bewegen, ist Knative ein nützliches, zusätzliches Tool. Kenntnisse und Erfahrungen mit Kubernetes und Containern sollten vorhanden sein.

Für Entwickler, die mit dem Open-Source-Projekt Riff vertraut sind, ist Knative gewissermaßen eine Weiterentwicklung. Denn Riff beschäftigte sich ebenfalls mit der Erweiterung von Kubernetes und stellte Services für das Event-getriggerte Ausführen von Funktionen zur Verfügung. Die Riff CLI erlaubt es, auf einfache Art und Weise mit der Knative-API zu interagieren und mehrere Ressourcen auf einmal anzulegen. Das Projekt geht nun vollständig in Knative auf.