Plan your migration to ACK

Updated at:

Due to compliance and security requirements, ACK differs from self-managed Kubernetes in some capabilities. Review network, capacity, data, and security planning before creating your first cluster.

Audience

For DevOps engineers and architects deploying workloads on ACK for the first time.

Cluster planning

ACK supports ECS Bare Metal instances, which combine virtual machine elasticity with physical machine performance using Alibaba Cloud's virtualization 2.0 technology. They provide exclusive compute resources, chip-level security, confidential computing, heterogeneous instruction set support, and compatibility with multiple proprietary cloud deployments.

Instance type Best for
ECS Bare Metal instances Workloads requiring exclusive compute resources, chip-level security, or confidential computing
GPU ECS instances AI, deep learning, video processing, scientific computing, and data visualization

Network planning

Network type

ACK clusters support two network types for ECS instances.

Network type Isolation level Notes
Virtual private cloud (VPC) (recommended) Layer 2 Stronger security and flexibility
Classic network Layer 3 All instances share infrastructure; not recommended for new clusters

Use VPC for all new clusters.

Network plugin

The network plug-in controls pod-to-pod communication within the cluster. ACK supports two options.

Plug-in Developed by Kubernetes network policies Bandwidth throttling Best for
Terway (recommended) Alibaba Cloud Supported Per-container Most workloads; required if you need network policies
Flannel Kubernetes community Not supported Not available Simple clusters with no network policy requirements

Terway assigns elastic network interfaces (ENIs) directly to containers, enabling Kubernetes network policies and per-container bandwidth throttling. If you don't need network policies, Flannel is simpler.

Capacity planning

Plan capacity in two stages: an initial baseline when you create the cluster, and a scaling strategy to handle load changes afterward.

Initial capacity: Set node count and instance types based on expected workload at cluster creation.

Auto scaling: After cluster creation, configure these scaling mechanisms as needed.

Mechanism Scope How it works
Horizontal Pod Autoscaling (HPA) Pods Scales pod replicas based on resource utilization
cluster-autoscaler Nodes Scales nodes automatically; supports regular, GPU-accelerated, and preemptible instances across multiple zones

Data planning

Choose storage and database services based on your application's data access patterns.

Service Type Best for
Relational Database Service (RDS) Managed relational database Structured data; supports MySQL, SQL Server, PostgreSQL, PPAS, and MariaDB; built on Apsara Distributed File System with high-performance SSDs
Object Storage Service (OSS) Object storage Unstructured data, media files, and backups; high capacity, security, cost-effectiveness, and reliability
Container Registry Image registry Store, scan, and manage container images; supports builds from code repositories in China and overseas, security scanning, and simplified image licensing

Container Registry offers two tiers: a default instance and an Enterprise Edition for enhanced security and compliance.

Security planning

ACK provides security controls across the full workload lifecycle.

Layer Mechanism
Infrastructure Security group rules to control network access to cluster nodes
Image Private image repositories and automated vulnerability scans before deployment
Application Kubernetes network policies to control traffic between pods and services

Monitoring and logging

Concern Options
Cluster and resource monitoring Cloud Monitor — monitors cluster nodes and Alibaba Cloud resources with custom metrics, alert rules, and exception notifications
Application performance monitoring Application Real-Time Monitoring Service (ARMS) — APM covering frontend, application, and Prometheus monitoring for browsers, mini programs, distributed applications, and containers
Log collection Log Service — centralized log collection from cluster workloads; eliminates custom logging infrastructure

Next steps