应用打包成镜像以后，真正麻烦的事才开始：机器怎么排、扩容找谁、测试和生产怎么保证跑的是同一个东西。阿里云容器服务做的，就是把集群搭建、调度和扩缩容交给平台，团队主要盯业务代码。下面说明它包含哪些产品、哪些场景适合上、一个迁移案例是怎么做的，最后给出从开通到部署第一个应用的步骤。
阿里云容器服务包含哪些产品
很多人以为容器服务只是控制台里的一个入口，其实它是一组服务，分别负责运行、镜像和网络。常用的有下面几个：
- 容器服务 ACK（Kubernetes 版）：托管的 Kubernetes 集群。控制面的高可用和版本升级由平台负责，你只需要管理工作节点。
- Serverless 容器服务 ACK Serverless：不用管理节点，按 Pod 实际使用的资源计费。流量忽高忽低、节点利用率很难控制的任务，可以优先考虑它。
- 容器镜像服务 ACR：存放和分发镜像，支持镜像安全扫描和跨地域同步。集群分布在多个地区时，跨地域同步能让各地拉取镜像更方便。
- 弹性容器实例 ECI：不依赖集群，直接启动单个容器，适合批量计算和临时任务。
- 服务网格 ASM：统一管理服务之间的流量、熔断和灰度发布。服务多到在代码里维护这些规则已经吃力时，再考虑引入。
多数团队会先从 ACK 和 ACR 起步。业务规模变大、服务之间的关系变复杂以后，再按需加 ASM 或 Serverless 能力。别一开始就把所有产品都接上，出了问题很难分清是哪一层的原因。
适用场景
下面几类业务比较适合使用阿里云容器服务：
- 微服务数量多，需要统一的服务发现、负载均衡和滚动发布。服务少的时候，手动维护这些配置还应付得过来。
- 访问量有明显的高峰和低谷，比如电商大促、在线教育的开课时段。
- 测试、预发和生产需要保持一致的部署方式，减少“在我机器上能跑”这类问题。
- 离线计算、视频转码、数据清洗等可以拆成大量独立任务的工作。
如果应用只有一两个服务，访问量也比较稳定，直接用云服务器通常更省事。容器化能带来多少好处，要和团队的运维成本放在一起算，不能只看技术上是否先进。
案例：某电商团队的容器化迁移
以下为示意案例，用于说明典型做法，具体数字需替换为实际项目数据。
迁移背景
某中型电商团队原有 30 多个服务，部署在十几台虚拟机上。每逢大促，运维人员要提前手动扩容，活动结束后再缩回去。部署依赖人工执行脚本，一旦出错，回滚要花不少时间。团队的目标很具体：人手不增加，资源利用率和发布效率要提上去。
迁移做法
- 把各服务的运行环境写进 Dockerfile，镜像统一推送到容器镜像服务 ACR，并开启镜像扫描。含高危漏洞的镜像会被拦截，不再进入后续部署。
- 用容器服务 ACK 建两个集群，分别承载测试环境和生产环境，两边使用同一套 Helm Chart。环境之间的差异越少，线上意外的机会就越少。
- 订单、商品等核心服务配置基于 CPU 和请求量的弹性伸缩，并设置合理的最小和最大副本数。最大副本数要结合节点资源来算，否则扩容会卡在资源不足上。
- 报表生成、图片处理这类非核心任务，大促时流量一涨就用 ECI 按需启动，任务结束后自动释放。
- 发布采用分批滚动更新，每一批通过健康检查后再继续。出现异常时自动回滚到上一版本。
迁移效果
迁移后，团队主要观察到三类变化：
- 发布从人工执行改为流水线自动完成，单次发布的操作时间明显缩短。
- 大促期间的扩容由系统自动完成，运维人员不用再盯着服务器数量手动调整。
- 非高峰时段的资源用量下降，闲置成本得到控制。
迁移也带来了新的工作。团队要先学会 Kubernetes 的基本概念，还要重新梳理服务的健康检查和日志采集方式。这部分投入在迁移前期最明显，别在一开始就低估它。
上手步骤
- 在阿里云控制台开通容器服务 ACK 和容器镜像服务 ACR，按预计的节点数选择集群规格。
- 为应用编写 Dockerfile，在本地构建镜像，推送到 ACR 的个人或企业仓库。
- 编写 Deployment 和 Service 配置文件，先部署到测试集群，确认服务可以正常访问。
- 配置 Ingress 或负载均衡，把外部流量导入服务，并绑定域名和证书。
- 接入日志服务和监控告警，确认容器的 CPU、内存和业务指标都能被采集到。
- 配置弹性伸缩和发布策略，生产环境先小范围灰度，确认没问题后再全量上线。
第一次上手时，建议只挑一个无状态的小服务，完整走一遍上面的流程。走通之后，再把同样的做法套到其他服务上，返工会少很多。
使用建议
- 给每个容器设置资源请求和限制。没有限制时，一个服务的内存问题可能拖垮整个节点，连带影响其他服务。
- 健康检查要区分存活探针和就绪探针。服务启动较慢时，就绪探针要留出足够的初始化时间，否则服务还没准备好就会被判定为失败。
- 镜像尽量精简，只保留运行所需的文件，既能缩短拉取时间，也能减少安全风险。
- 密码和密钥通过 Kubernetes Secret 或阿里云 KMS 管理，不要写进镜像或代码仓库。
- 集群升级前，先在测试集群验证兼容性，再安排生产环境的升级窗口。
