Google Cloud bietet zwei Hauptplattformen zum Ausführen containerisierter Anwendungen: GKE zum Ausführen von Containern in Kubernetes-Clustern und Cloud Run zum Ausführen von Containern direkt auf der Google Cloud -Infrastruktur. Aber wann sollten Sie welche verwenden? Kann ich 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 infrage kommt.
Diese Seite richtet sich an Infrastrukturadministratoren und Anwendungsoperatoren, die verschiedene Containerarbeitslasten ausführen und die Stärken von Google Kubernetes Engine (GKE) und Cloud Run nutzen möchten, um Anwendungen auf derGoogle 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.
Im Folgenden sind einige Vorteile der Verwendung beider Laufzeiten für die Bereitstellung Ihrer Arbeitslasten aufgeführt:
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 und so 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 standardmäßigen Struktur dargestellt und können daher problemlos 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 -Konsole, um Anwendungsmesswerte unabhängig von ihrer Plattform zu beobachten. Sie können auch Service Level Objectives-Monitoring (SLO) 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 auch gleichzeitig in GKE und Cloud Run bereitstellen. Verwenden Sie dazu die parallele Bereitstellung.
Sie können erweiterte Traffic-Verwaltung ermöglichen, indem Sie externe und interne Load Balancer für Dienste in GKE und Cloud Run verwenden. 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 den Traffic für denselben Dienst auch 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 scannen, bevor Sie sie auf einer der beiden Plattformen bereitstellen. 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 Bereichskontrollen für Ihre GKE- und Cloud Run-Ressourcen definieren.
GKE und Cloud Run vergleichen
Damit Sie die besten Funktionen von GKE und Cloud Run nutzen und 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 | Verwalten Sie 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 und 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 von 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, Webservices und Funktionen. |
| Preismodell | Abrechnung pro Cluster pro Stunde, unabhängig von Betriebsmodus (Standard oder Autopilot), Clustergröße oder Topologie. | Die Abrechnung erfolgt nutzungsabhängig auf eine Zehntelsekunde genau. |
Anwendungsfall
Sie sind der Plattformadministrator eines Einzelhandelsunternehmens, das eine große E-Commerce-Plattform aufbaut. Sie haben die folgenden containerisierten Arbeitslasten, die Sie bereitstellen können:
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 zustandsbehafteten Diensten. Sie entscheiden sich daher, 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 nutzungsbasierten Modell Sie zahlen nur, wenn Nutzer Produkte ansehen oder kaufen 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 Batchverarbeitungsjobs 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 eignet sich am besten für ereignisgesteuerte Anwendungen. 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.
App Hub bietet eine einheitliche Ansicht der verschiedenen Komponenten, die mit einem hybriden Ansatz bereitgestellt werden, und zeigt, wie sie als zusammenhängende Anwendung zusammenarbeiten. Weitere Informationen finden Sie unter Unterstützte Ressourcen für App Hub.
Hinweise
GKE und Cloud Run ergänzen sich und decken unterschiedliche Anforderungen in einer komplexen Anwendungslandschaft ab.
Hier sind einige Überlegungen, die Sie bei der Einführung eines hybriden Ansatzes für die Bereitstellung von Arbeitslasten berücksichtigen sollten:
Führen Sie zustandslose Mikrodienste in Cloud Run aus, um Kosten zu senken und die Skalierbarkeit zu erhöhen.
Komplexe zustandsorientierte Anwendungen, die eine umfassende Anpassung erfordern, auf GKE bereitstellen.
Wenn Sie ein privates Netzwerk auf Google Cloudverwenden, können Sie über ausgehenden Direct VPC-Traffic eine Anfrage an ein VPC-Netzwerk (Virtual Private Cloud) senden, um von Ihrem Cloud Run-Dienst aus auf Ressourcen in Ihrem GKE-Cluster zuzugreifen. Damit auf Kubernetes-Dienste im GKE-Cluster zugegriffen werden kann, 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 IP-Adressen verfügbar machen möchten, verwenden Sie einen internen Load-Balancer.
Wenn Ihre Arbeitslasten bereits in Cloud Run ausgeführt werden, können Sie 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äten 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. Prüfen Sie sorgfältig die Anforderungen Ihrer Anwendung, die Ressourcenbeschränkungen und die Fachkenntnisse 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.