Cloud Run-alternatieven op STACKIT

Een Cloud Run-service, omgezet

Een kleine omgeving die voor deze pagina is geschreven en op 4 november 2026 door StackToIT is beoordeeld. Links: de invoer. Rechts: de resourceblokken van de STACKIT-Terraform die de engine schreef; de reviewcommentaren boven elk blok in het bestand zijn hier weggelaten.

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

• Eén cluster voor de containerworkloads

  De code schrijft één SKE-cluster dat de gemigreerde Cloud Run-services draait als Deployments, Jobs en CronJobs. Heeft de omgeving al een SKE-cluster, dan kan uw architect ze daar laten draaien.

• De serviceinstellingen, benoemd voor de Deployment

  De poorten, omgevingsvariabelen en resourcelimieten, de concurrency van 80 en de time-out van 30 seconden worden in de code genoemd voor de Deployment en Service die u schrijft.

• De grootte van de pool bepaalt u

  Machinetype en het minimum en maximum van de nodepool zijn variabelen, zodat u het cluster dimensioneert voor alle services die het samen host.

De beslissing erachter

Het eenheidsresultaat uit dezelfde run, precies zoals assessment.json het vastlegt.

{
  "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

  De service draait al een containerimage, dus die verhuist als Deployment op SKE, of als Cloud Foundry-app vanuit het image.

• Terugschalen naar nul

  Scale-to-zero krijgt u met Knative of KEDA, beheerd op SKE. Zonder zo’n autoscaler draait minstens één replica.

• Publieke aanroep

  De service staat allUsers toe de service aan te roepen. De code bevat geen controle op aanroep, dus u beslist bewust welke endpoints publiek blijven.

Het runtime-service account, omgezet

Uit dezelfde run. Links: de invoer. Rechts: de resourceblokken die StackToIT schreef; de reviewcommentaren boven elk blok in het bestand zijn hier weggelaten.

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

• Dezelfde naam, nieuw adres

  checkout-api wordt een STACKIT-service account met dezelfde naam. STACKIT genereert het e-mailadres, dus de code geeft aan dat u elke verwijzing naar het oude adres moet bijwerken.

• Identiteit van de workload

  De run vraagt hoe de workload op STACKIT aan zijn identiteit komt, via een eigen service account of workload federation, omdat de service het account in zijn template noemde.

Hoe de Cloud Run-omgeving wordt gekoppeld

Klassen zoals de run ze bepaalde. Images worden van registry naar registry gekopieerd met tools als skopeo of crane, en imageverwijzingen veranderen naar de nieuwe host; de registry wordt ingericht via het STACKIT-portaal of de API.

Vragen die applicatieteams stellen

Bronnen

• Google Cloud-documentatie: wat is Cloud Run?
• STACKIT-documentatie: Kubernetes Engine (SKE)
• STACKIT-documentatie: Cloud Foundry