De complete migratiegids van Google Cloud naar STACKIT

De migratie in tien stappen

Waar de run het antwoord bevat, noemt de stap het bestand. Stappen die als praktijk zijn aangemerkt, zijn algemeen advies en geen uitvoer van de run.

1. 01

   1. Verzamel de Terraform-code en zet de provider vast

   Verzamel de rootmodules van elk project en leg de .terraform.lock.hcl vast in versiebeheer. In de voorbeeldruns beperkt een Google-provider zonder lockbestand elke eenheid tot zekerheidsniveau MEDIUM. De bron kan dan ook niet met OpenTofu worden gevalideerd, omdat de validatie zonder lockbestand nooit een provider installeert.

2. 02

   2. Voer het assessment uit

   Voer stacktoit assess ./gcp-terraform uit. Het leest Terraform- en OpenTofu-rootmodules die de Google-provider gebruiken en maakt geen verbinding met een Google Cloud-project.

3. 03

   3. Lees de resultaten in volgorde

   Open eerst index.html, daarna assessment.json voor de klasse en de reden van elke eenheid, decisions.json en de invoertemplates voor openstaande keuzes, en tot slot target-plan.json, terraform/ en execution/.

4. 04

   4. Ontwerp de landing zone

   Bepaal hoe folders en projecten worden gekoppeld en of een Shared VPC een Network Area wordt. De run deelt de Shared VPC-koppeling in als redesign.

5. 05

   5. Bouw het netwerk opnieuw op

   Subnetworks worden STACKIT-netwerken en firewallregels worden security groups. Deny-regels, tagselectors en een vast NAT-adres vergen beslissingen.

6. 06

   6. Verplaats compute en containers

   GKE wordt SKE, Compute Engine wordt Compute Engine, en Cloud Run en Cloud Functions worden workloads op SKE of Cloud Foundry-apps.

7. 07

   7. Plan de data

   Cloud SQL gaat naar PostgreSQL Flex, MariaDB of SQLServer Flex; Cloud Storage naar Object Storage. BigQuery, Spanner en Bigtable vergen een ontwerp, geen kopie.

8. 08

   8. Vertaal identiteit en secrets

   Service accounts worden STACKIT-service accounts en secrets worden opnieuw aangemaakt in Secrets Manager. GKE Workload Identity wordt niet als zodanig overgenomen: de run verwijst naar een STACKIT-service account met een federatieve identiteitsprovider die de issuer van het SKE-cluster vertrouwt, aangemaakt per Kubernetes-service account.

9. 09

   9. Vul de beslissingen in en voer opnieuw uit

   Beantwoord inputs-template.yaml en decisions-template.yaml en voer opnieuw uit met --inputs en --decisions. Invoer kan het concept wijzigen; een vastgelegde beslissing op zichzelf herschrijft de Terraform niet. Controleer daarom na elke wijziging het nieuwe uitvoeringsplan.

10. 10

    10. Kopiëren, cutover, verifiëren (praktijk)

    Kies per data-eenheid een mechanisme voor de dataverplaatsing, spreek vensters af, schakel de afnemers over, verifieer en bewaar de bron tot de acceptatie. De run noemt de eenheden en de beslissingen; mensen en tools verplaatsen de data.

De service map

De samengestelde koppeling die StackToIT op Google Cloud toepast, met de klasse die er gewoonlijk bij hoort. De klasse van een concrete resource hangt af van de configuratie en staat in uw run.

De verdiepende pagina’s van deze gids behandelen netwerk, landing zones, Cloud Functions, Cloud Run, Cloud SQL en GKE.

Een GKE-cluster, omgezet

Uit de bestaande GKE-run op een omgeving die voor deze pagina’s is geschreven en op 4 november 2026 door StackToIT is beoordeeld: een regionaal cluster met Workload Identity en een node pool. Links: het cluster uit de invoer. Rechts: het blok STACKIT-Terraform dat de run schreef; de reviewcommentaren boven het blok zijn hier weggelaten.

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
  }
}

• De versie wordt verhoogd, niet gekopieerd

  De bron draait Kubernetes 1.32. Het concept zet kubernetes_version_min op 1.36, vier minorversies hoger, en geeft aan dat u manifests en Helm-charts op verwijderde API’s moet controleren voordat u verhuist.

• Release channels bestaan niet

  SKE kent geen release channels; automatische updates zijn een onderhoudsinstelling.

• Netwerk en identiteit laat het concept aan u over

  Het cluster wordt niet in een gegenereerd netwerk geplaatst: zonder netwerk in een Network Area maakt SKE een eigen netwerk voor het cluster. Ook de Google workload pool wordt niet overgenomen. Beide worden in het bestand genoemd.

Wat de voorbeeldruns u vertellen

Cijfers uit de runs op de voorbeeldomgevingen van deze pagina’s, niet uit uw omgeving.

• Kubernetes verhuist

  Een GKE-omgeving van 4 eenheden leverde een concept voor een SKE-cluster, een netwerk en een service account op, zonder eenheid die aan de architect is overgelaten.

• Databases veranderen van vorm

  Cloud SQL voor PostgreSQL wordt gekoppeld aan PostgreSQL Flex en een MySQL-instance aan STACKIT MariaDB. Databases die alleen een privé-IP hebben, kennen geen tegenhanger, dus het bereik van het endpoint wordt een beslissing.

• Serverless wordt platformwerk

  Een Cloud Run-service en een Cloud Function worden beide gekoppeld aan CONTAINERIZE: het image of de code verhuist en het platform eromheen wordt als concept geschreven.

• Het netwerk vergt de meeste beslissingen

  In het netwerkvoorbeeld is de egress-deny-regel een redesign en wordt een vast NAT-adres niet behouden.

Beslissingen die de architect neemt

Openstaande punten die in de runs op al deze omgevingen terugkomen.

• Project- en foldermapping

  Het concept plaatst alles in één project en één regio. Bepaal de werkelijke indeling voordat u apply uitvoert.

• Plaatsing van het cluster

  Het SKE-cluster wordt niet in een gegenereerd netwerk geplaatst. Bepaal of het deel gaat uitmaken van een Network Area.

• Grootte van node pools

  GKE telt het minimum en maximum van een node pool per zone, SKE telt de hele pool. De GKE-run neemt geen waarde over als gelijkwaardig en vraagt u de totalen van de pool in te stellen.

• Bereikbaarheid van databases

  Bepaal het bereik van het endpoint en de toegestane ranges voor elke database die op Google Cloud privé was. Blijft dit leeg, dan maakt de STACKIT API het endpoint openbaar. Noem de clients dus in de variabele voor toegestane ranges voordat u apply uitvoert.

• Mechanisme voor dataverplaatsing

  De run legt elke data-eenheid vast als beslissing zonder gekozen mechanisme. Kies er per eenheid één, met een downtimetolerantie en een recovery point.

• Identiteitsmodel

  Bepaal wie elk STACKIT-service account mag gebruiken en hoe workloads zich authenticeren zonder metadata server.

• Redesign-eenheden

  Bepaal voor BigQuery, Spanner en Bigtable eerst het doelontwerp; de indeling als REDESIGN betekent dat geen geautomatiseerd concept daarvoor in de plaats komt.

Vragen van migratieleiders

Bronnen

• Google Cloud: Shared VPC
• STACKIT Docs: Kubernetes Engine (SKE)
• STACKIT Docs: Cloud Foundry
• STACKIT Docs: PostgreSQL Flex
• STACKIT Docs: concepten van Network Area