ALIBABA CLOUD ACK → STACKIT SKE

Alibaba Cloud ACK to STACKIT Kubernetes Engine

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. StackToIT reads the managed cluster and its vSwitches from your Alibaba Cloud Terraform, classifies the cluster as REPLATFORM and tells you which SKE version to land on.

A managed ACK cluster and node pool, assessed

A small Alibaba Cloud estate written for this page and assessed by StackToIT on 4 November 2026. Left: the input. Right: the result StackToIT recorded for it, an excerpt of assessment.json with the values exactly as the run wrote them.

Example inputmain.tf
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
}
StackToIT assessmentassessment.json
{
  "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."
  }
}
  • Manifests stay

    The workloads keep their manifests. What ACK adds around them, from its load balancer annotations to its add-ons, is replaced on SKE.

  • Nine cluster settings named

    cluster_spec, name, new_nat_gateway, pod_cidr, proxy_mode, service_cidr, slb_internet_enabled, version and vswitch_ids are listed for your platform team.

  • Node pool to your architects

    The node pool is decided by your architects. ecs.g7.2xlarge, a desired size of 3 and the 80 GB system disk are the input for the SKE node pool they define.

  • Egress and exposure in view

    new_nat_gateway and slb_internet_enabled are among the named settings, so outbound access and the public endpoint are decided on purpose, not by default.

Two vSwitches in two zones

From the same run. Left: the input. Right: the result StackToIT recorded for it, an excerpt of assessment.json with the values exactly as the run wrote them.

Example inputmain.tf
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"
}
StackToIT assessmentassessment.json
{
  "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."
  }
}

How the ACK estate maps

Alibaba Cloud resourceSTACKIT targetMigration class
ACK managed clusterSTACKIT Kubernetes Engine (SKE)Replatform
ACK node poolDecided by your architectsArchitect decision
vSwitches in eu-central-1a and eu-central-1bSTACKIT networks with their own address rangesReconfigure
VPCSTACKIT network, with a Network Area where routing is neededReconfigure

Classes as the run decided them for 5 resources. Waves: VPC, then both vSwitches in parallel, then the cluster, then the node pool.

Landing on a supported SKE version

The run reads the SKE lifecycle as of 3 November 2026 and states each version with its dates.

  • 1.36 as the landing

    Supported, released on 27 August 2026, expiry on 9 June 2027, marked suitable as a landing version.

  • From 1.31 upwards

    The example cluster runs 1.31.1-aliyun.1. Versions 1.32 to 1.34 have expired on SKE, so the move includes the upgrade to 1.36.

  • Updates by SKE itself

    When a version reaches its expiry date, SKE starts a mandatory update. The run records this as the provider’s day-2 responsibility.

  • eu01 or eu02

    SKE is in the STACKIT catalogues of both regions, so you choose the region.

Proven on a real AWS estate

The AWS Retail Store Sample App, a public Terraform project from AWS, assessed by StackToIT and published in full, exactly as the run wrote it.

View Case Study
282
Terraform resource declarations analyzed
44
migration units identified
38
target units generated, from 52 considered
331
plan steps written

Questions platform teams ask

Can we keep our Kubernetes manifests when we leave ACK?

Yes, workload manifests can stay. The node pools, load balancer and storage annotations, identity and add-ons of ACK are replaced by those of SKE.

What happens to the ACK node pool?

Your architects define the SKE node pool from it. The run hands the node pool over as MANUAL_REVIEW; its instance types, desired size and system disk are the reference for the new pool.

How are the two zones of the ACK cluster handled?

Each vSwitch becomes a STACKIT network with its own address range. Because a vSwitch is bound to a zone at the source, the assessment asks you to review the zone placement of the workloads on it.

Sources

Your next move: STACKIT.

Tell us about your estate. We show you what StackToIT delivers for it: target architecture, Terraform artifacts and a structured migration plan.