Der Migrationsprozess zu GKE

In diesem Thema wird die empfohlene Abfolge von Schritten beschrieben, die Sie beim Migrieren von Arbeitslasten zu GKE ausführen sollten.

Auf übergeordneter Ebene müssen Sie eine Erkennungs- und Bewertungsphase durchlaufen, in der Sie Ihre Arbeitslasten und Abhängigkeiten zwischen diesen identifizieren und feststellen, ob sie in die Cloud migriert werden können.

Als Nächstes nehmen Sie an einer Migrationsplanungsphase teil, in der Sie Ihre Arbeitslastflotte in Gruppen von Arbeitslasten aufteilen, die miteinander zusammenhängen und zusammen migrieren sollten (basierend auf dem Ergebnis der Bewertung) und dann die Reihenfolge der zu migrierenden Gruppen festlegen.

Darüber hinaus legen Sie fest, welche Arbeitslasten zu GKE migriert werden sollen und welche nicht für GKE geeignet sind, aber mit Migrate for Compute Engine zu Compute Engine migrieren können. Beachten Sie, dass Sie die Herausforderung der Migration von Arbeitslasten in zwei verschiedene Phasen unterteilen können, auch für Arbeitslasten, die für GKE geeignet sind:

  1. Migrieren Sie Arbeitslasten mit Migrate for Compute Engine zu Compute Engine.
  2. Migrieren Sie mit Migrate for Anthos von Compute Engine zu GKE.

Diese Methode ist beispielsweise sinnvoll, wenn Sie eine Rechenzentrumsmigration durchführen sowie alle Arbeitslasten in Compute Engine migrieren und nur in einer zweiten Phase geeignete Arbeitslasten zu GKE migrieren möchten. Wie im Diagramm dargestellt, müssen Sie, nachdem Sie den gewünschten Pfad für eine bestimmte Arbeitslast ausgewählt haben, eine Migrationseinrichtung der Landing Zone durchlaufen und anschließend Optimierungsphasen der Migration durchführen.

Die Schritte einer Migration zu VMs oder Containern mit Migrate for Anthos.

Erkennung

Erheben Sie die für eine Migration erforderlichen Informationen, indem Sie Ihre Anwendungen und ihre Abhängigkeiten verstehen. Dies umfasst ein Inventar von:

  • Den VMs, deren Arbeitslasten Sie migrieren möchten.
  • Erforderlichen Netzwerkports und -verbindungen Ihrer Anwendungen.
  • Abhängigkeiten zwischen App-Stufen.
  • Dienstnamenauflösung oder DNS-Konfiguration.

Roles

  • IT-Analyst mit Kenntnissen der Topologien und der Migration der Anwendung.

Planung der Migration

Unterteilen Sie Ihre Anwendungen in Batches und übersetzen Sie die während des Erkennungsschritts erfassten Informationen in das Kubernetes-Modell. Ihre Anwendungsumgebungen, Topologien, Namespaces und Richtlinien sind in Kubernetes-YAML-Konfigurationsdateien zentralisiert. Beispiel-YAML-Dateien sind verfügbar.

Rollen

  • Application Migration Engineer oder Analyst Diese Person benötigt Grundkenntnisse über das verwaltete Kubernetes-Objektmodell, GKE-Bereitstellungen und YAML-Dateien.

Einrichtung der Landing Zone

In diesem Schritt gehen Sie so vor:

  • Den GKE-Cluster zum Hosten der migrierten Arbeitslasten erstellen oder identifizieren
  • VPC-Netzwerkregeln und Kubernetes-Netzwerkrichtlinien für Ihre Anwendunge erstellen
  • Kubernetes-Dienstdefinitionen anwenden
  • Entscheidungen für Load-Balancing machen
  • DNS konfigurieren

Roles

  • GKE-Clusteradministrator, vertraut mit Clusterbereitstellung, Google Cloud-Netzwerken, Firewallregeln, Cloud Identity and Access Management-Dienstkonten und -Rollen und der Einführung von Bereitstellungen über den Google Cloud-Marktplatz.

Migration zu GKE und Validierung

Sobald Ihr GKE-Cluster, Ihr VPC-Netzwerk und die Migrate for Anthos-Komponenten Arbeitslasten verarbeiten können, können Sie den Migrationsworkflow von Migrate for Anthos für jede zu migrierende Quell-VM starten. Achten Sie darauf, die Kompatibilität der Quellarbeitslast und des Betriebssystems mit Migrate for Anthos anhand dieser Richtlinien zu bewerten. Der Migrationsworkflow ist im folgenden Diagramm dargestellt:

Diagramm mit einer Übersicht über die Einrichtungs- und Migrationsschritte.

Der Migrationsworkflow umfasst die folgenden fünf Schritte:

  1. Migrationsplan generieren und prüfen: Mit der Migrate for Anthos migctl-Befehlszeile für Linux-Arbeitslasten oder dem Migrationsskript für Windows-Arbeitslasten wird ein Migrationsplan erstellt, anschließend geprüft und mit den Eingaben von wichtigen Beteiligten wie dem Anwendungsinhaber, dem Sicherheitsadministrator, dem Storage-Administrator usw aktualisiert.
  2. Artefakte generieren: Verwenden Sie den Migrationsplan als Eingabe für die Befehlszeile, um die Quell-VM zu verarbeiten und die relevanten Artefakte zu erzeugen:
    • Für Linux-Arbeitslasten: Container-Image, Dockerfile, Referenz-Bereitstellungs-YAMLs und, falls für zustandsorientierte Arbeitslasten angegeben, ein Daten-Volume.
    • Für Windows-Arbeitslasten: Extrahierte Anwendungsdateien in einem ZIP-Archiv und ein Dockerfile. Hinweis: Sie müssen ein Container-Image mit dem Dockerfile und extrahierten Inhalten erstellen, bevor Sie mit dem nächsten Schritt fortfahren können.
  3. Test: Bevor Sie mit der Bereitstellung der Arbeitslast für die End-to-End-Validierung auf Anwendungsebene in einem Test-, Staging- oder Produktionscluster Ihrer Wahl fortfahren, sollten Sie prüfen, ob das extrahierte Container-Image und Daten-Volume (falls zutreffend) bei der Ausführung in einem Container korrekt funktioniert. Sie können einen Funktionalitätstest für den Verarbeitungscluster ausführen, Probleme oder Änderungen am Migrationsplan ermitteln, dann Schritt 2 wiederholen und den Test noch einmal durchführen.
  4. Datensynchronisierung: Wenn eine zustandsorientierte Arbeitslast migriert wird (nur Linux) und die Arbeitslast während der Ausführung an der Quelle weiterhin neue Daten und Status ansammelt, können Sie einen oder mehrere Datensynchronisierungszyklen durchlaufen, bevor Sie eine endgültige Datensynchronisierung mit dem Herunterfahren der Quelle durchführen. So können Sie die endgültige Ausfallzeit der Umstellung reduzieren. Bei jeder Datensynchronisierung werden nur die geänderten Daten seit dem letzten Datensynchronisierungszyklus übertragen.
  5. Mit CI/CD bereitstellen oder integrieren: Nachdem die Containerartefakte nun bereit und validiert sind, können Sie mit der Bereitstellung in einem Test-, Staging- oder Produktionscluster fortfahren. Alternativ können Sie die Artefakte verwenden, um sie mithilfe eines Orchestrierungstools wie Cloud Build in eine Build- und Bereitstellungspipeline zu integrieren.

Roles

  • Für die Arbeitslastmigration:
    • Anwendungseigentümer oder Anwendungsmigrations-Analyst mit Anfängerwissen über das verwaltete Objektmodell von Kubernetes, GKE-Deployments und YAML-Bearbeitung.
  • OPTIONAL: Für die Datenspeichermigration auf ein nichtflüchtiges Volume, das kein GCP-PD ist:
    • Speicheradministrator oder GKE-Administrator, vertraut mit nichtflüchtiger Kubernetes-Datenträgerverwaltung in GKE.

Betrieb und Optimierung

Sie können jetzt Tools von Anthos und dem größeren Kubernetes-Ökosystem nutzen. In diesem Schritt können Sie Zugriffsrichtlinien, Verschlüsselung und Authentifizierung mit Istio, Monitoring und Logging mit Cloud Logging und Cloud Monitoring hinzufügen, indem Sie die Konfiguration ändern und Ihre Anwendungen nicht neu erstellen. Sie können auch eine Integration in eine CI/CD-Pipeline mithilfe von Tools wie Cloud Build vornehmen, um Day-2-Wartungsverfahren wie Softwarepakete und Versionsupdates zu implementieren