Der vollständige Leitfaden für die Migration von Google Cloud zu STACKIT

Die Migration in zehn Schritten

Wo der Lauf die Antwort enthält, nennt der Schritt die Datei. Schritte mit dem Vermerk „Praxis“ sind allgemeine Hinweise, keine Ausgabe des Laufs.

1. 01

   1. Terraform sammeln und den Provider festlegen

   Sammeln Sie die Root-Module aller Projekte und committen Sie die .terraform.lock.hcl. In den Beispielläufen begrenzt ein Google-Provider ohne Lock-Datei jede Einheit auf mittlere Konfidenz, und die Quelle lässt sich nicht mit OpenTofu validieren, weil die Validierung ohne Lock-Datei keinen Provider installiert.

2. 02

   2. Die Bewertung starten

   Führen Sie stacktoit assess ./gcp-terraform aus. Es liest Terraform- und OpenTofu-Root-Module, die den Google-Provider nutzen, und verbindet sich nicht mit einem Google-Cloud-Projekt.

3. 03

   3. Die Ergebnisse der Reihe nach lesen

   Öffnen Sie zuerst index.html, dann assessment.json für Klasse und Begründung jeder Einheit, decisions.json und die Eingabevorlagen für offene Entscheidungen, danach target-plan.json, terraform/ und execution/.

4. 04

   4. Die Landing Zone entwerfen

   Legen Sie fest, wie Ordner und Projekte abgebildet werden und ob eine Shared VPC zur Network Area wird. Der Lauf stuft die Shared-VPC-Verbindung als Redesign ein.

5. 05

   5. Das Netzwerk neu aufbauen

   Subnetze werden zu STACKIT-Netzwerken, Firewall-Regeln zu Security Groups. Deny-Regeln, Tag-Selektoren und eine feste NAT-Adresse brauchen Entscheidungen.

6. 06

   6. Compute und Container umziehen

   GKE wird zu SKE, Compute Engine zu Compute Engine, und Cloud Run und Cloud Functions werden zu Workloads auf SKE oder zu Cloud-Foundry-Apps.

7. 07

   7. Die Daten planen

   Cloud SQL zieht nach PostgreSQL Flex, MariaDB oder SQLServer Flex um, Cloud Storage nach Object Storage. BigQuery, Spanner und Bigtable brauchen ein Design, keine Kopie.

8. 08

   8. Identität und Secrets übersetzen

   Service Accounts werden zu STACKIT-Service-Accounts; Secrets legen Sie im Secrets Manager neu an. GKE Workload Identity wird nicht direkt übernommen: Der Lauf verweist auf einen STACKIT-Service-Account mit föderiertem Identity Provider, der dem Issuer des SKE-Clusters vertraut, angelegt je Kubernetes-Service-Account.

9. 09

   9. Entscheidungen eintragen und neu laufen lassen

   Beantworten Sie inputs-template.yaml und decisions-template.yaml und starten Sie den Lauf erneut mit --inputs und --decisions. Eingaben können den Entwurf ändern; eine erfasste Entscheidungsprüfung allein schreibt das Terraform nicht um. Prüfen Sie nach jeder Änderung den neuen Ausführungsplan.

10. 10

    10. Kopieren, umstellen, prüfen (Praxis)

    Wählen Sie je Dateneinheit einen Mechanismus für den Datenumzug, vereinbaren Sie Zeitfenster, stellen Sie die Verbraucher um, prüfen Sie und behalten Sie die Quelle bis zur Abnahme. Der Lauf führt Einheiten und Entscheidungen auf; übertragen wird von Menschen und Werkzeugen.

Die Dienstezuordnung

Die kuratierte Zuordnung, die StackToIT auf Google Cloud anwendet, mit der üblichen Klasse. Die Klasse einer konkreten Ressource hängt von ihrer Konfiguration ab und steht in Ihrem Lauf.

Die vertiefenden Seiten dieses Leitfadens behandeln Netzwerk, Landing Zones, Cloud Functions, Cloud Run, Cloud SQL und GKE.

Ein GKE-Cluster, umgewandelt

Aus dem vorhandenen GKE-Lauf über eine für diese Seiten geschriebene Umgebung, am 4. November 2026 von StackToIT bewertet: ein regionaler Cluster mit Workload Identity und einem Node-Pool. Links der Cluster der Eingabe, rechts der Block des STACKIT-Terraform-Codes aus dem Lauf; die Prüfkommentare über dem Block sind hier ausgelassen.

resource "google_container_cluster" "platform" {
  name                     = "platform"
  location                 = "europe-west3"
  network                  = google_compute_network.platform.id
  subnetwork               = google_compute_subnetwork.gke.id
  min_master_version       = "1.32"
  remove_default_node_pool = true
  initial_node_count       = 1
  deletion_protection      = true

  release_channel {
    channel = "REGULAR"
  }

  workload_identity_config {
    workload_pool = "shop-platform-prod.svc.id.goog"
  }
}

resource "stackit_ske_cluster" "platform" {
  project_id = var.project_id
  name       = "platform"
  node_pools = [{
    name               = "general"
    machine_type       = var.general_machine_type
    minimum            = var.platform_general_minimum
    maximum            = var.platform_general_maximum
    availability_zones = var.availability_zones
  }]
  kubernetes_version_min = "1.36"
  lifecycle {
    prevent_destroy = true
  }
}

• Die Version wird angehoben, nicht kopiert

  Die Quelle läuft mit Kubernetes 1.32. Der Entwurf setzt kubernetes_version_min auf 1.36, vier Minor-Versionen höher, und fordert Sie auf, Manifeste und Helm-Charts vor dem Umzug auf entfernte APIs zu prüfen.

• Release-Channels gibt es nicht

  SKE hat keine Release-Channels; automatische Updates sind eine Wartungseinstellung.

• Netzwerk und Identität bleiben bei Ihnen

  Der Cluster wird nicht in ein erzeugtes Netzwerk gelegt: Ohne Netzwerk aus einer Network Area legt SKE ein eigenes Cluster-Netzwerk an. Auch der Google-Workload-Pool wird nicht übernommen. Beides steht in der Datei.

Was die Beispielläufe zeigen

Zahlen aus den Läufen über die Beispielumgebungen dieser Seiten, nicht aus Ihrer Umgebung.

• Kubernetes zieht um

  Eine GKE-Umgebung mit 4 Einheiten ergab einen entworfenen SKE-Cluster, ein Netzwerk und einen Service Account, ohne dass eine Einheit dem Architekten überlassen blieb.

• Datenbanken ändern ihre Form

  Cloud SQL for PostgreSQL wird zu PostgreSQL Flex, eine MySQL-Instanz zu STACKIT MariaDB. Rein private Datenbanken haben kein Gegenstück, deshalb wird der Endpunktbereich zur Entscheidung.

• Serverless wird zur Plattformarbeit

  Ein Cloud-Run-Dienst und eine Cloud Function werden beide CONTAINERIZE: Image oder Code ziehen um, und die Plattform darum herum wird entworfen.

• Das Netzwerk braucht die meisten Entscheidungen

  Im Netzwerkbeispiel ist die Egress-Deny-Regel ein Redesign, und eine feste NAT-Adresse bleibt nicht erhalten.

Entscheidungen, die beim Architekten liegen

Offene Punkte, die in den Läufen aller dieser Umgebungen auftauchen.

• Projekt- und Ordnerzuordnung

  Der Entwurf legt alles in ein Projekt und eine Region. Legen Sie das echte Layout fest, bevor Sie anwenden.

• Platzierung des Clusters

  Der SKE-Cluster wird nicht in ein erzeugtes Netzwerk gelegt. Entscheiden Sie, ob er einer Network Area beitritt.

• Größe der Node-Pools

  GKE zählt Minimum und Maximum eines Node-Pools je Zone, SKE für den ganzen Pool. Der GKE-Lauf übernimmt keinen Wert als gleichwertig und lässt Sie die Gesamtzahlen festlegen.

• Erreichbarkeit der Datenbanken

  Legen Sie Endpunktbereich und erlaubte Adressbereiche für jede Datenbank fest, die auf Google Cloud privat war. Bleibt der Bereich offen, macht die STACKIT-API den Endpunkt öffentlich; tragen Sie die Clients deshalb vor dem Anwenden in die Variable der erlaubten Bereiche ein.

• Mechanismus für den Datenumzug

  Der Lauf führt jede Dateneinheit als Entscheidung ohne gewählten Mechanismus. Wählen Sie je Einheit einen, mit Ausfalltoleranz und Recovery-Punkt.

• Identitätsmodell

  Legen Sie fest, wer jeden STACKIT-Service-Account nutzen darf und wie sich Workloads ohne Metadatenserver authentifizieren.

• Redesign-Einheiten

  Für BigQuery, Spanner und Bigtable entscheiden Sie zuerst das Zieldesign; die Einstufung REDESIGN heißt, dass kein automatischer Entwurf es ersetzt.

Fragen von Migrationsverantwortlichen

Quellen

• Google Cloud: Shared VPC
• STACKIT-Dokumentation: Kubernetes Engine (SKE)
• STACKIT-Dokumentation: Cloud Foundry
• STACKIT-Dokumentation: PostgreSQL Flex
• STACKIT-Dokumentation: Network-Area-Konzepte