Container zu Google Cloud migrieren: Von OpenShift zu GKE Enterprise migrieren

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:

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
  • Anthos 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
  • Cloud Run for Anthos 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:

  1. Arbeitslasten bewerten und erkennen
  2. Grundlagen planen und aufbauen
  3. Arbeitslasten bereitstellen
  4. Umgebung optimieren

Die folgende Grafik veranschaulicht den Migrationsprozess:

Migrationspfad mit vier Phasen

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:

  1. Erstellen Sie ein umfassendes Inventar Ihrer Abläufe und Anwendungen.
  2. Katalogisieren Sie Ihre Abläufe und Anwendungen entsprechend ihren Eigenschaften und Abhängigkeiten.
  3. Bereiten Sie die Teams auf Google Cloud vor.
  4. Erstellen Sie Tests und Proofs of Concept in Google Cloud.
  5. Berechnen Sie die Gesamtbetriebskosten (TCO) der Zielumgebung.
  6. 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:

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:

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:

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 ihnen zugewiesenen Nutzer, Gruppen und Dienstkonten.
  • 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:

  1. Erstellen Sie eine Ressourcenhierarchie.
  2. Konfigurieren Sie die Identitäts- und Zugriffsverwaltung.
  3. Richten Sie die Abrechnung ein.
  4. Richten Sie die Netzwerkverbindung ein.
  5. Erhöhen Sie die Sicherheit.
  6. 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 VM-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:

Arbeitslasten bereitstellen

In der Bereitstellungsphase stellen Sie Ihre Arbeitslasten auf GKE Enterprise bereit:

  1. Stellen Sie Laufzeitplattform und -umgebungen bereit und konfigurieren Sie sie.
  2. Migrieren Sie Daten aus der alten Umgebung in die neue.
  3. 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 einige GKE Enterprise-Cluster mehr erforderlich, als die Anzahl Ihrer OpenShift-Cluster beträgt, da dies Ihren Entwicklerteams maximale Flexibilität und Isolation ermöglicht.

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:

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:

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:

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, 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:

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 Ziel-GKE Enterprise-Ressourcenmanifest
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:

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
  • Kubernetes-Namespaces, die zentral von Config Sync verwaltet werden
  • Kubernetes-RBAC-Autorisierung, die zentral von Config Sync verwaltet wird
  • Kubernetes-Ressourcenkontingente, die zentral von Config Sync verwaltet werden
OpenShift SDN und Netzwerkisolation
  • Calico-Netzwerksicherheitsrichtlinien, die zentral von Config Sync verwaltet werden
OpenShift-Sicherheitskontextbeschränkungen
  • Policy Controller-Einschränkungen
OpenShift-Pipelines
  • Cloud Build
  • Jenkins-Integration mit dem Google Cloud-Jenkins-Plug-in
  • GitLab
Quelle-zu-Image in OpenShift
  • Cloud Native Buildpacks
  • Jib
Integration von Identitäten
  • Cloud Identity
  • Google Cloud Directory Sync
  • GKE on VMware: OIDC-Einbindung

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:

  1. Aktuelle Umgebung, Teams und Optimierungsschleife bewerten
  2. Optimierungsanforderungen und -ziele festlegen
  3. Umgebung und Teams optimieren
  4. 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:

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