ALIBABA CLOUD ACK → STACKIT SKE
Alibaba Cloud ACK zu STACKIT Kubernetes Engine
Ein ACK-Cluster wird zu einem SKE-Cluster: Die Workload-Manifeste können bleiben, ersetzt werden Node Pools, Load-Balancer- und Storage-Annotationen, Identität und Add-ons der Quelle. StackToIT liest den Managed Cluster und seine vSwitches aus Ihrem Alibaba-Cloud-Terraform, stuft den Cluster als REPLATFORM ein und sagt Ihnen, auf welcher SKE-Version Sie landen sollten.
Ein Managed-ACK-Cluster mit Node Pool, bewertet
Eine kleine Alibaba-Cloud-Umgebung, für diese Seite geschrieben und am 4. November 2026 von StackToIT bewertet. Links die Eingabe, rechts das Ergebnis, das StackToIT dafür festgehalten hat: ein Auszug aus assessment.json, die Werte genau so, wie der Lauf sie geschrieben hat.
resource "alicloud_cs_managed_kubernetes" "platform" {
name = "platform"
cluster_spec = "ack.pro.small"
version = "1.31.1-aliyun.1"
vswitch_ids = [alicloud_vswitch.nodes_a.id, alicloud_vswitch.nodes_b.id]
pod_cidr = "172.20.0.0/16"
service_cidr = "172.21.0.0/20"
proxy_mode = "ipvs"
new_nat_gateway = true
slb_internet_enabled = false
}
resource "alicloud_cs_kubernetes_node_pool" "general" {
cluster_id = alicloud_cs_managed_kubernetes.platform.id
node_pool_name = "general"
vswitch_ids = [alicloud_vswitch.nodes_a.id, alicloud_vswitch.nodes_b.id]
instance_types = ["ecs.g7.2xlarge"]
desired_size = 3
system_disk_category = "cloud_essd"
system_disk_size = 80
}{
"id": "alicloud_cs_managed_kubernetes.platform",
"result": {
"class": "REPLATFORM",
"confidence": "MEDIUM",
"target": {
"service": "STACKIT Kubernetes Engine (SKE)"
},
"reason": "An ACK cluster becomes an SKE cluster. Workload manifests can stay, while node pools, load balancer and storage annotations, identity and add-ons of the source are replaced."
}
}Manifeste bleiben
Die Workloads behalten ihre Manifeste. Was ACK um sie herum hinzufügt, von seinen Load-Balancer-Annotationen bis zu seinen Add-ons, wird auf SKE ersetzt.
Neun Cluster-Einstellungen benannt
cluster_spec, name, new_nat_gateway, pod_cidr, proxy_mode, service_cidr, slb_internet_enabled, version und vswitch_ids stehen für Ihr Plattformteam in der Liste.
Node Pool an Ihre Architekten
Über den Node Pool entscheiden Ihre Architekten. ecs.g7.2xlarge, eine gewünschte Größe von 3 und die System-Disk mit 80 GB sind die Grundlage für den SKE-Node-Pool, den sie festlegen.
Egress und Erreichbarkeit im Blick
new_nat_gateway und slb_internet_enabled gehören zu den benannten Einstellungen. Ausgehender Zugang und öffentlicher Endpunkt werden also bewusst entschieden, nicht per Voreinstellung.
Zwei vSwitches in zwei Zonen
Aus demselben Lauf. Links die Eingabe, rechts das Ergebnis, das StackToIT dafür festgehalten hat: ein Auszug aus assessment.json, die Werte genau so, wie der Lauf sie geschrieben hat.
resource "alicloud_vswitch" "nodes_a" {
vswitch_name = "platform-nodes-a"
vpc_id = alicloud_vpc.platform.id
cidr_block = "10.60.0.0/20"
zone_id = "eu-central-1a"
}
resource "alicloud_vswitch" "nodes_b" {
vswitch_name = "platform-nodes-b"
vpc_id = alicloud_vpc.platform.id
cidr_block = "10.60.16.0/20"
zone_id = "eu-central-1b"
}{
"id": "alicloud_vswitch.nodes_a",
"result": {
"class": "RECONFIGURE",
"confidence": "MEDIUM",
"target": {
"service": "STACKIT network"
},
"reason": "A vSwitch becomes a STACKIT network with its own address range. It is bound to a zone at the source; review the zone placement of the workloads on it."
}
}So wird die ACK-Umgebung zugeordnet
| Alibaba-Cloud-Ressource | STACKIT-Ziel | Migrationsklasse |
|---|---|---|
| ACK Managed Cluster | STACKIT Kubernetes Engine (SKE) | Replatforming |
| ACK-Node-Pool | Entscheiden Ihre Architekten | Architekturentscheidung |
| vSwitches in eu-central-1a und eu-central-1b | STACKIT-Netzwerke mit eigenen Adressbereichen | Rekonfigurieren |
| VPC | STACKIT-Netzwerk, mit einer Network Area, wo Routing nötig ist | Rekonfigurieren |
Klassen so, wie der Lauf sie für 5 Ressourcen entschieden hat. Wellen: VPC, dann beide vSwitches parallel, dann der Cluster, dann der Node Pool.
Auf einer unterstützten SKE-Version landen
Der Lauf liest den SKE-Lifecycle mit Stand 3. November 2026 und nennt jede Version mit ihren Daten.
1.36 als Landeversion
Unterstützt, veröffentlicht am 27. August 2026, Ablauf am 9. Juni 2027, als Landeversion geeignet markiert.
Von 1.31 aufwärts
Der Beispiel-Cluster läuft auf 1.31.1-aliyun.1. Die Versionen 1.32 bis 1.34 sind auf SKE abgelaufen; der Umzug schließt daher das Upgrade auf 1.36 ein.
Updates durch SKE selbst
Erreicht eine Version ihr Ablaufdatum, startet SKE ein verpflichtendes Update. Der Lauf hält das als Day-2-Verantwortung des Providers fest.
eu01 oder eu02
SKE steht in den STACKIT-Katalogen beider Regionen; die Region wählen also Sie.
Bewiesen an einer echten AWS-Umgebung
Die AWS Retail Store Sample App, ein öffentliches Terraform-Projekt von AWS, von StackToIT bewertet und vollständig veröffentlicht, genau so, wie der Lauf es geschrieben hat.
Fallstudie ansehen (Englisch)- 282
- Terraform-Ressourcendefinitionen analysiert
- 44
- Migrationseinheiten identifiziert
- 38
- Zieleinheiten erzeugt, von 52 betrachteten
- 331
- Planschritte erstellt
Fragen aus Plattformteams
Können wir unsere Kubernetes-Manifeste beim Wechsel von ACK behalten?
Ja, die Workload-Manifeste können bleiben. Node Pools, Load-Balancer- und Storage-Annotationen, Identität und Add-ons von ACK werden durch die von SKE ersetzt.
Was passiert mit dem ACK-Node-Pool?
Ihre Architekten legen daraus den SKE-Node-Pool fest. Der Lauf übergibt den Node Pool als MANUAL_REVIEW; Instanztypen, gewünschte Größe und System-Disk sind die Vorlage für den neuen Pool.
Wie werden die zwei Zonen des ACK-Clusters behandelt?
Jeder vSwitch wird zu einem STACKIT-Netzwerk mit eigenem Adressbereich. Weil ein vSwitch in der Quelle an eine Zone gebunden ist, bittet die Bewertung Sie, die Zonenplatzierung der Workloads darauf zu prüfen.
Quellen
Ihr nächster Schritt: STACKIT.
Erzählen Sie uns von Ihrer Umgebung. Wir zeigen Ihnen, was StackToIT dafür liefert: Zielarchitektur, Terraform-Artefakte und einen strukturierten Migrationsplan.