Cloud-Run-Alternativen auf STACKIT

Ein Cloud-Run-Dienst, umgewandelt

Eine kleine Umgebung, für diese Seite geschrieben und am 4. November 2026 von StackToIT bewertet. Links die Eingabe, rechts die Ressourcenblöcke des STACKIT-Terraforms, das die Engine geschrieben hat; die Prüfkommentare über jedem Block in der Datei sind hier ausgelassen.

resource "google_cloud_run_v2_service" "checkout" {
  name     = "checkout-api"
  location = "europe-west3"
  ingress  = "INGRESS_TRAFFIC_ALL"

  template {
    service_account                  = google_service_account.api.email
    max_instance_request_concurrency = 80
    timeout                          = "30s"

    scaling {
      min_instance_count = 1
      max_instance_count = 20
    }

    containers {
      image = "europe-west3-docker.pkg.dev/shop-web-prod/images/checkout-api:1.8.2"

      ports {
        container_port = 8080
      }

      resources {
        limits = {
          cpu    = "2"
          memory = "1Gi"
        }
      }

      env {
        name  = "LOG_LEVEL"
        value = "info"
      }
    }
  }
}

resource "stackit_ske_cluster" "containers" {
  project_id = var.project_id
  name       = "containers"
  node_pools = [{
    name               = "workloads"
    machine_type       = var.containers_machine_type
    minimum            = var.containers_nodes_min
    maximum            = var.containers_nodes_max
    availability_zones = var.availability_zones
  }]
}

• Ein Cluster für die Container-Workloads

  Der Code schreibt einen SKE-Cluster, der die migrierten Cloud-Run-Dienste als Deployments, Jobs und CronJobs ausführt. Hat die Umgebung schon einen SKE-Cluster, kann Ihr Architekt sie stattdessen dort betreiben.

• Die Dienst-Einstellungen, benannt für das Deployment

  Ports, Umgebungsvariablen und Ressourcenlimits, die Concurrency von 80 und das Timeout von 30 Sekunden benennt der Code für das Deployment und den Service, die Sie schreiben.

• Die Pool-Größe bestimmen Sie

  Maschinentyp sowie Minimum und Maximum des Node Pools sind Variablen; Sie bemessen den Cluster daher für alle Dienste, die er gemeinsam trägt.

Die Entscheidung dahinter

Das Ergebnis der Einheit aus demselben Lauf, genau so, wie assessment.json es festhält.

{
  "id": "google_cloud_run_v2_service.checkout",
  "class": "CONTAINERIZE",
  "confidence": "MEDIUM",
  "target": {
    "service": "SKE workload (or Cloud Foundry Docker app)"
  },
  "reason": "The service already runs a container image, so it moves as a Deployment on SKE (or a Cloud Foundry app from the image). Scale-to-zero and per-request billing go away unless Knative or KEDA is operated on SKE."
}

• CONTAINERIZE

  Der Dienst läuft bereits als Container-Image; er zieht daher als Deployment auf SKE um oder als Cloud-Foundry-App aus dem Image.

• Skalieren auf null

  Scale-to-Zero kommt mit Knative oder KEDA, die auf SKE betrieben werden. Ohne einen solchen Autoscaler läuft mindestens eine Replika.

• Öffentlicher Aufruf

  Der Dienst erlaubt allUsers den Aufruf. Der Code übernimmt keine Aufrufprüfung; entscheiden Sie daher bewusst, welche Endpunkte öffentlich bleiben.

Der Laufzeit-Service-Account, umgewandelt

Aus demselben Lauf. Links die Eingabe, rechts die Ressourcenblöcke, die StackToIT geschrieben hat; die Prüfkommentare über jedem Block in der Datei sind hier ausgelassen.

resource "google_service_account" "api" {
  account_id   = "checkout-api"
  display_name = "Checkout API runtime"
}

resource "stackit_service_account" "api" {
  project_id = var.project_id
  name       = "checkout-api"
}

• Gleicher Name, neue Adresse

  checkout-api wird zu einem STACKIT Service Account mit demselben Namen. STACKIT erzeugt seine E-Mail-Adresse; der Code fordert daher, jeden Verweis auf die alte anzupassen.

• Identität des Workloads

  Der Lauf fragt, wie der Workload auf STACKIT seine Identität erhält, über einen eigenen Service Account oder per Workload-Föderation, denn der Dienst hat das Konto in seinem Template benannt.

So wird die Cloud-Run-Umgebung zugeordnet

Klassen so, wie der Lauf sie entschieden hat. Images werden mit Werkzeugen wie skopeo oder crane von Registry zu Registry kopiert, und Image-Verweise wechseln auf den neuen Host; die Registry wird über das STACKIT-Portal oder die API eingerichtet.

Fragen aus Anwendungsteams

Quellen

• Google-Cloud-Dokumentation: Was ist Cloud Run?
• STACKIT-Dokumentation: Kubernetes Engine (SKE)
• STACKIT-Dokumentation: Cloud Foundry