Kubernetes-Migration zu STACKIT SKE, aus jeder von sechs Clouds

EKS: Cluster und Node Group werden zu einem SKE-Cluster

Eine für diesen Leitfaden geschriebene kleine Umgebung, von StackToIT am 4. November 2026 bewertet. Links der EKS-Cluster mit seiner Node Group. Rechts der Block stackit_ske_cluster des STACKIT-Terraforms, das die Engine geschrieben hat, ohne Review-Kommentare.

resource "aws_eks_cluster" "platform" {
  name     = "platform"
  version  = "1.31"
  role_arn = aws_iam_role.cluster.arn

  vpc_config {
    subnet_ids = [aws_subnet.private_a.id, aws_subnet.private_b.id]
  }
}

resource "aws_eks_node_group" "workloads" {
  cluster_name    = aws_eks_cluster.platform.name
  node_group_name = "workloads"
  node_role_arn   = aws_iam_role.nodes.arn
  subnet_ids      = [aws_subnet.private_a.id, aws_subnet.private_b.id]
  instance_types  = ["m6i.xlarge"]

  scaling_config {
    desired_size = 3
    min_size     = 2
    max_size     = 6
  }
}

resource "stackit_ske_cluster" "platform" {
  project_id = var.project_id
  name       = "platform"
  node_pools = [{
    name               = "workloads"
    machine_type       = var.pool_workloads_machine_type
    minimum            = 2
    maximum            = 6
    availability_zones = var.availability_zones
  }]
  kubernetes_version_min = "1.36"
}

• Aus Node Groups werden Node Pools

  Eine Node Group ist bei STACKIT keine eigene Ressource, sondern ein Node Pool im Cluster-Block. Minimum und Maximum werden übernommen, desired_size nicht, weil ein SKE-Pool zwischen seinen Grenzen skaliert und keine Wunschgröße kennt.

• Der Maschinentyp wird abgeleitet, nicht kopiert

  m6i.xlarge hat 4 vCPU und 16 GiB. Der Entwurf verweist den Pool auf eine Variable, deren Standardwert der STACKIT-Maschinentyp ist, den der Lauf für diese Größe vorschlägt; die Wahl bleibt als offene Entscheidung zur Bestätigung oder Änderung.

• Die Version steigt

  Die Quelle läuft mit Kubernetes 1.31. Der eu01-Katalog, den der Lauf gelesen hat, beginnt bei 1.35, seine Lifecycle-Daten führen aber 1.36 als niedrigste unterstützte Version auf oder über der Quellversion. Der Lauf setzt kubernetes_version_min daher auf 1.36 und warnt, dass zwischen beiden Upgrades über fünf Minor-Versionen liegen: Prüfen Sie vor dem Umzug entfernte APIs.

• Rollen und Subnetze entfallen, jeweils benannt

  Die Cluster-IAM-Rolle, die Node-Rolle und die Control-Plane-Subnetze haben bei SKE kein Gegenstück. Jedes steht in der Datei als nicht übernommen, mit der offenen Frage dazu: wofür die Node-Zugangsdaten genutzt wurden und welchem Netzwerk der Cluster beitritt.

GKE: Schutz, Skalierung und Identität werden anders abgebildet

Dieselbe Übung für einen Google-Kubernetes-Engine-Cluster mit Node Pool. Links die Eingabe, rechts der SKE-Block.

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 "google_container_node_pool" "general" {
  name     = "general"
  cluster  = google_container_cluster.platform.id
  location = "europe-west3"

  autoscaling {
    min_node_count = 1
    max_node_count = 5
  }

  node_config {
    machine_type    = "e2-standard-8"
    disk_size_gb    = 100
    service_account = google_service_account.nodes.email
    oauth_scopes    = ["https://www.googleapis.com/auth/cloud-platform"]
  }
}

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

• Löschschutz bleibt

  deletion_protection = true wird als Terraform-Schutz übernommen (lifecycle prevent_destroy); ein Destroy wird also wie bisher abgelehnt.

• Skalierungswerte ändern ihre Bedeutung

  Die Autoscaling-Grenzen von GKE zählen Knoten pro Zone; Minimum und Maximum bei SKE zählen den ganzen Pool. Der Lauf übernimmt keinen Wert als Entsprechung und vermerkt, dass die Pool-Summen zu setzen sind.

• Workload Identity wird nicht übernommen

  Der Google-Workload-Pool hat kein Gegenstück. Workloads föderieren über einen STACKIT-Identity-Provider für Service Accounts, der den Cluster-Issuer nutzt; der Lauf meldet das als Befund und erzeugt es nicht. Auch Release Channels entfallen: SKE kennt keine Channels, und automatische Versionsupdates sind eine Wartungseinstellung.

CCE, ACK und OKE: Der Cluster ist bewertet, die Details liegen bei Ihnen

Für Quellen aus Huawei Cloud, Alibaba Cloud und Oracle Cloud schreibt dieser Build keine STACKIT-Ressourcenblöcke, sondern hält die Entscheidung fest. Hier die Cluster-Einheiten, wie assessment.json sie führt (ID, Klasse, Konfidenz und Ziel).

{
  "id": "huaweicloud_cce_cluster.platform",
  "result": {
    "class": "REPLATFORM",
    "confidence": "MEDIUM",
    "target": {
      "service": "STACKIT Kubernetes Engine (SKE)",
      "resources": [
        "stackit_ske_cluster",
        "stackit_ske_kubeconfig"
      ]
    }
  }
}
{
  "id": "alicloud_cs_managed_kubernetes.platform",
  "result": {
    "class": "REPLATFORM",
    "confidence": "MEDIUM",
    "target": {
      "service": "STACKIT Kubernetes Engine (SKE)",
      "resources": [
        "stackit_ske_cluster",
        "stackit_ske_kubeconfig"
      ]
    }
  }
}
{
  "id": "oci_containerengine_cluster.platform",
  "result": {
    "class": "REPLATFORM",
    "confidence": "MEDIUM",
    "target": {
      "service": "STACKIT Kubernetes Engine (SKE)",
      "resources": [
        "stackit_ske_cluster",
        "stackit_ske_kubeconfig"
      ]
    }
  }
}

• Gleiche Klasse, gleiches Ziel

  Alle drei Cluster sind REPLATFORM mit Konfidenz MEDIUM und Ziel STACKIT Kubernetes Engine. Workload-Manifeste können bleiben; Node Pools, Annotationen für Load Balancer und Storage sowie die Identität werden ersetzt, ebenso die Add-ons (bei OKE nennt der Lauf stattdessen die Images).

• Node Pools sind uneinheitlich

  In diesen Demo-Läufen ist der OKE-Node-Pool REPLATFORM, während die Node Pools von CCE und ACK MANUAL_REVIEW mit Konfidenz LOW sind: Dieser Build kennt ihre Ressourcentypen nicht, daher wird nichts davon bewertet oder entworfen. Sie erscheinen als Arbeit für einen Architekten statt als stille Lücke.

Was sich je Quelle ändert

Aus den sechs Demo-Läufen dieser Leitfaden-Reihe. Der AKS-Clustername wird gekürzt, weil ein SKE-Clustername 1 bis 11 Zeichen hat; der Lauf wählt aks-2a0320 und bittet Sie, den gewünschten Namen zu setzen.

Die Migration der Reihe nach

Die Schritte sind allgemeine Praxis; der Lauf liefert die ersten beiden und die Listen für den Rest.

1. 01

   1 · Infrastrukturcode bewerten

   Lassen Sie die Engine über das Terraform oder OpenTofu der Cluster laufen. Sie benennt jede cloudspezifische Einstellung, sodass die Änderungsliste existiert, bevor jemand eine Zeile schreibt.

2. 02

   2 · Netzwerk und Identität zuerst klären

   Platzierung des Clusters, API-Zugriff und Authentifizierung der Workloads sind die Fragen, die die Entwürfe bei jeder Quelle offen lassen. Klären Sie sie vor den Knotengrößen.

3. 03

   3 · Manifeste und Charts durchsuchen

   Suchen Sie Annotationen für Load Balancer und Ingress, Storage Classes, Service-Account-Annotationen für Cloud-Identität und Controller, die es nur in der Quell-Cloud gibt. Diese Teile wandern nicht mit den Manifesten.

4. 04

   4 · SKE-Cluster in einem Testprojekt bauen

   Wenden Sie den entworfenen Cluster an, nachdem die Variablen gefüllt sind, und deployen Sie zuerst die zustandslosen Workloads.

5. 05

   5 · Persistente Volumes umziehen

   Der Lauf nennt ein Backup-Werkzeug wie Velero für Volume-Daten; die Daten selbst überträgt die Engine nie. Wählen Sie die Methode nach Größe, Änderungsrate und tolerierter Ausfallzeit.

6. 06

   6 · Den Traffic umstellen

   Stellen Sie DNS oder den vorgelagerten Load Balancer Einstiegspunkt für Einstiegspunkt um, behalten Sie den Quell-Cluster, bis die Prüfungen bestehen, und legen Sie ihn dann still.

Was die Quell-Clouds gemeinsam haben

• Eine verwaltete Control Plane

  AKS, GKE und EKS betreiben die Control Plane für Sie, SKE ebenso. Adresse und Zugangsdaten des API-Servers ändern sich also, das Betriebsmodell aber bleibt vertraut.

• Automatische oder Standard-Modi

  EKS bietet Auto Mode, AKS Automatic und Standard, GKE Autopilot und Standard. Automatisch verwaltete Knotenfunktionen sind Verhalten des Anbieters; prüfen Sie, ob Workloads davon abhängen.

• Cloudgebundene Add-ons

  Netzwerk-Plugins, Storage-Treiber, Ingress-Controller und Identitätsanbindungen stammen aus der Quell-Cloud und werden durch SKE-Entsprechungen ersetzt.

• Versionen

  In diesen Läufen beginnt der SKE-Katalog für eu01 bei 1.35, und jeder Entwurf verlangt 1.36; die Quell-Cluster mit 1.31 und 1.32 werden also unterwegs angehoben. Prüfen Sie zuerst entfernte Kubernetes-APIs gegen Ihre Manifeste.

Fragen von Plattformteams

Quellen

• STACKIT-Dokumentation: Kubernetes Engine (SKE)
• AWS-Dokumentation: Was ist Amazon EKS?
• Microsoft Learn: Grundkonzepte von AKS
• Google Cloud: GKE im Überblick