很多团队刚接触 k8s 时，关心的是它能不能把容器调度起来。真正上线以后，问题会转到集群升级、节点扩容、监控告警和安全合规上。把其中一部分交给 阿里云 的托管服务，团队能腾出手做业务。
自建集群到底累在哪
自建 k8s 集群要自己维护控制面高可用、etcd 备份、证书轮换和版本升级。单看每一项都不难，麻烦在于它们要长期做，而且出错时影响面大。
- 控制面升级要一台台操作，维护窗口拉得很长。
- etcd 备份很少真正演练，出事时才发现恢复不了。这种情况并不少见。
- 节点扩容靠手工脚本，高峰期往往已经来不及。
ACK 实际托管了什么
阿里云容器服务 ACK（容器服务 Kubernetes 版）托管 k8s 控制面，并和阿里云的网络、存储、监控、负载均衡打通。对日常运维影响最大的有下面几项。
控制面托管与升级
控制面的高可用和日常维护由阿里云负责。小版本升级可以在控制台或 API 上发起，升级前能看到兼容性检查结果。升级之前仍然要在测试集群里把业务跑一遍，检查结果只能说明平台层面的问题。
节点池与弹性伸缩
节点池把规格和镜像一致的机器放在一组里管理。配合集群自动伸缩，负载上来时加节点，低谷时回收，闲置资源会少很多。
弹性容器实例
突发的批处理任务可以调度到弹性容器实例上跑。不用为峰值提前买节点，任务结束，资源也就释放了。
可观测性
ACK 可以和 ARMS、日志服务 SLS 打通。指标、日志、链路追踪能放在同一个视图里看，排查问题时不用来回切工具。
一个迁移案例
下面是一个示意场景，其中的数字只用来说明思路，正式发布前需要替换成真实数据。假设某在线教育团队有 40 个微服务跑在自建集群上，周末直播课的流量大约是平时的五倍。
- 盘点与分组。先按依赖关系和流量大小把服务分成三批。无状态服务先走，数据库和消息队列放到最后。
- 搭建 ACK 集群并打通网络。新集群通过专线和原机房互通。服务之间的调用尽量走内网地址，避免产生不必要的公网流量费用。
- 灰度切流。用负载均衡的权重把流量一点点从旧集群挪到新集群，每次调整约 10%，同时盯住错误率和延迟。出现异常就把权重调回去。
- 压测与弹性验证。在预发环境模拟五倍流量，确认节点池的扩容速度和 HPA 参数够不够用。这一步最容易被跳过，也最容易在直播当天出问题。
这个示意团队大约用了六周。直播高峰时，节点池几分钟内从 12 台扩到 30 台，高峰过后自动缩回。按这组假设测算，闲置资源成本比原来按峰值常备机器的方式低三成左右。
迁移时容易踩的坑
- 网段没规划好。Pod 和 Service 的 CIDR 定下来之后很难改，动手前最好和网络团队对一遍。
- 把弹性容器实例当普通节点用。它对 DaemonSet 和主机网络有限制，依赖这些能力的组件要先确认能不能跑。
- RAM 权限给得太宽。CI/CD 流水线应该用最小权限的子账号或 RAM 角色，不要直接用主账号的密钥。
- 镜像直接从公网拉取，发布慢，还不稳定。可以通过容器镜像服务 ACR 做同地域同步，发布时从内网拉取。
要不要迁，怎么选
团队规模不大、业务以无状态服务为主，直接用托管集群通常更省事，自建的维护成本会明显下降。如果合规要求高，或者要统一管理多个集群，可以评估 ACK Pro 版或 ACK One 的管理能力。是否迁移取决于运维人力、峰值流量和现有投入，没有统一答案。建议先挑一个非核心服务试点，跑通之后再决定推进范围。
