Google Cloud bietet zwei Hauptplattformen für das Ausführen von Containeranwendungen: GKE für das Ausführen von Containern in Kubernetes-Clustern und Cloud Run für das Ausführen von Containern direkt auf der Google Cloud Infrastruktur. Aber wann sollten Sie die eine oder die andere verwenden? Und können Sie beide verwenden? Auf dieser Seite werden die beiden Plattformen und ihre Vorteile verglichen. Außerdem erfahren Sie, ob eine Einzelplattform- oder Hybridstrategie für Sie geeignet ist.
Dieses Dokument richtet sich an Infrastrukturadministratoren und Anwendungs betreiber, die verschiedene Containerarbeitslasten ausführen und die Stärken von Google Kubernetes Engine (GKE) und Cloud Run nutzen wollen, um Anwendungen auf der Google Cloud Plattform bereitzustellen.
Bevor Sie diese Seite lesen, sollten Sie mit Folgendem vertraut sein:
Zustandslose und zustandsorientierte Arbeitslasten
Warum GKE und Cloud Run zusammen verwenden?
GKE und Cloud Run bieten unterschiedliche Vorteile für das Ausführen von Containeranwendungen und decken verschiedene Arbeitslastkomplexitätsebenen ab. Sie müssen sich jedoch nicht zwischen den beiden Plattformen entscheiden. Sie können die Stärken von GKE und Cloud Run gleichzeitig nutzen, indem Sie Ihre Arbeitslasten nach Bedarf zwischen den beiden Plattformen migrieren. Mit einer solchen Hybridstrategie können Sie Kosten, Leistung und Verwaltungsaufwand optimieren.
Die Verwendung beider Laufzeiten zum Bereitstellen Ihrer Arbeitslasten bietet folgende Vorteile:
GKE und Cloud Run bieten eine relativ hohe Portabilität:
Beide Plattformen verwenden Standard-Container-Images als Bereitstellungsartefakte. Sie können dasselbe Image für Ihre Anwendung auf beiden Plattformen ohne Änderungen verwenden. So lassen sich Arbeitslasten nahtlos zwischen GKE und Cloud Run migrieren. Sie müssen Ihr Continuous Integration-Setup nicht updaten, um zwischen GKE und Cloud Run zu migrieren, solange Container-Images in Artifact Registry gespeichert sind.“
GKE und Cloud Run verwenden beide ein deklaratives API-Modell. Die Cloud Run Admin API Version 1 ist so konzipiert, dass sie mit der Kubernetes API kompatibel ist. Das bedeutet, dass Sie vertraute Kubernetes-Konzepte wie Deployments, Dienste und horizontale Pod-Autoscaler zum Verwalten Ihres Cloud Run-Dienstes verwenden können. Diese Ähnlichkeit erleichtert die Übertragung von Konfigurationen zwischen den beiden Plattformen.
Ressourcen werden in YAML-Dateien mit derselben deklarativen und Standardstruktur dargestellt und können daher einfach zwischen Laufzeiten migriert werden. Hier ein Beispiel mit einem Vergleich der YAML-Dateien eines Kubernetes-Deployments und eines Cloud Run-Dienstes.
Sowohl GKE als auch Cloud Run sind nahtlos in Cloud Logging und Cloud Monitoring eingebunden. Dadurch erhalten Sie eine zentrale Ansicht in der Google Cloud Console, um Anwendungsmesswerte unabhängig von ihrer Plattform zu beobachten. Sie können auch Service Level Objectives (SLO) Monitoring für und eine einheitliche Anzeige der SLOs auf dem Cloud Monitoring Dashboard verwenden.
Mit Cloud Deploy können Sie Continuous Delivery für GKE-Ressourcen oder Cloud Run-Dienste implementieren. Alternativ können Sie Ihre Anwendung mit der parallelen Bereitstellung gleichzeitig in GKE und Cloud Run bereitstellen.
Sie können die erweiterte Traffic Verwaltung mithilfe von externen und internen Load-Balancern für Dienste in GKE und Cloud Run erleichtern. Dazu gehört die Möglichkeit, externe Endpunkte verfügbar zu machen, sodass Sie auf unterschiedlichen Websites verschiedene URLs für dieselbe Anwendung auf beiden Plattformen bereitstellen und ausführen können. Sie können auch Traffic für denselben Dienst zwischen GKE und Cloud Run aufteilen, um eine nahtlose Migration von einer Plattform zur anderen zu ermöglichen.
Google Cloud bietet Sicherheitstools, mit denen Sie Ihren Sicherheitsstatus verbessern können, wenn Sie beide Laufzeiten verwenden. Mit dem Betriebssystemscan können Sie Container auf Sicherheitslücken überprüfen, bevor sie auf einer der beiden Plattformen bereitgestellt werden. Eine zentrale Richtlinie zur Binärautorisierung kann die Integration mit der GKE- und Cloud Run-Steuerungsebene erzwingen, um die Image-Bereitstellung basierend auf den von Ihnen definierten Richtlinien zu erlauben oder zu blockieren. Mit VPC Service Controls können Sicherheitsteams detaillierte Perimeterkontrollen für Ihre GKE- und Cloud Run-Ressourcen definieren.
GKE und Cloud Run im Vergleich
Um die besten Funktionen von GKE und Cloud Run zu nutzen und zu wissen, wann Sie Arbeitslasten zwischen den beiden Diensten verschieben sollten, ist es wichtig, die Unterschiede zwischen den beiden Diensten zu kennen.
| Funktion | GKE | Cloud Run |
|---|---|---|
| Bereitstellung und Verwaltung | Sie verwalten die Kubernetes-Cluster, einschließlich Knotenkonfiguration, Netzwerk, Skalierung und Upgrades. Google Cloud verwaltet die zugrunde liegende Infrastruktur und bietet Tools zur Vereinfachung des Clusterbetriebs. Sie sind jedoch weiterhin für die wichtigsten Kubernetes-Aspekte verantwortlich. |
Container direkt auf der skalierbaren Infrastruktur von Google Cloudausführen. Sie müssen nur Quellcode oder ein Container-Image bereitstellen. Cloud Run kann den Container für Sie erstellen. Sie müssen keinen Cluster erstellen oder die Infrastruktur bereitstellen und verwalten. |
| Kontrolle und Flexibilität | Vollständige Kontrolle über den Kubernetes-Cluster. Sie können erweiterte Anpassungen der Knotenkonfigurationen, Netzwerkrichtlinien, Sicherheitseinstellungen und Add-ons vornehmen. |
Begrenzte Kontrolle über die zugrunde liegende Infrastruktur. Sie können beispielsweise Umgebungsvariablen, Parallelität und Netzwerkverbindungen konfigurieren, aber die zugrunde liegende Infrastruktur oder Umgebung nicht anpassen. Ideal für Einfachheit und Geschwindigkeit. |
| Anwendungstypen | Unterstützt sowohl zustandslose als auch zustandsorientierte Anwendungen und ist ideal für komplexe Anwendungen mit spezifischen Ressourcenanforderungen. | Am besten geeignet für zustandslose, anfrage- oder ereignisgesteuerte Dienste, Webdienste und Funktionen. |
| Preismodell | Abrechnung pro Cluster pro Stunde, unabhängig von Betriebsmodus (Standard oder Autopilot), Clustergröße oder Topologie. | Nutzungsabhängige Abrechnung, auf die nächste Zehntelsekunde aufgerundet. |
Anwendungsfall
Sie sind der Plattformadministrator eines Einzelhandelsunternehmens, das eine große E-Commerce-Plattform aufbaut. Sie müssen die folgenden containerisierten Arbeitslasten bereitstellen:
Frontend-Website und mobile App: Eine zustandslose Webanwendung für das Durchsuchen von Produkten, die Suche und den Checkout.
Produktinventarverwaltung: Ein zustandsorientierter Dienst, der Produktverfügbarkeit und Updates verwaltet.
Empfehlungssystem: Ein komplexer Mikrodienst, der personalisierte Angebote Produktempfehlungen für jede nutzende Person generiert.
Batchverarbeitungsjobs: Beinhaltet regelmäßige Aufgaben wie die Aktualisierung von Produktkatalogen und das Analysieren des Nutzerverhaltens.
Diese Arbeitslasten bestehen aus einer Mischung aus zustandslosen und zustandsorientierten Diensten. Daher entscheiden Sie sich, sowohl GKE als auch Cloud Run zu nutzen, um eine optimale Leistung zu erzielen. Hier ist eine Möglichkeit, einen hybriden Ansatz für Ihre Arbeitslasten zu implementieren.
Nachdem Sie die Kriterien für die Eignung von Cloud Run-Arbeitslasten gelesen haben, entscheiden Sie sich für Cloud Run für die Website und die mobile App sowie für die Batchverarbeitungsjobs. Die Bereitstellung dieser Dienste in Cloud Run bietet folgende Vorteile:
Die automatische Skalierung bei Traffic-Spitzen und großen Batchjobs wird ohne manuelle Eingriffe ausgeführt.
Kosteneffizienz mit einem nutzungsabhängigen Abrechnungsmodell. Sie zahlen nur, wenn Nutzer Produkte durchsuchen oder zur Kasse gehen und wenn Ressourcen während der Ausführung von Batchjobs verwendet werden.
Schnellere Bereitstellung, da Updates sofort verfügbar sind, was die Nutzerfreundlichkeit verbessert.
Einfache Einbindung in andere Google Cloud Dienste. Beispiel: Für ereignisgesteuerte Verarbeitung können Sie Cloud Run-Funktionen zum Initiieren von Batch verarbeitungsjobs in Cloud Run und nahtlose Workflows verwenden.
Die Produktinventarverwaltung ist ein zustandsorientierter Dienst, der differenzierte und möglicherweise benutzerdefinierte Speicherlösungen erfordert. Sie entscheiden sich für GKE zum Bereitstellen dieses Dienstes, da er nichtflüchtigen Speicher bietet. Außerdem können Sie Volumes anhängen, um Produktdaten dauerhaft und zuverlässig zu halten.
Das Empfehlungssystem ist ein komplexer Mikrodienst, der von GKE profitiert. Mit GKE können Sie komplexe Abhängigkeiten sowie eine fein abgestimmte Kontrolle über die Ressourcenzuweisung und Skalierung ausführen.
GKE eignet sich am besten für komplexe Mikrodienstarchitekturen, zustandsorientierte Anwendungen, Arbeitslasten, die eine benutzerdefinierte Infrastruktur oder eine Netzwerkkonfiguration erfordern Konfigurationen und Szenarien, in denen eine umfassende Kontrolle über Kubernetes von entscheidender Bedeutung ist. Cloud Run ist am besten für ereignisgesteuerte Apps geeignet. Sie eignet sich ideal für zustandslose Webdienste, APIs, Batchjobs und andere Arbeitslasten, die von nutzungsabhängiger Abrechnung profitieren.
Das obige Beispiel zeigt, wie die Kombination von GKE und Cloud Run eine leistungsstarke und flexible Lösung für Ihre E-Commerce-Plattform sein kann. Sie erhalten die Vorteile beider Plattformen. Serverlose Effizienz für zustandslose Arbeitslasten und Kubernetes-Steuerung für komplexe Mikrodienste und zustandsorientierte Komponenten.
Eine ganzheitliche Übersicht der verschiedenen Komponenten, die mit einem hybriden Ansatz bereitgestellt werden, und Informationen dazu, wie sie als zusammenhängende Anwendung funktionieren, finden Sie in App Hub. Weitere Informationen finden Sie unter Unterstützte Ressourcen für App Hub.
Hinweise
GKE und Cloud Run ergänzen sich und erfüllen unterschiedliche Anforderungen in einer komplexen Anwendungslandschaft.
Bei der Einführung eines hybriden Ansatzes für die Bereitstellung von Arbeitslasten sollten Sie Folgendes beachten:
Führen Sie zustandslose Mikrodienste in Cloud Run aus, um Kosten zu senken und die Skalierbarkeit zu erhöhen.
Stellen Sie komplexe zustandsorientierte Anwendungen, die eine umfassende Anpassung erfordern, in GKE bereit.
Wenn Sie ein privates Netzwerk in Google Cloudverwenden, um von Ihrem Cloud Run-Dienst aus auf Ressourcen in Ihrem GKE-Cluster zuzugreifen, können Sie mit Direct VPC-Ausgang eine Anfrage an ein Virtual Private Cloud (VPC)-Netzwerk senden. Um auf Kubernetes-Dienste im GKE Cluster zuzugreifen, muss der Cloud Run-Dienst mit dem VPC-Netzwerk des Clusters verbunden sein und der Kubernetes-Dienst muss einen internen Passthrough-Network-Load-Balancer verwenden.
Um Traffic zwischen Cloud Run und GKE zu migrieren, können Sie externe Endpunkte hinter einem Globalen externen Application Load Balancer preisgeben. Wenn Sie diesen Load-Balancer in beiden Laufzeiten vor Diensten implementieren, können Sie dieselbe Anwendung sowohl in Cloud Run als auch in GKE bereitstellen, sodass Sie den Traffic schrittweise von einer Plattform zur anderen verlagern können.
Wenn Sie Cloud Run-Dienste in Virtual Private Cloud hinter privaten IPs bereitstellen möchten, verwenden Sie einen internen Load-Balancer.
Wenn sich Ihre Arbeitslasten bereits in Cloud Run befinden, können Sie bei Bedarf jederzeit zu GKE migrieren.
Wann GKE und Cloud Run nicht zusammen verwendet werden sollten
GKE und Cloud Run bieten einen überzeugenden Ansatz für viele containerisierte Arbeitslasten. Es gibt Situationen, in denen die gemeinsame Verwendung nicht die beste Lösung ist. Hier sind einige Beispiele, in denen Sie sich entscheiden sollten, keinen hybriden Ansatz zu verfolgen:
Eng gekoppelte Mikrodienste: Wenn Ihre Mikrodienste stark voneinander abhängig sind und eine häufige Kommunikation mit geringer Latenz erfordern, kann die Verwaltung auf separaten Plattformen zu Komplexität führen. Häufige Netzwerkanrufe zwischen Plattformen kann zu Mehraufwand und zu möglichen Engpässen führen, was sich auf die Leistung auswirkt.
Legacy-Anwendungen mit benutzerdefinierten Abhängigkeiten: Wenn Ihre Anwendung bestimmte Bibliotheken, Frameworks oder Konfigurationen benötigt, die nicht von Cloud Run unterstützt werden, kann die Nutzung für Teile der Anwendung erhebliche Refaktorierung oder Problemumgehungen erforderlich machen. Dies kann das serverlose Vorteile negieren und plattformspezifischer Wartungsaufwand verursachen.
Budgetbeschränkungen bei vorhersehbaren Arbeitslasten: Wenn Ihre Arbeitslast konsistente Ressourcenanforderungen hat und Sie ein enges Budget haben, ist das knotenbasierte Abrechnungsmodell von GKE möglicherweise kostengünstiger als die nutzungsabhängige Abrechnung von Cloud Run. Wenn Sie vorhersehbare Arbeitslasten haben, nutzen Sie die Vorteile der automatischen Skalierung von Cloud Run, wodurch die Festpreise von GKE attraktiver werden.
Der beste Ansatz hängt letztendlich von Ihren spezifischen Anforderungen und Prioritäten ab. Bewerten Sie sorgfältig die Anforderungen Ihrer Anwendung, die Ressourcenbeschränkungen und das Fachwissen Ihres Teams, bevor Sie sich für eine hybride GKE- und Cloud Run-Architektur entscheiden.
Nächste Schritte
Unter Migration von Cloud Run zu GKE erfahren Sie, wie Sie Ihren Cloud Run-Dienst in einen Kubernetes-Dienst konvertieren.
Verpacken Sie Ihr Kubernetes-Deployment in einen mit Cloud Run kompatiblen Container, indem Sie Migration von Kubernetes zu Cloud Run befolgen.