Architekturübersicht über Knative serving

Diese Seite bietet einen Überblick über die Architektur von Knative serving und beschreibt die Änderungen, die auftreten, wenn Sie Knative serving in Ihrem Google Kubernetes Engine-Cluster.

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, Knative serving lässt sich in Kubernetes-Cluster einbinden Anwendungen zu verbessern oder Knative serving zu konfigurieren, .

Komponenten in der Standardinstallation

Installieren Sie Knative serving in um zustandslose Arbeitslasten zu verbinden und zu verwalten. Knative Komponenten werden im Namespace knative-serving erstellt.

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

Hier ist eine Liste der von Knative serving und Cloud Service Mesh installierten Komponenten:

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

  • Activator: Wenn Pods auf null herunterskaliert oder durch Anfragen überlastet werden, die an den überarbeitet, stellt der Aktivator die Anfragen vorübergehend in die Warteschlange und sendet Messwerte an Autoscaling zum Hochfahren weiterer Pods 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 an Cloud Monitoring weiter.
  • Webhook: Legt Standardwerte fest und lehnt inkonsistente und ungültige Werte ab und validiert, und mutate-Vorgänge 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 Cluster-Gateway: Load-Balancer in der Datenebene, der für den internen Traffic, der von einer Knative serving-Dienst zu einem anderen. 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.

Knative serving-Komponenten werden automatisch Clusterupdates der GKE-Steuerungsebene. Weitere Informationen finden Sie unter Verfügbare GKE-Versionen.

Nutzung von Clusterressourcen

Die Erstinstallation von Knative serving erfordert etwa 1,5 virtuelle CPU und 1 GB Arbeitsspeicher für Ihren Cluster. Die Anzahl der Knoten in Ihrem keinen Einfluss auf die Speicherplatz- und Arbeitsspeicheranforderungen eines 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.

Für jeden vom Knative serving-Dienst erstellten Pod wird ein Sidecar-Warteschlangen-Proxy, 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

<ph type="x-smartling-placeholder">

</ph>

Architektur von Knative serving Service (zum Vergrößern klicken)

Knative serving ist eine Erweiterung von 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:

• Knative serving Service ist die benutzerdefinierte Ressource der obersten Ebene. definiert durch Knative serving. 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: Folgendes passieren:

1. Das Objekt „Knative serving Service“ 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 grobe Übersicht über einen möglichen Anfragepfad für über die Komponenten der Datenebene von Knative serving auf einer Google Kubernetes Engine-Beispielcluster:

<ph type="x-smartling-placeholder">

</ph>

Knative serving-Clusterarchitektur (zum Vergrößern klicken)

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:

<ph type="x-smartling-placeholder">

</ph>

Anfragepfad von Knative serving (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.