Seite 2: Serving, Build, Eventing – die Komponenten von Knative

Inhaltsverzeichnis

Knative stellt ein Set von Middleware-Komponenten bereit, die zurzeit vor allem drei Bereiche abdecken: Serving, Build und Eventing. Als Basis dafür benötigt es einen Kubernetes-Cluster auf einer entsprechenden Plattform.

Knative Serving definiert einen Satz von Objekten als Kubernetes Custom Resource Definitions (CRD). Sie kontrollieren und legen fest wie sich der Serverless Workload auf dem Cluster verhält: Dazu zählen das schnelle Deployment von Serverless-Containern, das automatische Up- and Down-Scaling (bei Bedarf bis auf Null), das Routing und die Netzwerkprogrammierung für die Istio-Komponenten.

Knative deployt die Objekte unter dem jeweiligen Serving-Namespace. In der Knative Serving API hat ein Ressourcenpfad folgendes standardisiertes Kubernetes-Format:

/apis/{apiGroup}/{apiVersion}/namespace/{metadata.namespace}/{kind}/{metadata.name}

Die Route benennt den Netzwerkendpunkt für den User Service namentlich. Dabei erwartet Knative, dass die Route einen Namen zur Verfügung stellt, den Knative innerhalb des Cluster-weiten DNS-Systems zuordnet. Mit den Mechanismen des Kubernetes-Namespace lässt sich das einfach umsetzen, um eine URL nach folgendem Schema zu erzeugen:

[$revisionname].$route.$namespace.<common knative cluster suffix>

Die Service-Ressource der Knative-Serving-Komponente verwaltet (service.serving.knative.dev) den gesamten Lebenszyklus eines Workloads. Sie generiert Objekte, damit die Applikation eine Route sowie Konfigurationen hat und nach jedem Service-Update eine Revision stattfindet. Die Route-Ressource (route.serving.knative.dev) mapt einen Netzwerkendpunkt zu einer oder mehreren Revisionen. Damit lassen sich Deployment-Szenarien umsetzen, in denen Entwickler flexibel festlegen können, welche Revision welchen Anteil an der Ausspielung haben soll. Entwickler könnten etwa eine neue Revision in zehn Prozent der Fälle anstoßen und die alte Revision in 90 Prozent.

Die Configuration-Ressource (configuration.serving.knative.dev) stellt sicher, dass der gewünschte Status (desired state) des Deployments bestehen bleibt. Da durch jede Änderung an der Konfiguration eine neue Revision entsteht, lässt sich mit der Revision-Ressource (revision.serving.knative.dev) ein eindeutiger Point-in-Time-Snapshot von Code und Konfiguration erstellen.

Serving stellt eine durch Anfragen gesteuerte Scale-to-Zero Compute Runtime zur Verfügung und nutzt Istio, um den Workload routen zu können. Der folgende Code zeigt ein einfaches Kubernetes-Beispiel, das eine Basisvariante einer Scale-to-Zero-Instanz für einen Container kreiert und das korrespondierende Istio-Routing nutzt Quelle des Codes: Paul Czarkowski:

apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
name: autoscale-go
namespace: default
spec:
runLatest:
configuration:
revisionTemplate:
spec:
container:
image: samples/autoscale-go