Architekturübersicht über die Bereitstellung mit Knative

Diese Seite bietet einen Überblick über die Architektur der Bereitstellung mit Knative und behandelt die Änderungen, die auftreten, wenn Sie die Bereitstellung von Knative in Ihrem Google Kubernetes Engine-Cluster aktivieren.

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

• Nutzer, die erste Schritte mit der Knative-Bereitstellung machen.
• 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 bereitstellende Anwendung zu konfigurieren.

Komponenten in der Standardinstallation

Installieren Sie Knative Serving in Ihrem Cluster, um Ihre zustandslosen Arbeitslasten zu verbinden und zu verwalten. Knative-Komponenten werden im Namespace knative-serving erstellt.

Knative-Bereitstellung verwendet Anthos Service Mesh, um Traffic weiterzuleiten. Standardmäßig installiert Anthos Service Mesh Komponenten im Namespace istio-system.

Hier finden Sie eine Liste der Komponenten, die von Knative-Bereitstellung und Anthos Service Mesh installiert wurden:

• Komponenten, die von Knative im Namespace knative-serving installiert werden:

  • Aktivator: 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 Nebenläufigkeit 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 den Knative-Bereitstellungskomponenten und leitet sie an Cloud Monitoring weiter.
  • Webhook: Legt Standardwerte fest, lehnt inkonsistente und ungültige Objekte ab und validiert und mutiert Kubernetes API-Aufrufe für Knative-Bereitstellungsressourcen. Der Webhook ist eine Komponente der Steuerungsebene.

• Komponenten, die von Anthos Service Mesh installiert wurden, das im Namespace istio-system ausgeführt wird:

  • Lokales Clustergateway: Load-Balancer in der Datenebene, der für die Verarbeitung des internen Traffics verantwortlich ist, der von einem Knative-Bereitstellungsdienst zu einem anderen eingeht. 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 Bereitstellungskomponenten von Knative werden bei allen Clusterupdates der GKE-Steuerungsebene automatisch aktualisiert. Weitere Informationen finden Sie unter Verfügbare GKE-Versionen.

Nutzung von Clusterressourcen

Die Erstinstallation von Knative erfordert in etwa 1,5 virtuelle CPU und 1 GB Arbeitsspeicher für den Cluster. Die Anzahl der Knoten in Ihrem Cluster hat keinen Einfluss auf die Speicherplatz- und Arbeitsspeicheranforderungen für eine Knative-Bereitstellungsinstallation.

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-Bereitstellungsdienst erstellte Pod erstellt einen Warteschlangen-Proxy-Sidecar, der Limits für die Nebenläufigkeit 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

Knative Serving-Dienstarchitektur (zum Vergrößern klicken)

Die Bereitstellung von Knative 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 Service ist die benutzerdefinierte Ressource der obersten Ebene, die durch die Bereitstellung durch Knative definiert wird. 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-Bereitstellungsdienst erstellt, geschieht Folgendes:

1. Das Knative-Bereitstellungsdienstobjekt definiert:

   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 bietet einen allgemeinen Überblick über einen möglichen Anfragepfad für Nutzertraffic über die Komponenten der Knative-Bereitstellungsdatenebene in einem Google Kubernetes Engine-Beispielcluster:

Architektur des Bereitstellungsclusters von Knative (zum Vergrößern klicken)

Das nächste Diagramm erweitert das obige Diagramm um einen detaillierten Einblick in den Anfragepfad des Nutzertraffics, der auch unten ausführlich beschrieben wird:

Anfragepfad für die Knative-Bereitstellung (zum Vergrößern klicken)

Für einen Anfragepfad für die Knative-Bereitstellung:

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.