Architekturübersicht über Cloud Run for Anthos

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

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

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

Komponenten in der Standardinstallation

Wenn Sie Cloud Run for Anthos als Add-on für Ihren Google Kubernetes Engine-Cluster installieren, werden die Namespaces knative-serving und gke-system automatisch erstellt. Die folgenden Komponenten werden in einem dieser Namespaces bereitgestellt:

• Komponenten, die im Namespace knative-serving ausgeführt 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 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.
  • Webhook: Legt Standardwerte fest, lehnt inkonsistente und ungültige Objekte ab und validiert und mutiert Kubernetes API-Aufrufe für Cloud Run for Anthos-Ressourcen. Der Webhook ist eine Komponente der Steuerungsebene.

• Komponenten, die im Namespace gke-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 Cloud Run for Anthos-Gerät an ein anderes 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.
  • Istio-Pilot: Konfiguriert das lokale Clustergateway und das Istio-Ingress-Gateway für die Verarbeitung von HTTP-Anfragen an den richtigen Endpunkten. Der Istio-Pilot ist eine Komponente der Steuerungsebene. Weitere Informationen finden Sie unter Istio-Pilot.

Die Komponenten von Cloud Run for Anthos werden automatisch mit allen Clusteraktualisierungen der GKE-Steuerungsebene aktualisiert. Weitere Informationen finden Sie unter Verfügbare GKE-Versionen.

Nutzung von Clusterressourcen

Die Erstinstallation von Cloud Run for Anthos 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 Speicherplatz und die Arbeitsspeicheranforderungen für eine Cloud Run for Anthos-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 Cloud Run for Anthos-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

Cloud Run for Anthos-Dienstarchitektur (zum Vergrößern klicken)

Cloud Run for Anthos erweitert Kubernetes durch die Festlegung einer Reihe von benutzerdefinierten Ressourcendefinitionen (CRDs): Dienst, Überarbeitung, Konfiguration und Route. Diese CRDs definieren und steuern das Verhalten der Anwendungen auf dem Cluster:

• Der Cloud Run for Anthos-Dienst ist die von Cloud Run for Anthos 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 Cloud Run for Anthos-Dienst erstellt, geschieht Folgendes:

1. Das Cloud Run for Anthos-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 Cloud Run for Anthos auf einem Google Kubernetes Engine-Beispielcluster:

Cloud Run for Anthos-Clusterarchitektur (zum Vergrößern klicken)

Das nächste Diagramm erweitert das Diagramm oben, um einen detaillierten Einblick in den Anfragepfad des Nutzer-Traffics zu bieten, der im Folgenden genauer beschrieben wird:

Cloud Run for Anthos-Anfragepfad (zum Vergrößern klicken)

Für einen Cloud Run for Anthos-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.