Architekturübersicht über Knative Serving

Auf dieser Seite erhalten Sie einen Überblick über die Architektur von Knative Serving und erfahren, was geschieht, wenn Sie Knative Serving in Ihrem Google Kubernetes Engine-Cluster aktivieren.

Diese Informationen sind für die folgenden Nutzertypen nützlich:

  • Nutzer, die mit Knative Serving beginnen.
  • Operatoren mit Erfahrung in der Ausführung von GKE-Clustern
  • Anwendungsentwickler, die mehr darüber erfahren möchten, wie Knative Serving in Kubernetes-Cluster eingebunden wird, um bessere Anwendungen zu entwickeln oder ihre Knative Serving-Anwendung zu konfigurieren.

Komponenten in der Standardinstallation

Installieren Sie Knative Serving in Ihrem Cluster, um eine Verbindung für Ihre zustandslosen Arbeitslasten herzustellen und diese zu verwalten. Knative-Komponenten werden im Namespace knative-serving erstellt.

Bei Knative Serving wird Cloud Service Mesh zum Weiterleiten von Traffic verwendet. Standardmäßig installiert Cloud Service Mesh-Komponenten im Namespace istio-system.

Hier finden Sie eine Liste der Komponenten, die von Knative Serving und Cloud Service Mesh installiert werden:

  • Von Knative Serving im Namespace knative-serving installierte Komponenten:

    • Activator Wenn Pods auf null herunterskaliert oder mit Anfragen überlastet werden, die an die Überarbeitung gesendet werden, stellt der Aktivator die Anfragen vorübergehend in die Warteschlange und sendet Messwerte an Autoscaling, um weitere Pods einzurichten. Sobald Autoscaling die Überarbeitung basierend auf den gemeldeten Messwerten und verfügbaren Pods skaliert, leitet der Aktivator die Anfragen aus der Warteschlange an die Überarbeitung weiter. Der Aktivator ist eine Komponente der Datenebene. Komponenten der Datenebene verwalten alle Funktionen und Prozesse zur Weiterleitung des Nutzertraffics.
    • Autoscaling: Fasst die Messwerte vom Aktivator und dem Sidecar-Warteschlangen-Proxycontainer zusammen, einer Komponente in der Datenebene, die Gleichzeitigkeitslimits von Anfragen erzwingt. Autoscaling berechnet anschließend die beobachtete Gleichzeitigkeit für die Überarbeitung und passt die Bereitstellungsgröße auf Basis der gewünschten Pod-Anzahl an. Wenn Pods in der Überarbeitung verfügbar sind, ist Autoscaling eine Komponente der Steuerungsebene. Andernfalls ist Autoscaling eine Komponente der Datenebene, wenn die Pods auf null herunterskaliert werden.
    • Controller: Erstellt und aktualisiert die untergeordneten Ressourcen von Autoscaling und die Serviceobjekte. Der Controller ist eine Komponente der Steuerungsebene. Komponenten der Steuerungsebene verwalten alle Funktionen und Prozesse, die den Anfragepfad des Nutzertraffics festlegen.
    • Metrics Collector: Erfasst Messwerte aus Knative Serving-Komponenten und leitet sie dann an Cloud Monitoring weiter.
    • Webhook Legt Standardwerte fest, lehnt inkonsistente und ungültige Objekte ab und validiert und mutates Kubernetes API-Aufrufe für: Knative Serving-Ressourcen. Der Webhook ist eine Komponente der Steuerungsebene.

  • Komponenten, die von Cloud Service Mesh installiert werden und im Namespace istio-system ausgeführt werden:

    • Lokales Clustergateway: Load Balancer in der Datenebene, der für die Verarbeitung des internen Traffics zuständig ist, der von einem Knative-Dienst an einen anderen gesendet wird. Auf das lokale Clustergateway kann nur innerhalb Ihres GKE-Clusters zugegriffen werden. Es wird keine externe Domain registriert, um eine versehentliche Veröffentlichung privater Informationen oder interner Prozesse zu verhindern.
    • Istio Ingress Gateway: Load-Balancer in der Datenebene, der für den Empfang und die Verarbeitung von eingehendem Traffic von außerhalb des Clusters zuständig ist, einschließlich des Traffics von externen oder internen Netzwerken.
    • Istiod: Konfiguriert das lokale Clustergateway und das Istio-Ingress-Gateway für die Verarbeitung von HTTP-Anfragen an den richtigen Endpunkten. Istiod ist eine Komponente der Steuerungsebene. Weitere Informationen finden Sie unter Istiod.

Die Komponenten von Knative Serving werden automatisch mit allen Clusteraktualisierungen der GKE-Steuerungsebene aktualisiert. Weitere Informationen finden Sie unter Verfügbare GKE-Versionen.

Nutzung von Clusterressourcen

Die Erstinstallation von Knative Serving erfordert ungefähr 1,5 virtuelle CPU und 1 GB Arbeitsspeicher für Ihren Cluster. Die Anzahl der Knoten in Ihrem Cluster hat keinen Einfluss auf den Speicherplatzbedarf und die Arbeitsspeicheranforderungen für eine Knative Serving-Installation.

Ein Aktivator kann Anfragen mit maximal 1.000 MilliCPU und 600 MiB RAM verarbeiten. Kann ein vorhandener Aktivator die Anzahl der eingehenden Anfragen nicht unterstützen, wird ein zusätzlicher Aktivator ausgelöst, der eine Reservierung von 300 MilliCPU und 60 MiB RAM erfordert.

Jeder vom Knative Serving-Dienst erstellte Pod erstellt einen Sidecar-Warteschlangenproxy, der die Gleichzeitigkeitslimits von Anfragen erzwingt. Der Warteschlangenproxy reserviert 25 MilliCPU und hat keine Arbeitsspeicherreservierung. Die Nutzung des Warteschlangenproxys hängt von der Anzahl der Anfragen in der Warteschlange und der Größe der Anfragen ab. Es gibt keine Beschränkungen für die CPU- und Arbeitsspeicherressourcen, die verbraucht werden können.

Dienst erstellen

Diagramm zur Architektur von Knative Serving-Diensten
Knative Serving-Architektur (zum Vergrößern anklicken)

Knative Serving erweitert Kubernetes durch die Definition einer Reihe von benutzerdefinierten Ressourcendefinitionen (CRDs): Dienst, Überarbeitung, Konfiguration und Route. Diese CRDs definieren und steuern das Verhalten der Anwendungen auf dem Cluster:

  • Der Knative Serving-Dienst ist die von Knative Serving definierte benutzerdefinierte Ressource der obersten Ebene. Es ist eine einzelne Anwendung, die den gesamten Lebenszyklus Ihrer Arbeitslast verwaltet. Der Dienst stellt sicher, dass Ihre Anwendung eine Route, eine Konfiguration und eine neue Überarbeitung für jede Aktualisierung des Dienstes hat.
  • Die Überarbeitung ist ein unveränderlicher Snapshot des Codes und der Konfiguration zu einem bestimmten Zeitpunkt.
  • In der Konfiguration werden die aktuellen Einstellungen für die letzte Überarbeitung verwaltet und ein Verlauf aller früheren Überarbeitungen aufgezeichnet. Wenn Sie eine Konfiguration ändern, wird eine neue Überarbeitung erstellt.
  • Die Route definiert einen HTTP-Endpunkt und verknüpft den Endpunkt mit einer oder mehreren Überarbeitungen, an die Anfragen weitergeleitet werden.

Wenn ein Nutzer einen Knative Serving-Dienst erstellt, geschieht Folgendes:

  1. Das Knative Serving-Dienstobjekt definiert Folgendes:

    1. Eine Konfiguration für die Bereitstellung der Überarbeitungen.
    2. Eine unveränderliche Überarbeitung für diese Version des Dienstes.
    3. Eine Route zum Verwalten der angegebenen Trafficzuordnung zur Überarbeitung.

  2. Das Routenobjekt erstellt den VirtualService. Das VirtualService-Objekt konfiguriert das Ingress-Gateway und lokale Clustergateway so, dass der Gatewaytraffic an die richtige Version weitergeleitet wird.

  3. Das Überarbeitungssobjekt erstellt die folgenden Komponenten der Steuerungsebene: ein Kubernetes-Serviceobjekt und ein Bereitstellungsobjekt.

  4. Die Netzwerkkonfiguration verbindet den Aktivator, Autoscaling und den Load-Balancer für Ihre Anwendung.

Anfragen verarbeiten

Das folgende Diagramm zeigt eine allgemeine Übersicht über einen möglichen Anfragepfad für Nutzertraffic über die Komponenten der Datenebene für Knative Serving auf einem Google Kubernetes Engine-Beispielcluster:

Diagramm zur Architektur des Knative Serving-Clusters
Knative Servingclusterarchitektur (zum Vergrößern anklicken)

Das nächste Diagramm ist eine Erweiterung aus dem obigen Diagramm, um einen detaillierten Überblick über den Anfragepfad des Nutzertraffics zu geben, der auch unten detailliert beschrieben wird:

Diagramm zum Knative Serving-Anfragepfad
Knative Serving-Anfragepfad (zum Vergrößern klicken)

Für einen Knative Serving-Anfragepfad:

  1. Der Traffic trifft ein über:

    • Das Ingress-Gateway für Traffic von außerhalb von Clustern
    • Das lokale Cluster-Gateway für Traffic innerhalb von Clustern

  2. Die VirtualService-Komponente, die Traffic-Routingregeln festlegt, konfiguriert die Gateways so, dass der Nutzertraffic an die richtige Version weitergeleitet wird.

  3. Der Kubernetes-Service, eine Komponente der Steuerungsebene, bestimmt den nächsten Schritt im Anfragepfad abhängig von der Verfügbarkeit von Pods zur Verarbeitung des Traffics:

    • Wenn die Überarbeitung keine Pods enthält:

      1. Der Aktivator stellt die empfangene Anfrage vorübergehend in die Warteschlange und überträgt einen Messwert an Autoscaling, um weitere Pods zu skalieren.
      2. Autoscaling skaliert auf den gewünschten Zustand der Pods in der Bereitstellung.
      3. Bei der Bereitstellung werden weitere Pods erstellt, um zusätzliche Anfragen zu erhalten.
      4. Der Aktivator wiederholt Anfragen an den Sidecar-Warteschlangen-Proxy.

    • Wenn der Dienst horizontal skaliert wird (es sind Pods verfügbar), sendet der Kubernetes-Dienst die Anfrage an den Sidecar-Warteschlangen-Proxy.

  4. Der Sidecar-Warteschlangen-Proxy erzwingt Parameter für Anfragewarteschlangen, wie Einzel- oder Multithread-Anfragen, die der Container gleichzeitig verarbeiten kann.

  5. Wenn der Sidecar-Warteschlangen-Proxy mehr Anfragen enthält, als er verarbeiten kann, erstellt Autoscaling mehr Pods, um die zusätzlichen Anfragen zu verarbeiten.

  6. Der Sidecar-Warteschlangen-Proxy sendet Traffic an den Nutzercontainer.