Dieses Dokument richtet sich an Infrastrukturadministratoren und Anwendungsoperatoren, die verschiedene Containerarbeitslasten ausführen und die Stärken von Google Kubernetes Engine (GKE) sowie Cloud Run nutzen wollen, um Anwendungen auf der Google Cloud Platform bereitzustellen. Mit einer Hybridstrategie können Sie Kosten, Leistung und Verwaltungsaufwand optimieren.
Bevor Sie dieses Dokument lesen, sollten Sie mit Folgendem vertraut sein:
Zustandslose und zustandsorientierte Arbeitslasten
Vorteile der gemeinsamen Verwendung von GKE und Cloud Run
GKE und Cloud Run bieten unterschiedliche Vorteile für das Ausführen von Containeranwendungen und decken verschiedene Arbeitslastkomplexitätsebenen ab. Sie müssen jedoch nicht zwischen den beiden Plattformen wählen. Sie können die Stärken von GKE und Cloud Run gleichzeitig nutzen, indem Sie Ihre Arbeitslasten je nach Bedarf zwischen den beiden Plattformen migrieren.
Die Verwendung beider Laufzeiten zum Bereitstellen von Arbeitslasten bietet unter anderem 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 auf beiden Plattformen ohne Änderungen für Ihre Anwendung verwenden, was eine nahtlose Migration von Arbeitslasten zwischen GKE und Cloud Run ermöglicht. 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 Übersetzung von Konfigurationen zwischen den beiden Plattformen.
Ressourcen werden in YAML-Dateien mit derselben deklarativen und Standardstruktur dargestellt und können daher leicht 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-Monitoring (SLO) für und eine einheitliche Anzeige der SLOs auf dem Cloud Monitoring Dashboard verwenden.
Sie können Continuous Delivery mithilfe von Cloud Deploy entweder für GKE-Ressourcen oder in Cloud Run-Dienste implementieren. Sie können Ihre Anwendung auch gleichzeitig in GKE und Cloud Run mit der parallelen Bereitstellung bereitstellen.
Sie können die erweiterte Trafficverwaltung mithilfe externer und interner Load-Balancer für Dienste in GKE und Cloud Run vereinfachen. 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. Außerdem können Sie den Traffic auf denselben Dienst in GKE und Cloud Run aufteilen, um eine nahtlose Migration von einer Plattform zu einer anderen zu ermöglichen.
Google Cloud bietet Sicherheitstools, mit denen Sie Ihren Sicherheitsstatus verbessern können, wenn Sie beide Laufzeiten verwenden. Betriebssystemscan ermöglicht es Ihnen, Container auf Sicherheitslücken zu ü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 Bereichskontrollen für Ihre GKE- und Cloud Run-Ressourcen definieren.
GKE und Cloud Run im Vergleich
Damit Sie die Features von GKE und Cloud Run nutzen können und wissen, wann Arbeitslasten zwischen ihnen verschoben werden sollen, müssen Sie wissen, wie sich die beiden Dienste voneinander unterscheiden.
| Funktion | GKE | Cloud Run |
|---|---|---|
| Bereitstellung und Verwaltung | Verwaltung von Kubernetes-Clustern, einschließlich Knotenkonfiguration, Netzwerk, Skalierung und Upgrades. Google Cloud verwaltet die zugrunde liegende Infrastruktur und bietet Tools zur Vereinfachung von Clustervorgängen. Sie sind jedoch weiterhin für die zentralen Kubernetes-Aspekte verantwortlich. |
Container direkt auf der skalierbaren Infrastruktur von Google Cloud ausführen. Sie müssen lediglich Quellcode oder ein Container-Image bereitstellen. Cloud Run kann den Container dann für Sie erstellen. Sie müssen keinen Cluster erstellen oder 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. |
Eingeschränkte Kontrolle über die zugrunde liegende Infrastruktur. Sie können beispielsweise Umgebungsvariablen, Nebenläufigkeit und Netzwerkverbindungen konfigurieren, die zugrunde liegende Infrastruktur oder Umgebung jedoch 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 bestimmten Ressourcenanforderungen. | Optimal für zustandslose, anfragen- 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, aufgerundet auf eine Zehntelsekunde genau. |
Anwendungsfall
Sie sind der Plattformadministrator eines Einzelhandelsunternehmens, das eine große E-Commerce-Plattform aufbaut. Sie müssen die folgenden Containerarbeitslasten bereitstellen:
Frontend-Website und mobile App: Eine zustandslose Webanwendung, die das Surfen, die Suche und die Kasse verarbeitet.
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 stellen eine Mischung aus zustandslosen und zustandsorientierten Diensten dar. Daher sollten Sie sowohl GKE als auch Cloud Run 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 ausführen, entscheiden Sie sich für die Verwendung von Cloud Run der Website und der mobilen App sowie 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 surfen oder bezahlen, und wenn Ressourcen während der Batch-Jobausführung 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 Batchverarbektungsjobs 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.
Hinweise
GKE und Cloud Run ergänzen sich gegenseitig und erfüllen unterschiedliche Anforderungen in einer komplexen Anwendungslandschaft.
Im Folgenden sind einige Überlegungen für die Anwendung eines hybriden Ansatzes zur Bereitstellung von Arbeitslasten aufgeführt:
Zustandslose Mikrodienste in Cloud Run ausführen, um Kosteneffizienz und Skalierbarkeit zu erzielen
Komplexe zustandsorientierte Anwendungen bereitstellen, die eine tiefe Anpassung in GKE erfordern.
Wenn Sie ein privates Netzwerk in Google Cloud verwenden, können Sie für den Zugriff auf Ressourcen in Ihrem GKE-Cluster von Ihrem Cloud Run-Dienst eine Anfrage an ein Virtual Private Cloud (VPC)-Netzwerk senden. mit ausgehendem Direct VPC-Traffic. Für den Zugriff auf Kubernetes-Dienste im GKE-Cluster 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.
Verwenden Sie einen internen Load-Balancer, um Cloud Run-Dienste in Virtual Private Cloud hinter privaten IP-Adressen verfügbar zu machen.
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 niedriger Latenz erfordern, kann die Verwaltung über separate Plattformen hinweg Komplexität verursachen. 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, Ressourceneinschrä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.