How Shentong Express Cut a Year‑Long Cluster Migration to Months with ACK One Multi‑Cluster Service

Background and Migration Challenges

Shentong Express operates dozens of business systems and hundreds of micro‑services (including databases, big‑data, storage and logging components). The migration from its legacy logistics cloud to Alibaba Cloud Container Service for Kubernetes (ACK) had to satisfy:

Massive scale – hundreds of services across many clusters.

Complex, undocumented service‑dependency graph.

Zero‑downtime requirement for core C‑ and B‑end services.

Limited migration window (~26 weeks after excluding regular releases and major sales events).

Traditional cross‑cluster migration methods (full‑cluster lift‑and‑shift or refactoring service discovery to a central registry) would require extensive code changes, manual DNS updates and long validation cycles, leading to high cost and uncontrolled risk.

ACK One MultiClusterService Overview

Alibaba Cloud Distributed Cloud Container Platform ACK One introduces MultiClusterService (MCS) , a Kubernetes‑native abstraction that enables a service defined in one cluster to be reachable from any other cluster using the same DNS name. Key properties:

Zero business refactoring : No changes to application code, Service objects or CoreDNS configuration.

Cross‑cluster routing handled by the platform : The ACK One control plane creates virtual endpoints that forward traffic between clusters.

Risk‑controlled migration : Services can be moved in batches; traffic can be validated with a small percentage before full cut‑over.

Traffic‑loss‑free : No interception or redirection of live traffic.

Typical MultiClusterService Manifest

apiVersion: networking.alibaba.com/v1alpha1
kind: MultiClusterService
metadata:
  name: order-service
spec:
  serviceName: order-service   # name of the Service in the source cluster
  namespace: logistics
  clusters:
    - name: old-cluster
    - name: new-cluster

Applying the manifest creates a DNS entry order-service.logistics.svc.cluster.local that resolves to the appropriate endpoint in whichever cluster the request originates.

Migration Procedure Using MultiClusterService

Deploy MultiClusterService objects for the target services in both the old and new clusters, establishing bidirectional service discovery.

Select a subset of services (e.g., a single business line) and migrate its workloads to the new cluster while keeping the Service name unchanged.

Gradually increase the traffic weight to the new instances (e.g., 10 % → 100 %). If issues arise, rollback is immediate by reverting the weight.

Repeat steps 2‑3 until all services run in the new cluster, then switch external ingress to point exclusively to the new cluster.

The process can be visualised with three backend services (svc‑a, svc‑b, svc‑c) and a client pod that resolves the same DNS name regardless of the cluster where the client runs.

Results and Quantitative Benefits

Timeline compression : Expected migration duration of > 1 year reduced to a few months (≈ 3‑4 months).

Effort reduction : No need to modify service‑discovery code for hundreds of services; migration can be performed system‑by‑system during stable periods.

Labor cost : Development teams focus on business features; operations rely on platform‑level routing instead of manual mapping.

Controlled rollback : Each batch can be validated with a small traffic slice; failures are mitigated by instantly reverting to the old cluster.

Efficiency gain : Overall migration productivity increased by ~35 %.

By abstracting inter‑cluster dependencies and automating routing, ACK One MultiClusterService enables large‑scale, zero‑downtime migrations without code changes, making it suitable for any enterprise moving workloads across clouds or Kubernetes clusters.