Verwaltete Containerlaufzeitumgebung auswählen

Last reviewed 2024-08-30 UTC

In diesem Dokument erfahren Sie, wie Sie Ihre Anwendungsanforderungen bewerten und anhand technischer und organisatorischer Überlegungen zwischen Cloud Run und Google Kubernetes Engine (GKE) Autopilot wählen. Dieses Dokument richtet sich an Cloud Architects, die eine Ziel-Containerlaufzeitumgebung in Google Cloud für ihre Arbeitslasten auswählen müssen. Es wird davon ausgegangen, dass Sie mit Kubernetes und Google Cloudvertraut sind und einige Kenntnisse über serverlose Cloud-Laufzeitumgebungen wie Cloud Run, Cloud Run-Funktionen oder AWS Lambda haben.

Google Cloud bietet mehrere Optionen für Laufzeitumgebungen mit einer Vielzahl von Funktionen. Das folgende Diagramm zeigt die Palette der verwalteten Google Cloud-Angebote:

Google Cloud- Angebote von der umfassendsten Verwaltung zur geringsten Verwaltung.

Das Diagramm zeigt Folgendes:

  • Laufzeitumgebungen mit umfassendster Verwaltung (Schwerpunkt dieses Leitfadens):

    Diese Optionen werden von Google verwaltet. Die zugrunde liegende Recheninfrastruktur wird nicht vom Nutzer verwaltet.

  • Laufzeitumgebungen mit geringster Verwaltung:

    • GKE Standard, das für Unternehmensarbeitslasten optimiert ist und eine Single-Cluster-Skalierbarkeit von bis zu 65.000 Knoten bietet.
    • Compute Engine, einschließlich der beschleunigungsoptimierten A3-Familie virtueller Maschinen für Arbeitslasten aus den Bereichen maschinelles Lernen (ML) und Hochleistungs-Computing (HPC).

    Für diese Optionen ist eine gewisse Infrastrukturverwaltung auf Nutzerebene erforderlich, z. B. für die virtuellen Maschinen (VMs), die den Computing-Funktionen zugrunde liegen. VMs in GKE Standard sind die Kubernetes-Clusterknoten. VMs in Compute Engine sind das Kernplattformangebot, das Sie an Ihre Anforderungen anpassen können.

In diesem Leitfaden erfahren Sie, wie Sie zwischen den Laufzeitumgebungen mit der umfassendsten Verwaltung wählen: Cloud Run und GKE Autopilot. Eine umfassendere Übersicht über die Laufzeitumgebungen von Google Cloud finden Sie im Leitfaden Google Cloud -Optionen für das Anwendungshosting.

Übersicht über Umgebungen

In diesem Abschnitt erhalten Sie einen Überblick über die Funktionen von Cloud Run und GKE Autopilot. Cloud Run und GKE Autopilot sind beide eng in Google Cloudeingebunden. Daher haben sie viele Gemeinsamkeiten. Beide Plattformen unterstützen mehrere Optionen für das Load Balancing mit den hochzuverlässigen und skalierbaren Load Balancing-Diensten von Google. Außerdem unterstützen beide VPC-Netzwerke, Identity-Aware Proxy (IAP) und Google Cloud Armor, wenn ein detaillierteres privates Netzwerk erforderlich ist. Bei beiden Plattformen werden Ihnen nur die Ressourcen in Rechnung gestellt, die Sie für Ihre Anwendungen tatsächlich nutzen.

Aus Sicht der Softwarebereitstellung werden Cloud Run und GKE Autopilot als Containerlaufzeitumgebungen von Diensten unterstützt, die das Google Cloud -Container-Ökosystem bilden. Dazu gehören Cloud Build, Artifact Registry, Binärautorisierung und Continuous Delivery mit Cloud Deploy. Mit diesen Diensten werden Ihre Anwendungen sicher und zuverlässig in der Produktion bereitgestellt. Das bedeutet, dass Sie und Ihre Teams die Entscheidungen bezüglich Build und Bereitstellung treffen.

Aufgrund der Gemeinsamkeiten zwischen den beiden Plattformen sollten Sie die Stärken der einzelnen Plattformen nutzen, indem Sie einen flexiblen Ansatz für die Bereitstellung Ihrer Anwendungen wählen, wie im Leitfaden GKE und Cloud Run zusammen verwenden beschrieben. In den folgenden Abschnitten werden die Besonderheiten von Cloud Run und Autopilot beschrieben.

Cloud Run

Cloud Run ist eine serverlose, verwaltete Computing-Plattform, mit der Sie Ihre Anwendungen direkt auf der skalierbaren Infrastruktur von Google ausführen können. Cloud Run bietet Automatisierung und Skalierung für zwei Hauptarten von Anwendungen:

  • Cloud Run-Dienste: Für Code, der auf Webanfragen reagiert.
  • Cloud Run-Jobs: Für Code, der eine oder mehrere Hintergrundaufgaben ausführt und dann beendet wird, wenn die Arbeit erledigt ist.

Mit diesen beiden Bereitstellungsmodellen kann Cloud Run eine breite Palette von Anwendungsarchitekturen unterstützen, Best Practices ermöglichen und Entwicklern die Möglichkeit geben, sich auf den Code zu konzentrieren.

Cloud Run unterstützt auch das Bereitstellen von Anwendungscode aus den folgenden Quellen:

  • Einzelne einfache Funktionen
  • Vollständige Anwendungen aus Quellcode
  • Containerisierte Anwendungen

Cloud Run bietet eine Build- und Bereitstellungsfunktion, die neben der vorkonfigurierten Containerlaufzeit sowohl FaaS als auch die Möglichkeit zum Erstellen aus der Quelle unterstützt. Wenn Sie Cloud Run auf diese Weise verwenden, werden die Schritte zum Erstellen und Bereitstellen des ausgeführten Anwendungscontainer-Images vollständig automatisch durchgeführt und erfordern keine benutzerdefinierte Konfiguration.

GKE Autopilot

GKE Autopilot ist der standardmäßige und empfohlene Clusterbetriebsmodus in GKE. Mit Autopilot können Sie Anwendungen in Kubernetes ausführen, ohne sich um die Verwaltung der Infrastruktur kümmern zu müssen. Wenn Sie Autopilot verwenden, verwaltet Google wichtige zugrunde liegende Aspekte Ihrer Clusterkonfiguration, einschließlich Knotenbereitstellung und ‑skalierung, Standardsicherheitsstatus und anderer vorkonfigurierter Einstellungen. Da Autopilot die Knotenressourcen verwaltet, zahlen Sie nur für die Ressourcen, die von Ihren Arbeitslasten angefordert werden. Autopilot überwacht und optimiert kontinuierlich die Infrastrukturressourcen, um die bestmögliche Eignung zu gewährleisten und gleichzeitig ein SLA für Ihre Arbeitslasten bereitzustellen.

GKE Autopilot unterstützt Arbeitslasten, die für Cloud Run möglicherweise nicht geeignet sind. GKE Autopilot unterstützt beispielsweise häufig langlebige oder zustandsorientierte Arbeitslasten.

Laufzeitumgebung auswählen

Wenn die Merkmale Ihrer Arbeitslast für eine verwaltete Plattform geeignet sind, ist die serverlose Laufzeitumgebung von Cloud Run in der Regel die beste Wahl. Die Verwendung von Cloud Run kann zu weniger zu verwaltender Infrastruktur, weniger selbst verwalteter Konfiguration und damit zu einem geringeren Betriebsaufwand führen. Sofern Sie Kubernetes nicht ausdrücklich wünschen oder benötigen, empfehlen wir, zuerst die serverlose Option als Ziellaufzeitumgebung zu verwenden. Kubernetes bietet zwar die leistungsstarke Abstraktion einer offenen Plattform, die Verwendung von Kubernetes ist aber komplexer. Wenn Sie Kubernetes nicht benötigen, sollten Sie überlegen, ob Ihre Anwendung für serverlose Lösungen geeignet ist. Wenn es Kriterien gibt, die Ihre Arbeitslast für serverlose Lösungen weniger geeignet machen, empfehlen wir die Verwendung von Autopilot.

In den folgenden Abschnitten finden Sie weitere Informationen zu einigen der Kriterien, die Ihnen bei der Beantwortung dieser Fragen helfen können, insbesondere bei der Frage, ob die Arbeitslast für serverlose Lösungen geeignet ist. Angesichts der Gemeinsamkeiten zwischen Autopilot und Cloud Run, die in den vorherigen Abschnitten beschrieben wurden, ist die Migration zwischen den Plattformen eine einfache Aufgabe, wenn keine technischen oder anderen Hindernisse vorliegen. Weitere Informationen zu den Migrationsoptionen finden Sie unter Von Cloud Run zu GKE migrieren und Von Kubernetes zu Cloud Run migrieren.

Bei der Auswahl einer Laufzeitumgebung für Ihre Arbeitslast müssen Sie technische und organisatorische Aspekte berücksichtigen. Technische Aspekte sind Merkmale Ihrer Anwendung oder der Google Cloud-Laufzeitumgebung. Organisatorische Aspekte sind nicht technische Merkmale Ihrer Organisation oder Ihres Teams, die Ihre Entscheidung beeinflussen können.

Technische Aspekte

Einige der technischen Aspekte, die Ihre Auswahl der Plattform beeinflussen, sind:

  • Steuerung und Konfigurierbarkeit: Detaillierte Steuerung der Ausführungsumgebung.
  • Netzwerkverkehr – Verwaltung und Routing: Konfigurierbarkeit von Interaktionen über das Netzwerk.
  • Horizontale und vertikale Skalierbarkeit: Unterstützung für die dynamische Erhöhung und Verringerung der Kapazität.
  • Unterstützung für zustandsorientierte Anwendungen: Funktionen zum Speichern eines nichtflüchtigen Zustands.
  • CPU-Architektur: Unterstützung verschiedener CPU-Typen.
  • Accelerator-Auslagerung (GPUs und TPUs): Möglichkeit, Berechnungen auf dedizierte Hardware auszulagern.
  • Hohe Kapazität bei Arbeitsspeicher, CPU und anderen Ressourcen: Der Grad der Nutzung verschiedener Ressourcen.
  • Explizite Abhängigkeit von Kubernetes: Anforderungen an die Verwendung der Kubernetes API.
  • Komplexe RBAC für die Mehrmandantenfähigkeit: Unterstützung für die Freigabe von gemeinsamen Ressourcen.
  • Maximale Zeitüberschreitung für Containeraufgaben: Ausführungsdauer langlebiger Anwendungen oder Komponenten.

In den folgenden Abschnitten werden diese technischen Überlegungen beschrieben, damit Sie eine geeignete Laufzeitumgebung auswählen können.

Steuerung und Konfigurierbarkeit

Im Vergleich zu Cloud Run bietet GKE Autopilot eine detailliertere Steuerung der Ausführungsumgebung für Ihre Arbeitslasten. Im Kontext eines Pods bietet Kubernetes viele konfigurierbare Primitive, die Sie an Ihre Anwendungsanforderungen anpassen können. Zu den Konfigurationsoptionen gehören die Berechtigungsebene, Dienstqualitätparameter, benutzerdefinierte Handler für Containerlebenszyklusereignisse und die Freigabe des Prozess-Namespace zwischen mehreren Containern.

Cloud Run unterstützt direkt einen Teil der Kubernetes Pod API, die in der YAML-Referenz für das Cloud Run-Dienstobjekt und in der YAML-Referenz für das Cloud Run-Jobobjekt beschrieben ist. Diese Referenzhandbücher können Ihnen helfen, die beiden Plattformen im Hinblick auf Ihre Anwendungsanforderungen zu bewerten.

Der Containervertrag für die Cloud Run-Ausführungsumgebung ist relativ einfach und eignet sich für die meisten Bereitstellungslasten. Der Vertrag enthält jedoch einige Anforderungen, die erfüllt werden müssen. Wenn Ihre Anwendung oder deren Abhängigkeiten diese Anforderungen nicht erfüllen oder Sie eine genauere Kontrolle über die Ausführungsumgebung benötigen, ist Autopilot möglicherweise besser geeignet.

Wenn Sie den Zeitaufwand für Konfiguration und Verwaltung reduzieren möchten, sollten Sie Cloud Run als Laufzeitumgebung auswählen. Cloud Run bietet weniger Konfigurationsoptionen als Autopilot. So können Sie die Entwicklerproduktivität maximieren und den Betriebsaufwand reduzieren.

Netzwerkverkehr verwalten und routen

Sowohl Cloud Run als auch GKE Autopilot können in Google Cloud Load Balancing eingebunden werden. GKE Autopilot bietet jedoch zusätzlich eine umfangreiche und leistungsstarke Reihe von Primitiven zur Konfiguration der Netzwerkumgebung für die Dienst-zu-Dienst-Kommunikation. Die Konfigurationsoptionen umfassen detaillierte Berechtigungen und Trennung auf Netzwerkebene mithilfe von Namespaces und Netzwerkrichtlinien, Port-Neuzuordnung und integrierter DNS-Service-Discovery innerhalb des Clusters. GKE Autopilot unterstützt auch die hochgradig konfigurierbare und flexible Gateway API. Mit dieser Funktion können Sie die Weiterleitung von Traffic in Dienste und zwischen Diensten im Cluster steuern.

Da Autopilot hochgradig konfigurierbar ist, kann dies die beste Option sein, wenn Sie mehrere Dienste mit einer hohen Netzwerkabhängigkeit oder komplexe Anforderungen an die Weiterleitung von Traffic zwischen Ihren Anwendungskomponenten haben. Ein Beispiel für dieses Muster ist eine verteilte Anwendung, die in zahlreiche Mikrodienste zerlegt ist, die komplexe Abhängigkeitsmuster aufweisen. In solchen Fällen können Sie mit den Netzwerkkonfigurationsoptionen in Autopilot die Interaktionen zwischen Diensten verwalten und steuern.

Horizontale und vertikale Skalierbarkeit

Sowohl Cloud Run als auch GKE Autopilot unterstützen die manuelle und automatische horizontale Skalierung für Dienste und Jobs. Die horizontale Skalierung bietet bei Bedarf mehr Rechenleistung und entfernt sie, wenn sie nicht benötigt wird. Bei einer typischen Arbeitslast kann Cloud Run in der Regel schneller horizontal skaliert werden als GKE Autopilot, um auf Spitzen bei der Anzahl der Anfragen pro Sekunde zu reagieren. Beispiel: Die Videodemonstration „What's New in Serverless Compute?“ zeigt die Skalierung von Cloud Run von null auf über 10.000 Instanzen in etwa 10 Sekunden. Mit Autopilot können Sie zusätzliche Rechenkapazität bereitstellen, um die horizontale Skalierung in Kubernetes zu beschleunigen (zusätzliche Kosten).

Wenn Ihre Anwendung nicht durch Hinzufügen weiterer Instanzen skaliert werden kann, um die verfügbaren Ressourcen zu erhöhen, ist Autopilot möglicherweise die bessere Lösung. Autopilot unterstützt die vertikale Skalierung, um die verfügbare Rechenleistung dynamisch zu variieren, ohne die Anzahl der laufenden Instanzen der Anwendung zu erhöhen.

Mit Cloud Run können Ihre Anwendungen automatisch auf null Replikate herunterskaliert werden, wenn sie nicht verwendet werden. Das ist hilfreich für bestimmte Anwendungsfälle, bei denen Kostenoptimierung im Vordergrund steht. Aufgrund der Merkmale der Skalierung Ihrer Anwendungen auf null gibt es mehrere Optimierungsschritte, mit denen Sie die Zeit zwischen dem Eintreffen einer Anfrage und dem Zeitpunkt minimieren können, zu dem Ihre Anwendung einsatzbereit ist und die Anfrage verarbeiten kann.

Unterstützung für zustandsorientierte Anwendungen

Autopilot bietet eine vollständige Unterstützung für Kubernetes-Volumes, die von nichtflüchtigen Laufwerken gestützt werden. So können Sie eine Vielzahl von zustandsorientierten Bereitstellungen ausführen, einschließlich selbst verwalteter Datenbanken. Sowohl Cloud Run als auch GKE Autopilot ermöglichen die Verbindung mit anderen Diensten wie Filestore und Cloud Storage-Buckets. Außerdem können Sie mit beiden Optionen Objektspeicher-Buckets mit Cloud Storage FUSE im Dateisystem bereitstellen.

Cloud Run verwendet ein In-Memory-Dateisystem, das für Anwendungen, die ein nichtflüchtiges lokales Dateisystem erfordern, möglicherweise nicht geeignet ist. Außerdem wird das lokale In-Memory-Dateisystem mit dem Arbeitsspeicher Ihrer Anwendung geteilt. Sowohl das sitzungsspezifische Dateisystem als auch die Arbeitsspeichernutzung durch die Anwendung und den Container tragen dazu bei, dass das Speicherlimit erreicht wird. Sie können dieses Problem vermeiden, indem Sie ein dediziertes In-Memory-Volume mit einer Größenbeschränkung verwenden.

Ein Dienst- oder Jobcontainer in Cloud Run hat eine maximale Aufgabenzeitüberschreitung. Ein Container, der in einem Pod in einem Autopilot-Cluster ausgeführt wird, kann neu geplant werden, sofern die Einschränkungen eingehalten werden, die mit Budgets für Pod-Störungen (PDBs) konfiguriert sind. Pods können jedoch bis zu sieben Tage lang ausgeführt werden, wenn sie vor der Bereinigung geschützt sind, die durch automatische Knoten-Upgrades oder Herunterskalierungsereignisse verursacht wird. In der Regel ist das Zeitlimit für Aufgaben eher bei Batcharbeitslasten in Cloud Run ein Thema. Bei langlebigen Arbeitslasten und Batchaufgaben, die nicht innerhalb der maximalen Aufgabendauer abgeschlossen werden können, ist Autopilot möglicherweise die beste Option.

CPU-Architektur

Alle Rechenplattformen von Google Cloud unterstützen die x86-CPU-Architektur. Cloud Run unterstützt keine Prozessoren mit Arm-Architektur. Autopilot unterstützt jedoch verwaltete Knoten, die von der Arm-Architektur gestützt werden. Wenn für Ihre Arbeitslast die Arm-Architektur erforderlich ist, müssen Sie Autopilot verwenden.

Accelerator-Auslagerung

Autopilot unterstützt die Verwendung von GPUs und die Verwendung von TPUs, einschließlich der Möglichkeit, reservierte Ressourcen zu nutzen. Cloud Run unterstützt die Verwendung von GPUs, allerdings mit einigen Einschränkungen.

Hohe Anforderungen an Arbeitsspeicher, CPU und andere Ressourcen

Im Vergleich zu den Grenzwerten für Ressourcenanfragen in GKE Autopilot sind die maximalen CPU- und Arbeitsspeicherressourcen, die von einem einzelnen Cloud Run-Dienst oder -Job (einer einzelnen Instanz) beansprucht werden können, eingeschränkt. Je nach den Merkmalen Ihrer Arbeitslasten gelten für Cloud Run möglicherweise weitere Einschränkungen, die die verfügbaren Ressourcen begrenzen. So sind bei Cloud Run beispielsweise die Startzeitüberschreitung und die maximale Anzahl ausgehender Verbindungen möglicherweise begrenzt. Bei Autopilot gelten einige Limits möglicherweise nicht oder es sind höhere zulässige Werte möglich.

Explizite Abhängigkeit von Kubernetes

Einige Anwendungen, Bibliotheken oder Frameworks haben möglicherweise eine explizite Abhängigkeit von Kubernetes. Die Kubernetes-Abhängigkeit kann eine der folgenden Ursachen haben:

  1. Die Anwendungsanforderungen (z. B. ob die Anwendung Kubernetes APIs aufruft oder benutzerdefinierte Kubernetes-Ressourcen verwendet)
  2. Die Anforderungen der Tools, die zum Konfigurieren oder Bereitstellen der Anwendung verwendet werden (z. B. Helm)
  3. Die Supportanforderungen eines Drittanbieters oder Lieferanten

In diesen Fällen ist Autopilot die Ziellaufzeitumgebung, da Kubernetes in Cloud Run nicht unterstützt wird.

Komplexe RBAC für die Mehrmandantenfähigkeit

Wenn Ihre Organisation besonders komplexe Organisationsstrukturen oder Anforderungen an die Mehrfachnutzung hat, verwenden Sie Autopilot, um die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) von Kubernetes zu nutzen. Eine einfachere Option sind die Sicherheits- und Trennungsfunktionen, die in Cloud Run integriert sind.

Organisatorische Aspekte

Im Folgenden finden Sie einige organisatorische Aspekte, die Ihre Auswahl der Umgebung beeinflussen:

  • Umfassende technische Strategie: Die technische Ausrichtung Ihrer Organisation.
  • Kubernetes-Ökosystem nutzen: Interesse am Nutzen der OSS-Community.
  • Bestehende interne Tools: Bestehende Nutzung bestimmter Tools.
  • Entwicklungsteamprofile: Fähigkeiten und Erfahrung der Entwickler.
  • Betriebsunterstützung: Fähigkeiten und Schwerpunkte der Betriebsteams.

In den folgenden Abschnitten werden diese organisatorischen Überlegungen beschrieben, um Ihnen bei der Auswahl einer Umgebung zu helfen.

Allgemeine technische Strategie

Organisationen oder Teams haben möglicherweise vereinbarte Strategien, im Rahmen derer sie bestimmte Technologien anderen vorziehen. Wenn ein Team beispielsweise eine Vereinbarung hat, nach Möglichkeit auf serverlose Lösungen oder Kubernetes zu standardisieren, kann diese Vereinbarung die Ziellaufzeitumgebung beeinflussen oder sogar vorschreiben.

Wenn eine bestimmte Arbeitslast nicht gut zur in der Strategie angegebenen Laufzeitumgebung passt, können Sie eine oder mehrere der folgenden Optionen mit den entsprechenden Einschränkungen auswählen:

  • Arbeitslast neu strukturieren. Wenn die Arbeitslast jedoch nicht gut passt, kann dies zu einer suboptimalen Leistung, zu höheren Kosten, zu Sicherheitsproblemen oder anderen Nachteilen führen.
  • Arbeitslast als Ausnahme von der strategischen Ausrichtung registrieren. Wenn Ausnahmen jedoch zu oft verwendet werden, kann dies zu einem uneinheitlichen Technologieportfolio führen.
  • Strategie überdenken. Dies kann jedoch zu Richtlinienaufwand führen, der den Fortschritt behindern oder blockieren kann.

Kubernetes-Ökosystem nutzen

Im Rahmen der oben beschriebenen umfassenden technischen Strategie entscheiden sich Organisationen oder Teams möglicherweise aufgrund des umfangreichen und wachsenden Ökosystems für Kubernetes als Plattform. Diese Auswahl unterscheidet sich von der Auswahl von Kubernetes aufgrund technischer Anwendungsabhängigkeiten, wie im vorherigen Abschnitt Explizite Abhängigkeit von Kubernetes beschrieben. Bei der Entscheidung für das Kubernetes-Ökosystem wird Wert auf eine aktive Community, umfangreiche Drittanbietertools sowie strenge Standards und Portabilität gelegt. Mit dem Kubernetes-System können Sie die Entwicklungsgeschwindigkeit beschleunigen und die Produkteinführungszeit verkürzen.

Vorhandene interne Tools

In einigen Fällen kann es vorteilhaft sein, vorhandene Tool-Ökosysteme in Ihrer Organisation oder Ihrem Team zu verwenden (für eine beliebige der Umgebungen). Wenn Sie beispielsweise Kubernetes verwenden, können Sie weiterhin Bereitstellungstools wie ArgoCD, Sicherheits- und Richtlinientools wie Gatekeeper und Paketverwaltungstools wie Helm verwenden. Vorhandene Tools können etablierte Regeln für die Automatisierung der Compliance-Anforderungen der Organisation und andere Funktionen umfassen, die für die Implementierung in einer alternativen Zielumgebung kostspielig sein oder viel Vorlaufzeit erfordern können.

Entwicklungsteamprofile

Ein Anwendungs- oder Arbeitslastteam hat möglicherweise bereits Erfahrung mit Kubernetes, was die Geschwindigkeit und die Kompetenz des Teams bei der Nutzung von Autopilot erhöhen kann. Es kann einige Zeit dauern, bis ein Team mit einer neuen Laufzeitumgebung vertraut ist. Je nach Betriebsmodell kann dies während der Weiterbildung zu einer geringeren Plattformzuverlässigkeit führen.

Bei einem wachsenden Team kann die Auswahl an Bewerbern die Plattformauswahl einer Organisation beeinflussen. In einigen Märkten sind Kubernetes-Kenntnisse möglicherweise knapp und daher mit einer Einstellungsprämie verbunden. Wenn Sie eine Umgebung wie Cloud Run auswählen, können Sie den Einstellungsprozess optimieren und das Team innerhalb Ihres Budgets schneller vergrößern.

Operativer Support

Berücksichtigen Sie bei der Auswahl einer Laufzeitumgebung die Erfahrung und Fähigkeiten Ihrer SRE-, DevOps- und Plattformteams sowie anderer Betriebsmitarbeiter. Die Fähigkeit der Betriebsteams, die Produktionsumgebung effektiv zu unterstützen, ist in puncto Zuverlässigkeit entscheidend. Es ist auch wichtig, dass die Betriebsteams Vorproduktionsumgebungen unterstützen können, damit die Entwicklergeschwindigkeit nicht durch Ausfallzeiten, die Abhängigkeit von manuellen Prozessen oder umständliche Bereitstellungsmechanismen beeinträchtigt wird.

Wenn Sie Kubernetes verwenden, kann ein zentrales Betriebs- oder Plattformentwicklungsteam Autopilot-Kubernetes-Upgrades übernehmen. Die Upgrades sind zwar automatisch, werden aber in der Regel von den Betriebsmitarbeitern genau beobachtet, um Unterbrechungen Ihrer Arbeitslasten zu minimieren. Einige Organisationen führen das Upgrade von Versionen der Steuerungsebene manuell aus. GKE Enterprise bietet außerdem Funktionen zur Optimierung und Vereinfachung der Verwaltung von Anwendungen in mehreren Clustern.

Im Gegensatz zu Autopilot erfordert Cloud Run keinen laufenden Verwaltungsaufwand oder Upgrades der Steuerungsebene. Mit Cloud Run können Sie Ihre Betriebsabläufe vereinfachen. Wenn Sie eine einzelne Laufzeitumgebung auswählen, können Sie Ihre Betriebsabläufe weiter vereinfachen. Wenn Sie mehrere Laufzeitumgebungen verwenden, müssen Sie dafür sorgen, dass das Team die Kapazität, die Fähigkeiten und das Interesse hat, diese Laufzeitumgebungen zu unterstützen.

Auswahl

Beginnen Sie den Auswahlprozess, indem Sie mit den verschiedenen Stakeholdern sprechen. Stellen Sie für jede Anwendung eine Arbeitsgruppe zusammen, die aus Entwicklern, Betriebsmitarbeitern, Vertretern einer zentralen Technologie-Governance-Gruppe, Nutzern und Verbrauchern der internen Anwendung, Sicherheitsteams, Cloud-Finanzoptimierungsteams und anderen Rollen oder Gruppen innerhalb Ihrer Organisation besteht, die relevant sein könnten. Sie können eine Umfrage zur Informationserhebung versenden, um die Merkmale der Anwendung zusammenzustellen, und die Ergebnisse vor der Sitzung teilen. Wir empfehlen, eine kleine Arbeitsgruppe auszuwählen, die nur die erforderlichen Stakeholder umfasst. Nicht alle Vertreter sind möglicherweise für jede Arbeitssitzung erforderlich.

Es kann auch hilfreich sein, Vertreter anderer Teams oder Gruppen einzubeziehen, die Erfahrung mit dem Erstellen und Ausführen von Anwendungen in Autopilot oder Cloud Run oder in beiden haben. Orientieren Sie sich an den technischen und organisatorischen Überlegungen in diesem Dokument, um die Eignung Ihrer Anwendung für die einzelnen Plattformen zu bewerten.

Wir empfehlen Ihnen, nach einigen Monaten einen Termin zu vereinbaren, um die Entscheidung anhand der Ergebnisse im Rahmen der Bereitstellung Ihrer Anwendung in der neuen Umgebung zu bestätigen oder zu überdenken.

Nächste Schritte

Beitragende

Autor: Henry Bell | Cloud Solutions Architect

Weitere Beitragende: