Dieses Dokument hilft Ihnen bei der Planung, Gestaltung und Implementierung Ihrer Migration von OpenShift zu GKE Enterprise. Bei einer inkorrekten Vorgehensweise kann das Verschieben Ihrer Arbeitslasten von einer Umgebung in eine andere sehr schwierig sein. Seien Sie daher sehr sorgfältig bei der Planung und Durchführung Ihrer Migration.
Dieses Dokument ist Teil einer mehrteiligen Reihe zur Migration zu Google Cloud. Weitere Informationen zu der Reihe finden Sie unter Migration zu Google Cloud: Migrationspfad auswählen.
Dieses Dokument ist Teil einer Reihe zur Migration von Containern zu Google Cloud:
- Container zu Google Cloud migrieren: Kubernetes zu Google Kubernetes Engine (GKE) migrieren
- Container zu Google Cloud migrieren: Von OpenShift zu GKE Enterprise migrieren (dieses Dokument)
- Container zu Google Cloud migrieren: OpenShift-Projekte zu GKE Enterprise migrieren
- Von OpenShift zu GKE Enterprise migrieren: OpenShift-SCCs zu Policy Controller-Einschränkungen migrieren
Dieses Dokument bietet nützliche Informationen, wenn Sie von OpenShift, das in einer lokalen oder privaten Hosting-Umgebung oder über einen anderen Cloud-Anbieter ausgeführt wird, zu GKE Enterprise migrieren möchten. Dieses Dokument ist auch hilfreich, wenn Sie die Möglichkeit zur Migration in Betracht ziehen und sich ein Bild davon machen möchten. Die Zielumgebung kann eine der folgenden sein:
- Eine vollständig in Google Cloud gehostete Umgebung
- Eine Hybridumgebung, in der Sie einen Teil Ihrer Arbeitslast lokal oder in einer privaten Hosting-Umgebung verwalten und den Rest zu Google Cloud migrieren
Entscheiden Sie anhand Ihrer Anforderungen, welche Umgebung für Sie am besten geeignet ist. So können Sie sich beispielsweise darauf konzentrieren, den Wert Ihres Unternehmens zu steigern, statt sich um die Infrastruktur zu kümmern, indem Sie zu einer öffentlichen Cloud-Umgebung migrieren und einige Zuständigkeiten an Google auslagern. Sie profitieren von einem flexiblen Nutzungsmodell, durch das Sie die Ausgaben und den Ressourceneinsatz optimieren können. Wenn Sie besondere Anforderungen haben, z. B. dass einige Ihrer Arbeitslasten außerhalb von Google Cloud bleiben müssen, können Sie eine Hybridumgebung in Betracht ziehen, z. B. wenn Sie einen Teil Ihrer Arbeitslasten in Ihrer aktuellen Umgebung beibehalten müssen, um Richtlinien und Vorschriften in Bezug auf den Datenstandort zu erfüllen. Sie können auch eine Migrationsstrategie zum Verbessern und Verschieben implementieren, bei der Sie zuerst Ihre Arbeitslasten modernisieren und dann zu Google Cloud migrieren.
Unabhängig vom Typ Ihrer Zielumgebung besteht das Ziel dieser Migration darin, Ihre in dieser Umgebung ausgeführten Arbeitslasten mit GKE Enterprise zu verwalten. Durch die Einführung von GKE Enterprise haben Sie Zugriff auf eine Reihe von Diensten, darunter:
- Multi-Cluster-Verwaltung, mit der Sie und Ihre Organisation Cluster, Infrastruktur und Arbeitslasten in Cloud- und lokalen Umgebungen zentral verwalten können
- Config Sync und Policy Controller, um eine gemeinsame Konfiguration und Richtlinien für Ihre gesamte Infrastruktur zu erstellen und diese sowohl lokal als auch in der Cloud anzuwenden
- Cloud Service Mesh für ein vollständig verwaltetes Service Mesh, das den Betrieb von Diensten, das Traffic-Management, die Telemetrie und die Sicherung der Kommunikation zwischen Diensten vereinfacht
- Binärautorisierung, um sicherzustellen, dass die Container, die Sie in Ihren Umgebungen bereitstellen, vertrauenswürdig sind
- Knative Serving zur Unterstützung Ihrer serverlosen Arbeitslasten in Ihrer GKE Enterprise-Umgebung.
Wir empfehlen Ihnen, diese Dienste bereits in einem frühen Stadium Ihres Migrationsprozesses zu evaluieren, während Sie Ihre Migration noch planen. Es ist einfacher, diese Dienste jetzt zu übernehmen, statt Ihre Prozesse und Infrastruktur später zu ändern. Sie können mit der Verwendung dieser Dienste entweder sofort oder bei der Modernisierung Ihrer Arbeitslasten beginnen.
Bei dieser Migration folgen Sie dem unter Migration zu Google Cloud: Einstieg definierten Migrations-Framework. Das Framework besteht aus vier Phasen:
- Arbeitslasten bewerten und erkennen
- Grundlagen planen und aufbauen
- Arbeitslasten bereitstellen
- Umgebung optimieren
Die folgende Grafik veranschaulicht den Migrationsprozess:
Dieses Dokument basiert auf Konzepten, die unter Container zu Google Cloud migrieren: Kubernetes zu GKE migrieren behandelt werden. Daher finden Sie hier gegebenenfalls Links zu diesem Dokument.
Arbeitslasten bewerten und erkennen
In der Bewertungsphase bestimmen Sie die Anforderungen und Abhängigkeiten für die Migration Ihrer Arbeitslasten von OpenShift zu GKE Enterprise:
- Erstellen Sie ein umfassendes Inventar Ihrer Abläufe und Anwendungen.
- Katalogisieren Sie Ihre Abläufe und Anwendungen entsprechend ihren Eigenschaften und Abhängigkeiten.
- Bereiten Sie die Teams auf Google Cloud vor.
- Erstellen Sie Tests und Proofs of Concept in Google Cloud.
- Berechnen Sie die Gesamtbetriebskosten (TCO) der Zielumgebung.
- Die Arbeitslasten auswählen, die als Erstes migriert werden sollen.
Die folgenden Abschnitte basieren auf Migration zu Google Cloud: Arbeitslasten bewerten und erkennen. Sie enthalten jedoch Informationen, die sich speziell auf die Bewertung von Arbeitslasten beziehen, die Sie von OpenShift zu GKE Enterprise migrieren möchten.
Inventar erstellen
Beachten Sie Folgendes beim Erstellen des Inventars der Komponenten Ihrer Umgebung:
- Dienstbereitstellungs- und Plattformverwaltungsmodell
- OpenShift-Projekte
- Build- und Bereitstellungsprozess
- Arbeitslasten, Anforderungen und Abhängigkeiten
- Konfiguration der OpenShift-Cluster
Dienstbereitstellungs- und Plattformverwaltungsmodell
Um Arbeitslasten von OpenShift zu GKE Enterprise zu migrieren, bewerten Sie das aktuelle Dienstbereitstellungs- und Plattformverwaltungsmodell Ihrer OpenShift-Umgebung. Dieses Modell entspricht wahrscheinlich Ihrer aktuellen Organisationsstruktur und Ihren Anforderungen. Wenn Sie feststellen, dass das aktuelle Modell die Anforderungen der Organisation nicht erfüllt, können Sie diese Migration zur Verbesserung des Modells nutzen.
Sammeln Sie zuerst Informationen zu den Teams, die für die folgenden Aspekte zuständig sind:
- Anwendungsentwicklung und -bereitstellung, einschließlich aller OpenShift-Nutzer; normalerweise Entwicklungs- oder Arbeitslast-Release-Teams.
- OpenShift-Plattformverwaltung, einschließlich Erstellen von OpenShift-Projekten, Zuweisen von Rollen zu Nutzern, Konfigurieren von Sicherheitskontexten und Konfigurieren von CI/CD-Pipelines.
- OpenShift-Installation und Clusterverwaltung, einschließlich OpenShift-Installation, Upgrade, Clusterskalierung und Kapazitätsverwaltung.
- Infrastrukturverwaltung. Diese Teams verwalten physische Server, Speicher, Netzwerke, die Virtualisierungsplattform und Betriebssysteme.
Ein Modell zur Dienstbereitstellung und Plattformverwaltung kann aus folgenden Teams bestehen:
- Entwicklungsteam: Dieses Team entwickelt Arbeitslasten und stellt sie in OpenShift bereit. Bei komplexen Produktionsumgebungen unterscheidet sich das Team, das Arbeitslasten bereitstellt, möglicherweise vom Entwicklungsteam. Der Einfachheit halber betrachten wir dieses Team als Teil des Entwicklungsteams. In Self-Service-Umgebungen ist das Entwicklungsteam auch für die Erstellung von OpenShift-Projekten verantwortlich.
- Plattformteam: Dieses Team ist für die OpenShift-Plattformverwaltung zuständig und die Mitglieder werden in der Regel als OpenShift-Clusteradministratoren bezeichnet. Dieses Team konfiguriert OpenShift-Projektvorlagen für verschiedene Entwicklungsteams und erstellt in stärker verwalteten Umgebungen OpenShift-Projekte. Dieses Team weist auch Rollen und Berechtigungen zu, konfiguriert Sicherheitskontexte und die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC), definiert Kontingente für Rechenressourcen und -objekte sowie Build- und Bereitstellungsstrategien. Sie werden manchmal als DevOps-Team oder als Middleware-Team bezeichnet, wenn sie Middleware- und Anwendungsserverkonfigurationen für Entwickler verwalten. Das Plattform- und das Infrastrukturteam sind möglicherweise auch an untergeordneten OpenShift-Clusterverwaltungsaktivitäten beteiligt, z. B. Software-Installation und -Upgrade, Clusterskalierung und Kapazitätsverwaltung.
- Infrastrukturteam: Dieses Team verwaltet die zugrunde liegende Infrastruktur, die die OpenShift-Umgebung unterstützt. Es ist beispielsweise für Server, Speicher, Netzwerke, die Virtualisierungsplattform und das Basisbetriebssystem zuständig. Dieses Team wird manchmal als Rechenzentrumsteam oder operatives Team bezeichnet. Wenn OpenShift in einer öffentlichen Cloud-Umgebung bereitgestellt wird, ist dieses Team für die IaaS-Dienste (Infrastructure as a Service) verantwortlich, die ein Anbieter öffentlicher Clouds bereitstellt.
Außerdem sollten Sie prüfen, ob Sie dedizierte OpenShift-Cluster für verschiedene Umgebungen haben. Sie könnten zum Beispiel unterschiedliche Umgebungen für Entwicklung, Qualitätssicherung und Produktion haben oder zur Trennung verschiedener Netzwerk- und Sicherheitszonen, wie interner Zonen und demilitarisierter Zonen.
OpenShift-Projekte
Ein OpenShift-Projekt ist ein Kubernetes-Namespace mit zusätzlichen Annotationen. So können Entwickler Ressourcen getrennt von anderen Teams verwalten, um Ressourcen logisch zu trennen. Wenn Sie das Inventar Ihrer OpenShift-Projekte erstellen, sollten Sie für jedes Projekt Folgendes berücksichtigen:
- Clusterrollen und lokale Rollen: OpenShift unterstützt sowohl lokale Rollen für ein OpenShift-Projekt als auch clusterweite Rollen. Sie prüfen, ob Sie Cluster und lokale Rollen erstellt haben, um ein effektives Zugriffssteuerungsverfahren in der Zielumgebung zu entwerfen.
- Rollenbindungen, sowohl für Clusterrollen als auch für lokale Rollen: Nutzer und Gruppen erhalten die Berechtigung, Vorgänge für OpenShift-Projekte auszuführen, indem ihnen Rollenbindungen zugewiesen werden. Rollen können sich auf Clusterebene oder auf lokaler Ebene befinden. Häufig sind lokale Rollenbindungen an vordefinierte Clusterrollen gebunden. Die Standardbindung der OpenShift-Projektadministratorrolle könnte beispielsweise an die Standardrolle des Clusteradministrators gebunden sein.
- Ressourcenkontingente: Um den aggregierten Ressourcenverbrauch zu beschränken, können Sie in OpenShift sowohl OpenShift-Kontingente auf Projektebene als auch Kontingente für mehrere OpenShift-Projekte definieren. Sie prüfen, wie sie Kubernetes-Ressourcenkontingenten (ResourceQuotas) zugeordnet werden, und erstellen eine Liste aller Ressourcenkontingente, die Sie in Ihrer OpenShift-Umgebung bereitgestellt und konfiguriert haben.
Unter Umgebung bewerten wird beschrieben, wie Sie Kubernetes-Ressourcen wie Dienstkonten (ServiceAccounts) und nichtflüchtige Volumes (PersistentVolumes) bewerten.
Build- und Bereitstellungsprozesse
Nachdem Sie Informationen zum Modell für die Dienstbereitstellung und Plattformverwaltung sowie zu OpenShift-Projekten gesammelt haben, bewerten Sie, wie Sie Ihre Arbeitslasten erstellen und in Ihrer Umgebung bereitstellen.
In Ihrer vorhandenen OpenShift-Umgebung haben Sie möglicherweise denselben Build- und Bereitstellungsprozess für alle Ihre Arbeitslasten oder es müssen verschiedene Prozesse geprüft werden. Artefakte des Build-Prozesses für eine containerisierte Arbeitslast sind Container-Images. In einer OpenShift-Umgebung können Sie Container-Images erstellen, speichern und auf verschiedene Arten bereitstellen:
- Der Build-Prozess für Container-Images wird vollständig außerhalb von OpenShift ausgeführt. Der Build-Prozess kann auf manuellen Schritten oder auf einer automatisierten CI/CD-Pipeline (Continuous Integration/Continuous Deployment) basieren, die das Container-Image und Kubernetes-Manifeste als Endprodukt enthält.
- Der Build-Prozess für Container-Images wird in OpenShift ausgeführt. OpenShift unterstützt verschiedene Optionen, beispielsweise die Bereitstellung eines Dockerfile und aller erforderlichen Artefakte zum Erstellen eines Container-Images, die Konfiguration eines Quelle-zu-Image-Builds, die Konfiguration eines Pipeline-Builds oder die Konfiguration eines benutzerdefinierten Builds. Bei diesen Build-Strategien wird eine BuildConfig-Ressource erstellt, die die Build-Auswahl, den Speicherort der Quellartefakte, die Zielcontainer-Images sowie die Ereignisse definiert, die die Erstellung des Container-Images auslösen können.
Nachdem Sie ein Container-Image erstellt haben, speichern Sie es in einer Container Registry, die Sie später bereitstellen können. Ihre Container Registry kann entweder in OpenShift oder außerhalb Ihrer OpenShift-Umgebung gehostet werden. Bewerten Sie diesen Aspekt, da Sie möglicherweise ein ähnliches System in Ihrer Zielumgebung benötigen.
Arbeitslasten, Anforderungen und Abhängigkeiten
Jede OpenShift-Anwendung enthält die folgenden Komponenten:
- Eine OpenShift-Deployment-Konfiguration (DeploymentConfig) oder ein Kubernetes-Deployment-Objekt. Weitere Informationen zu den Unterschieden zwischen diesen Objekten finden Sie unter Comparing Deployments and DeploymentConfigs (Deployment und DeploymentConfigs vergleichen).
- Ein Kubernetes-Service, über den Clients auf Ihre Anwendung zugreifen können, und eine OpenShift-Route, um von außerhalb des Clusters eine Verbindung zu diesem Kubernetes-Service herzustellen.
- Ein OpenShift-Image-Stream (ImageStream), der eine Zusammenfassung zum Verweis auf Container-Images bereitstellt. Ein OpenShift-Image-Stream enthält ein oder mehrere Container-Images, die jeweils durch Tags gekennzeichnet sind, und stellt eine einzige abstrakte Ansicht verwandter Images dar, ähnlich einem Container-Image-Repository.
- Eine OpenShift-Build-Konfiguration (BuildConfig) zum Erstellen der Container-Images dieser OpenShift-Anwendung in OpenShift.
Je nach Zweck der Anwendung können Sie anstelle der Deployment- oder DeploymentConfig-Objekte verschiedene Objekte zum Definieren der Anwendung verwenden:
- Definieren Sie Batchanwendungen mit Job oder Cronjob.
- Definieren Sie zustandsorientierte Anwendungen mit StatefulSets.
- Wenn Sie vorgangsbezogene Arbeitslasten haben, die auf jedem Knoten ausgeführt werden müssen oder an bestimmte Knoten gebunden sind, können Sie diese mit DaemonSets definieren.
In der folgenden Tabelle sind die wichtigsten Spezifikationen und Parameter aufgeführt, die Sie aus OpenShift-Ressourcen abrufen, um die Anwendungen in die GKE Enterprise-Zielumgebung zu migrieren.
Quell-OpenShift-Ressourcenmanifest | Die wichtigsten Spezifikationen und Parameter |
---|---|
Deployment, DeploymentConfig, StatefulSet, Job, Cronjob | Container-Image und -Repository, Containerport, Anzahl der Pod-Replikate, ConfigMaps, Secrets, PersistentVolumeClaims, Ressourcenanfragen und -limits, Aktualisierungsstrategie, StatefulSet-Service-Name, Cronjob-Zeitplan |
ImageStream | Container-Image, Image-Pull-Richtlinie, Container-Image-Repository |
Horizontales Pod-Autoscaling | Autoscaling-Kriterien |
Service | Hostname, der zur Verbindung mit der Anwendung von innerhalb des Clusters verwendet wird, IP-Adresse und Port, auf denen der Service bereitgestellt wird, sowie für externe Ressourcen erstellte Endpunkte |
Route | Hostname und Ressourcenpfad, der verwendet wird, um von außerhalb des Clusters eine Verbindung zur Anwendung herzustellen, sowie Routingregeln, Verschlüsselung und Informationen zur Zertifikatskette |
Unter Umgebung bewerten wird beschrieben, wie Kubernetes-Ressourcen bewertet werden:
- Andere Kubernetes-Controller
- Horizontales Pod-Autoscaling
- Pod-Sicherheitskontexte
- Zustandslose und zustandsorientierte Arbeitslasten
- Speicher
- Konfiguration und Einfügen von Secrets
- Ingress-Instanzen
- Logging und Monitoring
Mit OpenShift 4 wurde das Operator Framework eingeführt. Wenn Sie diese OpenShift-Version verwenden, haben Sie möglicherweise einige Anwendungen mit installierten Operatoren bereitgestellt. In diesem Fall rufen Sie die Liste der installierten Operatoren ab und erfassen für jeden von ihnen Informationen zu den bereitgestellten Operatorinstanzen. Diese Instanzen sind vom Operator definierte benutzerdefinierte Ressourcen, die einige der zuvor aufgeführten Kubernetes-Ressourcen bereitstellen.
Zusätzlich zu diesen Ressourcen bewerten Sie Folgendes:
- Anforderungen der Anwendung an die Netzwerkverbindung: Müssen Ihre Services oder Pods beispielsweise für ein bestimmtes Netzwerk verfügbar sein? Müssen sie bestimmte Back-End-Systeme erreichen?
- Einschränkungen für die Ausführung von Arbeitslasten an einem bestimmten Standort: Müssen beispielsweise alle Arbeitslasten oder Datasets lokal bleiben, um Anforderungen wie Latenzzeiten bei der Kommunikation mit anderen Arbeitslasten, Richtlinien in Bezug auf den Datenstandort und Nähe zu den Nutzern zu erfüllen?
Konfiguration der OpenShift-Cluster
Als Nächstes bewerten Sie Ihre OpenShift-Cluster. Erfassen Sie für diese Aufgabe die folgenden Informationen:
- OpenShift-Version: Die Hauptversionen von OpenShift in diesem Dokument sind OpenShift 3 und OpenShift 4. Verschiedene OpenShift-Versionen können unterschiedliche Funktionen haben. Sie prüfen, welche Version von OpenShift Sie verwenden, um festzustellen, ob Sie versionsspezifische OpenShift-Features verwenden.
- Für die Authentifizierung verwendeter Identitätsanbieter: Für die Authentifizierung verwenden Sie möglicherweise den integrierten OAuth-Server und einen oder mehrere Identitätsanbieter.
- Sicherheitskontextbeschränkungen: Bewerten Sie die OpenShift-Sicherheitskontextbeschränkungen, die Sie in Ihren Clustern festgelegt haben, deren Konfiguration und die Nutzer, Gruppen und Dienstkonten, denen sie zugewiesen sind.
- Netzwerkrichtlinie und -isolation: Prüfen Sie NetworkPolicies, die Konfiguration der Pod-Netzwerkisolation und welchen OpenShift-SDN-Modus Sie in Ihren Clustern konfiguriert haben.
Monitoring: Bewerten Sie Ihre aktuellen Monitoring-Anforderungen und wie Sie Ihr aktuelles Monitoring-System bereitgestellt und konfiguriert haben, um zu entscheiden, wie Sie eine Monitoring-Lösung in der Zielumgebung entwerfen und implementieren möchten. Anhand dieser Bewertung können Sie entscheiden, ob Sie eine neue Monitoring-Lösung verwenden möchten oder die vorhandene Lösung weiterhin verwenden können. Viele OpenShift-Versionen enthalten einen auf Prometheus basierenden Monitoring-Stack zum Überwachen von Systemkomponenten, der auch für das Anwendungs-Monitoring verwendet werden kann. Berücksichtigen Sie beim Entwerfen Ihrer Ziellösung Folgendes:
- Die Monitoring-Lösung, die Sie derzeit in Ihrer OpenShift-Umgebung verwenden, z. B. eine von OpenShift gehostete Prometheus-Lösung, ein unabhängiger Prometheus-Grafana-Stack, Zabbix, InflowData oder Nagios
- Wie Messwerte erzeugt und erfasst werden, z. B. ein Pull- oder Push-Mechanismus
- Abhängigkeiten von Komponenten, die in Ihren OpenShift-Clustern bereitgestellt werden
- Den Standort Ihres Monitoringsystems, das beispielsweise in einer Cloud-Umgebung oder lokal bereitgestellt sein kann
- Die derzeit für Ihre Arbeitslasten erfassten Messwerte
- Die Benachrichtigungen zu Messwerten, die Sie in Ihrem aktuellen Monitoringsystem konfiguriert haben
Logging: Bewerten Sie Ihre aktuellen Logging-Anforderungen und wie Sie Ihr aktuelles Logging-System bereitgestellt und konfiguriert haben, um zu entscheiden, wie Sie eine Logging-Lösung in der Zielumgebung entwerfen und implementieren möchten. Anhand dieser Bewertung können Sie entscheiden, ob Sie eine neue Logging-Lösung verwenden möchten oder die vorhandene Lösung weiterhin verwenden können. Viele OpenShift-Versionen werden mit einer Logging-Lösung geliefert, die auf einem Elasticsearch-, Fluentd- und Kibana-Stack (EFK) basiert, der zum Erfassen von Logs aus den Systemkomponenten verwendet wird. Diese Lösung kann auch für das Anwendungs-Logging verwendet werden. Berücksichtigen Sie beim Entwerfen Ihrer Ziellösung Folgendes:
- Das Logging-System, das Sie derzeit in Ihrer OpenShift-Umgebung verwenden, z. B. ein von OpenShift gehosteter EFK-Stack, ein unabhängiger EFK-Stack oder Splunk
- Abhängigkeiten von Komponenten, die in Ihren OpenShift-Clustern bereitgestellt werden
- Architektur und Kapazität der Logspeicherkomponenten
- Den Standort Ihres Logging-Systems, das beispielsweise in einer Cloud-Umgebung oder lokal bereitgestellt sein kann
- Die Aufbewahrungsrichtlinien und die Konfiguration von Logs
Unter Umgebung bewerten wird Folgendes beschrieben:
- Anzahl der Cluster
- Anzahl und Typ der Knoten pro Cluster
- Weitere Überlegungen zu Logging, Monitoring und Tracing
- Benutzerdefinierte Kubernetes-Ressourcen
Bewertung abschließen
Nachdem Sie die Inventare erstellt haben, die sich auf Ihre OpenShift-Prozesse und -Arbeitslasten beziehen, schließen Sie die restlichen Aktivitäten der Bewertungsphase unter Migration zu Google Cloud: Arbeitslasten bewerten und erkennen ab.
Grundlagen planen und aufbauen
In der Planungs- und Aufbauphase stellen Sie die Infrastruktur und Dienste bereit, die Ihre Arbeitslasten unterstützen:
- Erstellen Sie eine Ressourcenhierarchie.
- Konfigurieren Sie die Identitäts- und Zugriffsverwaltung.
- Richten Sie die Abrechnung ein.
- Richten Sie die Netzwerkverbindung ein.
- Erhöhen Sie die Sicherheit.
- Richten Sie Monitoring und Benachrichtigungen ein.
Dieser Abschnitt enthält Informationen, die sich speziell auf den Aufbau der Grundlagen in GKE Enterprise beziehen. Diese basieren auf den Informationen unter Migration zu Google Cloud: Grundlagen schaffen.
Bevor Sie eine Grundlage in Google Cloud aufbauen, sollten Sie die technische Übersicht über GKE Enterprise lesen, um zu verstehen, wie GKE Enterprise funktioniert und welche GKE Enterprise-Komponenten Sie möglicherweise benötigen. Abhängig von den Anforderungen der Arbeitslast und der Datenlokalität, die Sie in der Bewertungsphase ermittelt haben, stellen Sie Ihre Arbeitslasten auf GKE on VMware, GKE-Cluster in Google Cloud oder GKE on AWS bereit. Ihre Cluster sind möglicherweise auf verschiedene Umgebungen verteilt. Weitere Informationen zum Aufbau einer Grundlage für GKE on Google Cloud finden Sie unter Grundlagen planen und aufbauen.
Machen Sie sich mit den Kernkonzepten vertraut, um eine Grundlage für GKE on VMware zu schaffen. Achten Sie dann bei der Installation von GKE on VMware auf die folgenden Punkte:
- Sicherstellen, dass die lokale Umgebung die Anforderungen für Anthos GKE On-Prem erfüllt: Sie müssen in Ihrer VMware vSphere-Umgebung genügend Kapazität bereitstellen, um die Anforderungen an Administratorcluster und Nutzercluster zu erfüllen. Diese Anforderungen hängen von der Anzahl Ihrer Ressourcenanfragen für Arbeitslasten und der Anzahl der benötigten Cluster ab. Sie haben beide Aspekte in der Bewertungsphase bestimmt.
Netzwerk einrichten: Sie müssen Ihr lokales Netzwerk so konfigurieren, dass es neben den Installationsanforderungen für GKE on VMware auch die in der Bewertung erfassten Anforderungen an die Netzwerkkonnektivität der Anwendungen erfüllt. Berücksichtigen Sie die folgenden Netzwerkanforderungen:
Informationen zum Aufbau einer Grundlage für GKE on AWS finden Sie in den Kernkonzepten wie GKE on AWS-Architektur und GKE on AWS-Speicher. Berücksichtigen Sie Folgendes bei der Installation von GKE on AWS:
- Sicherstellen, dass die Amazon Web Services- und Google Cloud-Umgebungen die Anforderungen für GKE on AWS erfüllen: GKE on AWS erfordert ein AWS-Konto mit Befehlszeilenzugriff und einen AWS-KMS-Schlüssel (Key Management Service), um Secrets auf Anwendungsebene in Clustern zu verschlüsseln. Sie benötigen Terraform und kubectl.
- AWS-Umgebung konfigurieren: Sie müssen Ihre AWS-Umgebung konfigurieren, Tools wie die AWS-Befehlszeile installieren, AWS-IAM-Anmeldedaten konfigurieren und Ressourcen in Ihrer AWS-Umgebung bereitstellen, z. B. einen AWS KMS-Schlüssel.
- Google Cloud-Umgebung konfigurieren: Sie müssen Ihre Google Cloud-Umgebung konfigurieren, die erforderlichen Google Cloud-Projekte und Dienstkonten erstellen und IAM konfigurieren.
Arbeitslasten bereitstellen
In der Bereitstellungsphase stellen Sie Ihre Arbeitslasten in GKE Enterprise bereit:
- Stellen Sie Laufzeitplattform und -umgebungen bereit und konfigurieren Sie sie.
- Migrieren Sie Daten aus der alten Umgebung in die neue.
- Arbeitslasten bereitstellen
Die folgenden Abschnitte enthalten spezifische Informationen zum Bereitstellen von Arbeitslasten in GKE Enterprise und bauen auf den Informationen in Migration zu Google Cloud: Große Datasets übertragen, Migration zu Google Cloud: Workloads bereitstellen und Migration zu Google Cloud: Von manuellen zu automatisierten, containerisierten Bereitstellungen migrieren auf.
Laufzeitplattform und -umgebungen bereitstellen und konfigurieren
Bevor Sie eine Arbeitslast bereitstellen können, müssen Sie die erforderlichen GKE Enterprise-Cluster bereitstellen und konfigurieren.
Sie können GKE-Cluster in Google Cloud, GKE on VMware-Clustern oder GKE on AWS-Clustern bereitstellen. Wenn Sie beispielsweise eine Arbeitslast haben, die lokal bereitgestellt werden muss, stellen Sie einen oder mehrere GKE on VMware-Cluster bereit. Wenn für Ihre Arbeitslasten keine Standortanforderungen gelten, stellen Sie GKE-Cluster in Google Cloud bereit. In beiden Fällen verwalten und überwachen Sie Ihre Cluster mit GKE Enterprise. Wenn Sie Multi-Cloud-Anforderungen haben, stellen Sie GKE on AWS-Cluster zusammen mit anderen GKE Enterprise-Clustern bereit.
Zuerst definieren Sie die Anzahl und den Typ der benötigten GKE Enterprise-Cluster. Diese Anforderungen hängen größtenteils von den Informationen ab, die Sie in der Bewertungsphase gesammelt haben, z. B. dem Dienstmodell, das Sie implementieren möchten, und der Art und Weise, wie Sie verschiedene Umgebungen isolieren möchten. Wenn derzeit mehrere Entwicklerteams Ihre OpenShift-Cluster gemeinsam nutzen, müssen Sie ein Modell für Mandantenfähigkeit in GKE Enterprise implementieren:
- Verschiedene Kubernetes-Namespaces verwenden: Das Plattformteam erstellt einen Kubernetes-Namespace für jedes OpenShift-Projekt und implementiert ein Modell für Cluster-Mandantenfähigkeit. Dieses Modell ähnelt stark dem Modell, das Sie wahrscheinlich in Ihrer OpenShift-Umgebung verwenden. Daher benötigt es möglicherweise eine Anzahl von GKE Enterprise-Clustern, die der Anzahl Ihrer OpenShift-Cluster entspricht. Bei Bedarf können Sie weiterhin dedizierte Cluster für verschiedene Umgebungen haben.
- Verschiedene GKE Enterprise-Cluster verwenden: Das Infrastrukturteam stellt für jedes Entwicklungsteam einen GKE Enterprise-Cluster bereit; das Plattformteam verwaltet alle diese Cluster. Dieses Modell benötigt möglicherweise mehr GKE Enterprise-Cluster, als die Anzahl Ihrer OpenShift-Cluster beträgt, um mehr Flexibilität und Isolation bei der Entwicklung zu ermöglichen.
- Verschiedene Google Cloud-Projekte verwenden: Das Infrastruktur-Team erstellt für jedes Entwicklungsteam ein Google Cloud-Projekt und stellt GKE Enterprise-Cluster innerhalb dieses Google Cloud-Projekts bereit. Das Plattformteam verwaltet dann diese Cluster. Für dieses Modell sind möglicherweise mehr GKE Enterprise-Cluster erforderlich, als die Anzahl Ihrer OpenShift-Cluster beträgt, um Ihren Entwicklerteams maximale Flexibilität und Isolation zu ermöglichen.
Nachdem Sie die Anzahl der benötigten Cluster und die Umgebung, in der sie bereitgestellt werden sollen, festgelegt haben, definieren Sie Clustergröße, -konfiguration und -knotentypen. Anschließend stellen Sie Ihre Cluster und Knotenpools entsprechend den Arbeitslastanforderungen bereit, die Sie in der Bewertungsphase ermittelt haben. Beispielsweise können für Ihre Arbeitslasten bestimmte Leistungs- und Skalierbarkeitsgarantien sowie andere Anforderungen, z. B. bezüglich GPUs und TPUs, gelten.
Weitere Informationen zum Bereitstellen und Konfigurieren von Clustern finden Sie hier:
- Laufzeitplattform und -umgebungen für GKE-Cluster in Google Cloud bereitstellen und konfigurieren
- Administrator- und Nutzercluster für GKE on VMware-Cluster erstellen
- Verwaltungscluster installieren und Nutzercluster für GKE on AWS-Cluster erstellen
Nachdem Sie Ihre Cluster erstellt und bevor Sie eine Arbeitslast bereitgestellt haben, konfigurieren Sie die folgenden Komponenten, um die Anforderungen zu erfüllen, die Sie in der Bewertungsphase von OpenShift-Projekten und -Clustern ermittelt haben:
- Identitäts- und Zugriffsverwaltung: Sie können die Identitäts- und Zugriffsverwaltung wie unter Identitäts- und Zugriffsverwaltung konfigurieren beschrieben konfigurieren. Sie können zu Cloud Identity als Hauptidentitätsanbieter migrieren oder Google Cloud Directory Sync verwenden, um Cloud Identity mit einem vorhandenen LDAP- oder Active Directory-Server zu synchronisieren. GKE on VMware unterstützt OpenID Connect (OIDC) zur Authentifizierung bei Nutzerclustern über die Befehlszeile. Folgen Sie der Anleitung unter Mit OIDC und Google authentifizieren, um die Befehlszeilenauthentifizierung in Cloud Identity zu integrieren.
- Monitoring: Sie können Ihre aktuelle Monitoring-Lösung entsprechend Ihren Einschränkungen und Anforderungen an die GKE Enterprise-Zielumgebung anpassen. Wenn Ihre aktuelle Lösung auf OpenShift gehostet wird, können Sie Cloud Monitoring implementieren, wie unter Grundlage aufbauen beschrieben. Sie können auch Prometheus und Grafana mit GKE on VMware implementieren.
- Logging: Sie können Ihre aktuelle Logging-Lösung entsprechend Ihren Einschränkungen und Anforderungen an die GKE Enterprise-Zielumgebung anpassen. Wenn Ihre aktuelle Lösung auf OpenShift gehostet wird, können Sie Cloud Logging entsprechend der Anleitung Grundlagen schaffen – Monitoring und Benachrichtigungen implementieren.
Mit Config Sync können Sie die Konfiguration der folgenden Ressourcen zentral in einem gemeinsamen Git-kompatiblen Repository definieren und diese Konfiguration auf alle Cluster anwenden, sowohl lokal als auch in der Cloud:
- Rollenbasierte Zugriffssteuerung (RBAC): Nachdem Sie die Authentifizierung konfiguriert haben, können Sie Ihre Autorisierungsrichtlinien mithilfe einer Kombination aus Identitäts- und Zugriffsverwaltung und Kubernetes RBAC implementieren. Diese Richtlinien erfüllen die Anforderungen, die Sie in der OpenShift-Projektbewertung und dem von Ihnen ausgewählten Modell für Mandantenfähigkeit ermittelt haben.
- Ressourcenkontingente: Sie können Ressourcenkontingente auf Namespaces anwenden, um Entwicklerteams bei Bedarf Kontingente zuzuweisen.
- Sicherheitskontext für Ihre Arbeitslasten: Mit dem Policy Controller können Sie Einschränkungen erstellen, um die Pod-Sicherheit gemäß Ihren Anforderungen und den in der Bewertungsphase ermittelten Sicherheitskontextbeschränkungen von OpenShift zu erzwingen.
- Netzwerkrichtlinie und -isolation: Sie können die erforderliche Netzwerkisolation zwischen Namespaces oder Arbeitslasten mithilfe von Kubernetes-Netzwerkrichtlinien implementieren.
Informationen zum Installieren von Config Sync finden Sie unter Config Sync installieren. Informationen zum Installieren von Policy Controller finden Sie unter Policy Controller installieren.
Daten aus Ihrer alten Umgebung migrieren
Jetzt können Sie Daten aus Ihrer Quellumgebung in die Zielumgebung migrieren.
Wenn Ihre zustandsorientierten OpenShift-Anwendungen Daten auf nichtflüchtigen Kubernetes-Volumes hosten, gibt es verschiedene Strategien, um Daten in die Zielumgebung zu migrieren. Die Auswahl der richtigen Strategie hängt von verschiedenen Faktoren ab, z. B. vom Quell- und Ziel-Back-End-Speicheranbieter und vom Bereitstellungsstandort:
- Nutzen Sie die Funktionen Ihres Speicheranbieters zum Klonen, Exportieren und Importieren von Volumes. Wenn Sie VMware vSphere-Volumes in Ihrer lokalen Umgebung verwenden und zu GKE on VMware migrieren, klonen Sie die nichtflüchtigen Volumes (PersistentVolumes), die den virtuellen VMDK-Laufwerken zugrunde liegen, und stellen Sie sie als Volumes in Ihrer Zielumgebung bereit. Wenn Sie zu GKE migrieren, importieren Sie Ihre virtuellen Laufwerke als nichtflüchtige Compute Engine-Speicher und verwenden Sie sie als nichtflüchtige Volumes.
- Sichern Sie Ihre Daten aus der Quellumgebung mithilfe von Betriebssystem- oder Datenbanktools. Hosten Sie diese Daten an einem temporären Speicherort, auf den beide Umgebungen zugreifen können, und stellen Sie die Daten dann in Ihrer Zielumgebung wieder her.
- Verwenden Sie ein Remote-Kopiertool wie rsync, um Daten aus der Quellumgebung in die Zielumgebung zu kopieren.
- Verwenden Sie eine speicherunabhängige Sicherungslösung wie Velero mit restic-Integration.
Weitere Informationen finden Sie unter Migration zu Google Cloud: Große Datasets übertragen.
Weitere Informationen zum Migrieren von Daten sowie Strategien zum Verwalten des Speichers in GKE finden Sie unter Daten aus der alten Umgebung in die neue migrieren und in den GKE-Dokumenten zur Speicherkonfiguration.
Mit GKE on VMware haben Sie die Wahl zwischen verschiedenen Optionen für die Einbindung in externe Speichersysteme, z. B. über VMware vSphere-Speicher, Integriertes Kubernetes-Volume Plug-ins und CSI-Treiber (Container Storage Interface). Ihre Auswahl hängt davon ab, welches externe Speichersystem Sie integrieren müssen, welche Zugriffsmodi unterstützt werden und ob Sie die dynamische Bereitstellung von Volumes benötigen.
GKE on AWS stellt automatisch den CSI-Treiber für Amazon Elastic Block Store (EBS), eine Standard-StorageClass, die PersistentVolumeClaims mit EBS-Volumes unterstützt, sowie StorageClasses für andere EBS-Volume-Typen bereit. Sie können auch zusätzliche CSI-Treiber und benutzerdefinierte StorageClasses installieren. Wenn Sie ein EBS-Volume haben, das Sie in GKE on AWS importieren möchten, können Sie daraus ein PersistentVolume erstellen.
Arbeitslasten bereitstellen
Nachdem Sie den GKE Enterprise-Cluster bereitgestellt und Daten migriert haben, können Sie nun Ihre Arbeitslasten erstellen und bereitstellen. Sie haben verschiedene Optionen, die von manuellen bis zu vollautomatischen reichen.
Wenn Sie Operatoren verwenden müssen, um Arbeitslasten bereitzustellen, die diese Bereitstellungsmethode in Ihrer OpenShift-Umgebung verwenden, müssen Sie den Operator vor der Bereitstellung Ihrer Arbeitslast installieren. Sie können die Verfügbarkeit der benötigten Operatoren unter den folgenden Quellen prüfen:
- Google Cloud Marketplace
- operatorhub.io
- Website eines bestimmten Softwareanbieters oder GitHub-Repository
Manuell bereitstellen
Wenn Sie Ihre Arbeitslasten manuell in Ihrer OpenShift-Umgebung bereitstellen, können Sie diesen manuellen Bereitstellungsprozess an Ihre neue GKE Enterprise-Umgebung anpassen. Beispielsweise können Sie die OpenShift-Ressourcenmanifeste, die Sie unter Arbeitslasten, Anforderungen und Abhängigkeiten bewertet haben, manuell in die entsprechenden GKE Enterprise-Ressourcenmanifeste übersetzen.
Die folgende Tabelle erweitert die Tabelle im Abschnitt Arbeitslasten, Anforderungen und Abhängigkeiten dieses Dokuments und fügt Informationen zu den GKE Enterprise-Zielressourcen hinzu, in denen Sie sie verwenden können.
Quell-OpenShift-Ressourcenmanifest | Die wichtigsten Spezifikationen und Parameter | GKE Enterprise-Zielressourcenmanifest |
---|---|---|
Deployment, DeploymentConfig, StatefulSet, Job, Cronjob | Container-Image und -Repository, Containerport, Anzahl der Pod-Replikate, ConfigMaps, Secrets, PersistentVolumeClaims, Ressourcenanfragen und -limits, Aktualisierungsstrategie, StatefulSet-Service-Name, Cronjob-Zeitplan | Deployment, StatefulSet, Job, Cronjob |
ImageStream | Container-Image, Image-Pull-Richtlinie, Container-Image-Repository | Deployment |
Horizontales Pod-Autoscaling | Autoscaling-Kriterien | Horizontales Pod-Autoscaling |
Service | Hostname, der zur Verbindung mit der Anwendung von innerhalb des Clusters verwendet wird, IP-Adresse und Port, auf denen der Service bereitgestellt wird, sowie für externe Ressourcen erstellte Endpunkte | Service |
Route | Hostname und Ressourcenpfad, der zum Herstellen einer Verbindung von außerhalb des Clusters mit der Anwendung verwendet wird, Routingregeln | Ingress |
Automatisierten Bereitstellungsprozess entwerfen und implementieren
Um Ihre Arbeitslasten automatisch zu erstellen und bereitzustellen, entwerfen und implementieren Sie Build- und Bereitstellungsprozesse oder passen Sie die vorhandenen Prozesse so an, dass Ihre neue Umgebung unterstützt wird. Wenn Sie Ihre Arbeitslasten in einer Hybridumgebung bereitstellen müssen, ist es erforderlich, dass die Bereitstellungsprozesse sowohl GKE in Google Cloud als auch GKE on VMware unterstützen.
Für die Implementierung Ihrer Build- und Bereitstellungsprozesse können Sie Cloud Build verwenden. Wenn Sie Build- und Bereitstellungsprozesse automatisieren möchten, können Sie Build-Trigger oder GitHub-App-Trigger konfigurieren oder automatische Bereitstellungen aus der Google Cloud Console einrichten. Wenn Sie Richtliniencontroller-Einschränkungen verwenden, können Sie Ihre Kubernetes- und GKE Enterprise-Deskriptoren mit Richtlinien in Ihren Cloud Build-Jobs vergleichen, um Entwicklern Feedback zu geben.
Wenn Sie Build-Jobs oder Quellcode lokal speichern müssen, können Sie GitLab verwenden. GitLab bietet Quellcode-Repositories, eine Plattform zur Zusammenarbeit, CI/CD-Funktionen und eine Container-Image-Registry. Sie können GitLab auf Ihren GKE Enterprise-Clustern direkt aus Cloud Marketplace bereitstellen oder eine der anderen verfügbaren Installationsoptionen verwenden.
Wenn Sie derzeit eine der OpenShift-Funktionen zum Erstellen oder automatischen Bereitstellen Ihrer Arbeitslasten verwenden, können Sie basierend auf Ihrem aktuellen Prozess eine der folgenden Strategien anwenden:
- Jenkins-Pipelines: Wenn Sie Jenkins-Pipelines zur Automatisierung Ihres Build- und Bereitstellungsprozesses verwenden, können Sie Ihre Pipeline zu Cloud Build portieren, Ihre vorhandene Jenkins-Umgebung verwenden oder Jenkins in Google Cloud bereitstellen.
- Builds und Deployments aus einem Dockerfile und den erforderlichen Artefakten: Sie können Cloud Build zum Erstellen von Container-Images mit einem Dockerfile oder einer Build-Konfigurationsdatei verwenden. Wenn Sie Ihre Builds in einem lokalen Cluster ausführen möchten, können Sie GitLab verwenden.
- Quelle-zu-Image-Builds: In Cloud Build müssen Sie einen vorbereitenden Schritt implementieren, um die Artefakte zu erstellen, die das resultierende Container-Image benötigt. Wenn Ihr Quelle-zu-Image-Job eine Python-Anwendung erstellt und ein Container-Image erzeugt, müssen Sie einen benutzerdefinierten Build-Schritt konfigurieren, um die Python-Anwendung und dann das Container-Image zu erstellen. Dieser Ansatz erfordert auch die Bereitstellung eines Dockerfile. Wenn Sie kein Dockerfile bereitstellen möchten, können Sie Buildpacks von Google Cloud oder Jib für Java-Anwendungen verwenden.
- Benutzerdefinierte Builds: Sie können wie bereits in OpenShift benutzerdefinierte Cloud Build-Builder erstellen. Wenn Ihre benutzerdefinierten Builder keine OpenShift-spezifischen Features verwenden, können Sie diese möglicherweise wie in Cloud Build verwenden.
Unabhängig davon, wie Sie Ihre Container-Images erstellen, müssen Sie sie in einem Container-Image-Repository speichern. Sie haben folgende Möglichkeiten:
- Vorhandenes Container-Image-Repository behalten: Wenn Sie ein externes Container-Image-Repository verwenden, das nicht auf OpenShift ausgeführt wird, und Sie noch nicht für die Migration bereit sind, können Sie dieses Repository weiterhin zum Speichern Ihrer Container-Images verwenden.
- Container Registry: Wenn Sie einen vollständig verwalteten Dienst bevorzugen, können Sie Ihre Container-Images mit Container Registry speichern. Wenn Sie zusätzliche Sicherheitsebenen benötigen, können Sie die Container Registry-Verschlüsselungsschlüssel selbst verwalten, einen sicheren Perimeter für den Zugriff auf Container Registry konfigurieren, die Sicherheit Ihrer Softwarelieferkette erhöhen und die Container-Images auf bekannte Sicherheitslücken scannen, wobei Sie Artefaktanalyse verwenden. Container Registry unterstützt auch verwaltete Basis-Images, die von Google als Basis für Ihre Container-Images verwaltet werden.
- Lokales Repository: Wenn Sie von Ihrem aktuellen Repository migrieren müssen, weil es auf OpenShift gehostet wird, und Ihre Container-Images lokal speichern müssen, können Sie die mit GitLab bereitgestellte Registry auswählen.
- Hybridansatz: Sie können die vorherigen Optionen kombinieren, um von den jeweiligen Vorteilen zu profitieren. Sie können beispielsweise Container Registry als Ihr Haupt-Repository verwenden und in Ihr lokales Repository spiegeln. In diesem Fall verwenden Sie Container Registry-Features und profitieren trotzdem von einem lokalen Repository.
Unabhängig von Ihrer Wahl zum Speichern von Container-Images müssen Sie Anmeldedaten für Ihre Cluster bereitstellen und konfigurieren, um auf das Container-Image-Repository zuzugreifen.
Wenn Sie Benachrichtigungen über den Status Ihrer Builds und Ihrer Container-Images an Nutzer oder Drittanbieterdienste senden möchten, können Sie Cloud Functions verwenden, um auf Ereignisse von Cloud Build und Container Registry zu reagieren.
Zusammenfassung der Funktionszuordnung von OpenShift zu GKE Enterprise
Die folgende Tabelle enthält eine Zusammenfassung darüber, wie Sie GKE Enterprise-Funktionen denjenigen Funktionen zuordnen, die Sie in OpenShift verwendet haben.
OpenShift | GKE Enterprise |
---|---|
OpenShift-Projekte |
|
OpenShift SDN und Netzwerkisolation |
|
OpenShift-Sicherheitskontextbeschränkungen |
|
OpenShift-Pipelines |
|
Quelle-zu-Image in OpenShift |
|
Integration von Identitäten |
|
Umgebung optimieren
Die Optimierung ist die letzte Phase Ihrer Migration. In dieser Phase machen Sie Ihre Umgebung effizienter als zuvor. Sie führen mehrere Iterationen einer wiederholbaren Schleife aus, bis Ihre Umgebung Ihre Optimierungsanforderungen erfüllt. Die Schritte dieser wiederholbaren Schleife sind folgende:
- Aktuelle Umgebung, Teams und Optimierungsschleife bewerten
- Optimierungsanforderungen und -ziele festlegen
- Umgebung und Teams optimieren
- Optimierungsschleife verbessern
Die folgenden Abschnitte basieren auf dem Dokument Migration zu Google Cloud: Umgebung optimieren.
Aktuelle Umgebung, Teams und Optimierungsschleife bewerten
Die erste Bewertung bezieht sich auf die Migration von Ihrer aktuellen Umgebung zu GKE Enterprise, und diese Bewertung ist auf die Optimierungsphase zugeschnitten.
Optimierungsanforderungen festlegen
Informationen zu den Optimierungsanforderungen für GKE on Google Cloud finden Sie unter Umgebung optimieren.
Prüfen Sie die folgenden Optimierungsanforderungen für Ihre GKE Enterprise-Umgebung:
- Arbeitslasten in einer serverlosen Umgebung bereitstellen: Wenn Sie Ihre operativen Teams entlasten möchten, können Sie vollständig verwaltete serverlose Plattformen wie Cloud Run und Knative Serving verwenden.
- Bereitstellungsprozesse modernisieren: Unter Migration zu Google Cloud: Arbeitslasten bereitstellen werden typische End-to-End-Bereitstellungsprozesse und die Modernisierung vorhandener Prozesse beschrieben. Wenn Sie Ihre vorhandenen Bereitstellungsprozesse modernisieren oder neue entwerfen möchten, finden Sie weitere Informationen unter Migration zu Google Cloud: Manuelle Bereitstellungen zu automatisierten, containerisierten Bereitstellungen migrieren.
- Mit Spinnaker bereitstellen: Wenn Sie Bereitstellungslogik wie Canary-Bereitstellungen und Blau/Grün-Bereitstellungen implementieren müssen, um die Zuverlässigkeit Ihrer Umgebung zu erhöhen und die Auswirkungen für Ihre Nutzer zu reduzieren, können Sie Spinnaker verwenden. Wenn Sie Spinnaker in Google Cloud verwenden möchten, müssen Sie es installieren. Danach implementieren Sie Ihre Bereitstellungsprozesse mit Spinnaker. Sie können beispielsweise Ihre bestehenden GKE-Cluster in Spinnaker registrieren, die Kustomize-Unterstützung für Spinnaker aktivieren oder Continuous Delivery-Pipelines mit Spinnaker und GKE implementieren.
- Sichere Software-Lieferkette implementieren: Bei sicherheitskritischen Arbeitslasten können Sie mithilfe der Binärautorisierung eine sichere Softwarelieferkette in Ihren GKE Enterprise-Clustern implementieren.
- Zum Cloud Service Mesh wechseln. Wenn Sie bereits OpenShift Service Mesh verwenden oder nach den Traffic-Management-, Beobachtbarkeits- und Sicherheitsfunktionen eines Service Mesh suchen, können Sie Cloud Service Mesh verwenden. Cloud Service Mesh bietet eine von GKE Enterprise erprobte und unterstützte Distribution von Istio sowie von Google verwaltete Backend-Funktionen für die Beobachtbarkeit, die mTLS-Zertifikatsverwaltung und die Einbindung in Identity Aware Proxy (IAP).
Optimierung abschließen
Nachdem Sie die Liste Ihrer Optimierungsanforderungen erstellt haben, schließen Sie die restlichen Aktivitäten der Optimierungsphase unter Migration zu Google Cloud: Umgebung optimieren ab.
Hilfe
Google Cloud bietet verschiedene Optionen und Ressourcen, mit denen Sie Google Cloud-Dienste optimal nutzen können.
- Ressourcen zur Selbsthilfe: Wenn Sie keinen persönlichen Support benötigen, stehen Ihnen verschiedene Optionen zur Verfügung, die Sie in Ihrem eigenen Tempo verwenden können.
- Technologiepartner: Google Cloud arbeitet mit mehreren Unternehmen zusammen, um Ihnen bei der Nutzung unserer Produkte und Dienste Unterstützung bieten zu können.
- Professionelle Dienstleistungen von Google Cloud: Mit unseren Dienstleistungen können Sie Ihre Investitionen in Google Cloud optimal nutzen.
Weitere Informationen zur Migration von Arbeitslasten zu Google Cloud erhalten Sie im Google Cloud-Migrationscenter.
Weitere Informationen zu diesen Ressourcen finden Sie im Abschnitt "Hilfe" von Migration zu Google Cloud: Einstieg.
Nächste Schritte
- Migration zu Google Cloud: Einstieg
- Mehr über GKE Enterprise und Migrate to Containers erfahren.
- Mehr zur Migration mit der Istio-Mesh-Erweiterung erfahren
- Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center