阿里云云原生架构演进：从 ECS 到 ACK 的实战路径

在国内的云计算市场，阿里云占据了主导地位。很多企业早期的上云架构都是基于 ECS（云服务器）的“搬家式”上云——仅仅是用 ECS 替代了物理机，应用架构和运维模式并没有本质改变。

随着业务的扩展和对敏捷迭代的追求，向云原生（Cloud Native）架构演进成为了必选项。而阿里云容器服务 Kubernetes 版（ACK）则是这一演进的核心载体。本文将分享从 ECS 架构平滑迁移至 ACK 的实战经验。

1. 为什么要迁移到 ACK？

资源利用率：ECS 独占模式下，CPU/内存利用率通常低于 20%。通过 ACK 混部，可以将利用率提升至 40%-60%，显著降低成本。
弹性伸缩：ECS 的扩容通常需要分钟级（购买、启动、初始化），而 Pod 的启动是秒级的。结合 ACK 的 HPA（水平伸缩）和 Cluster Autoscaler，可以完美应对流量洪峰。
标准化交付：Docker 镜像保证了“一次构建，到处运行”，消除了“我本地是好的，线上不行”的诡异问题。

2. 演进路线图

以下是典型的从 ECS 到 ACK 的迁移路径图：

graph TD
    subgraph "Phase 1: Infrastructure Prep"
        VPC[VPC Network] -->|CEN Peering| ACK_Cluster[ACK Cluster]
        ACK_Cluster -->|Terway Plugin| ENI[Elastic Network Interface]
    end

    subgraph "Phase 2: Stateless Migration"
        Web_App[Web Service] -->|Dockerize| Container_Image[Container Image]
        Container_Image -->|Deploy| ACK_Pod[ACK Pod]
        SLB[Server Load Balancer] -->|Traffic Weight| ECS_Group[ECS Group]
        SLB -->|Traffic Weight| ACK_Group[ACK Node Group]
    end

    subgraph "Phase 3: Stateful & Optimization"
        DB_Self[Self-hosted DB on ECS] -->|Data Migration| RDS[Aliyun RDS]
        Middleware_Self[Self-hosted Middleware] -->|Replace| PaaS[Aliyun PaaS (Redis/RocketMQ)]
        Spot_Instance[Spot Instances] -->|Cost Saving| Batch_Job[Batch Processing Jobs]
    end

    Phase_1 --> Phase_2 --> Phase_3

阶段一：网络与基础设施准备

在迁移之前，网络规划至关重要。

VPC 集成：ACK 集群应部署在现有的 VPC 中，或者通过 CEN（云企业网）与现有 VPC 打通。确保 Pod 网段、Service 网段与现有 ECS 网段不冲突。
Terway 网络模式：强烈建议选择阿里云自研的 Terway 网络插件，而不是开源的 Flannel。
- Terway 可以让 Pod 直接使用 VPC 的弹性网卡（ENI）IP，性能几乎无损耗。
- 支持 Pod 级别的安全组规则，便于复用现有的安全策略。

阶段二：无状态应用迁移 (Stateless)

Web 服务、API 网关等无状态应用最容易迁移。

容器化改造：编写 Dockerfile，将应用打包。注意将配置（ConfigMap）、密钥（Secret）与镜像分离。
日志收集：ECS 时代通常是 Logtail 采集本地文件。在 ACK 中，建议使用 Logtail CRD 方式，通过标准输出（Stdout）或挂载 HostPath 采集日志到阿里云 SLS（日志服务）。
负载均衡切换：
- 流量切分：在 SLB 后端服务器组中，同时挂载 ECS 和 ACK 的 Node（或者通过 ALB Ingress 转发）。
- 权重控制：逐步调大 ACK 侧的权重，观察业务日志和监控，确认无误后下线 ECS。

阶段三：有状态应用迁移 (Stateful)

数据库、中间件等有状态应用迁移风险较大。

自建中间件 -> 云服务：借迁移之机，建议将自建在 ECS 上的 MySQL、Redis、Kafka 迁移到阿里云 RDS、Tair、RocketMQ 等 PaaS 服务。这能极大减轻运维负担，并获得更好的高可用保障。
必须自建的场景：如果必须在 K8s 中运行有状态应用（如 Elasticsearch 集群），务必使用 StatefulSet 控制器，并配合 PV/PVC（阿里云云盘或 NAS）实现数据持久化。

3. 关键技术点与避坑指南

3.1 优雅上下线

在 ECS 时代，发布可能通过脚本控制。在 K8s 中，必须配置好探针：

Readiness Probe（就绪检查）：确保 Pod 完全启动并加载完配置后，才会有流量打入。避免服务启动慢导致的 502 错误。
Liveness Probe（存活检查）：当服务死锁或假死时，自动重启 Pod。
PreStop Hook：在 Pod 终止前执行脚本（如通知注册中心下线、等待请求处理完毕），实现零宕机发布。

3.2 存储卷的选择

云盘 (Block Storage)：性能好，但只能单 Pod 挂载（RWO）。适用于数据库。注意云盘有跨可用区挂载限制。
NAS (File Storage)：支持多 Pod 共享读写（RWX）。适用于共享配置文件、静态资源。性能略低于云盘。

3.3 成本优化：Spot 实例

对于可中断的业务（如离线数据处理、CI/CD Agent），可以使用 抢占式实例（Spot Instances） 作为 ACK 的 Worker 节点，成本仅为按量付费的 1/10。配合 ACK 的节点池管理，可以实现 Spot 回收时的自动排水和补充。

4. 总结

从 ECS 到 ACK 的演进，不仅是基础设施的变更，更是开发运维模式的升级。它强制我们去解耦应用、标准化配置、关注可观测性。虽然迁移过程会有阵痛，但最终获得的弹性、效率和稳定性提升，将是企业数字化转型的巨大红利。