容器已经不是新鲜东西了。互联网团队拆微服务，传统企业迁老系统，最后大多要落到容器上，原因很实际：发布更快，资源能按需用。阿里云的容器产品比较全，从镜像构建到集群运行再到监控，基本能在一朵云上接起来。这篇文章不逐个介绍产品功能，只讲选型时要想清楚的几件事，以及上线前后容易踩的坑。
先分清几类产品
第一次接触阿里云容器，产品名确实多，容易看晕。换个角度看就简单些：一类负责跑业务，一类负责存和分发镜像，还有一类是把跑业务这件事做得更省心。
- 容器服务 ACK：托管的 Kubernetes，控制面由云上维护，团队主要精力放在工作负载和发布流程上。适合需要长期稳定运行的核心业务。
- 弹性容器实例 ECI：不用自己管服务器，直接拉起容器。适合流量突发、离线计算这类用完就该释放的任务。
- Serverless Kubernetes ASK：保留 Kubernetes 的使用方式，但不用关心底层节点，按实际用到的资源计费。适合不想养运维团队、又需要 K8s 生态的场景。
- 容器镜像服务 ACR：提供镜像存储、分发和安全扫描。多地域部署时，镜像同步能省不少事。
选型时可以先问两个问题：业务是长期平稳还是忽高忽低，团队有没有能力维护 Kubernetes。前一个问题决定用 ACK 还是 ECI，后一个问题决定要不要直接考虑 ASK。镜像仓库通常统一用 ACR，不必为此单独纠结。
两个典型场景
电商大促：核心服务和临时任务分开放
设想一家中型电商团队，一年有两次大促，平时流量大概只有峰值的两成。如果按峰值采购服务器，大部分时间机器都在空转。更常见的做法是把交易核心服务放在 ACK 集群里，配好基于 CPU 和自定义指标的弹性伸缩；图片处理、报表生成这类临时计算交给 ECI，任务跑完就释放。这样做下来，资源成本会比长期堆机器低，大促前的扩容时间也能从小时级压到分钟级。
弹性伸缩的阈值不能拍脑袋定。第一次大促前最好做一轮压测，看扩容需要多久，新实例能不能在流量到来前就绪。否则弹性策略再灵活，也可能在高峰前一刻掉链子。
老系统迁移：发布标准化比技术本身更关键
制造业或传统企业的情况更常见一些。ERP 之类的系统跑在老旧虚拟机上，发布靠人工，每次上线都要停机好几个小时。迁移时可以先用 ACR 统一各业务线的镜像，加上镜像签名和漏洞扫描，先把”什么能上线”管住；然后分批迁到 ACK，用滚动更新替代停机发布。
这类项目的难点往往不在容器本身。镜像规范、环境配置、回滚预案，哪一项没定清楚，迁移后都会出问题。容器只是把这些约定固定下来的工具。
上线前后要留意的几件事
镜像尽量小
镜像体积直接影响拉取速度，也就影响扩容响应。基础镜像优先考虑 Alpine 或 distroless，构建时用多阶段构建，把编译工具留在构建阶段，别带进最终镜像。
requests 和 limits 必须设
没有设置资源请求和限制，调度器就只能凭猜测分配资源。单个容器一旦出异常，还可能把整个节点拖慢。初始值可以参考压测结果，上线后再根据监控慢慢调。
日志和告警提前配
容器实例多、生命周期短，过去登录服务器翻日志的办法基本行不通。日志服务 SLS 和 ARMS 可以把日志和指标集中起来。告警规则和日志索引最好在上线前配好，出了问题再补，通常已经晚了。
权限和网络别图省事
镜像漏洞、RBAC 权限过宽、API Server 暴露在公网，是最常见的几类风险。开启 ACR 的镜像扫描，按最小权限给 Kubernetes 角色授权，再把访问范围收在 VPC 和安全组里。前期多花点时间，后面能省很多麻烦。
成本要定期看
容器化之后，资源利用率通常是慢慢提上来的，不会上线当天就理想。建议每隔一段时间看一次集群的 CPU 和内存利用率，清理长期没人用的命名空间和负载，再结合弹性策略调整容量。
从哪里开始
阿里云的容器产品线比较完整，真正卡住团队的，往往是发布流程、监控习惯和权限管理有没有跟着改。建议先挑一个非核心业务，用 ACK 或 ASK 把镜像构建、部署、监控、回滚这条链路完整跑一遍。经验攒下来再推向核心系统，比一开始就全量迁移稳妥得多。
