团队把业务搬到ACK上以后，最先感受到的通常是省事：控制面不用自己守，升级和高可用交给云厂商。真正容易出问题的，往往是节点池和网络配置。前者决定资源怎么摆，后者决定网段能用多久、服务之间能不能通。创建集群时，这两项看起来只是几个下拉框和输入框，业务量上来才会暴露问题。下面结合一个电商团队的迁移过程，把常见的坑理一理。
托管省掉了什么，又留下了什么
自建Kubernetes要自己维护etcd、apiserver、调度器和证书体系，一旦控制面出故障，排查成本常常超出预期。托管服务把这部分交出去，团队可以把注意力放在工作负载和发布流程上。
阿里云ACK提供标准版、专有版和Serverless版等形态。标准版的节点由用户自己管理，灵活度高，但节点池的规划、系统配置和扩缩容策略都要自己负责。Serverless版免去节点运维，适合流量波动大、希望按Pod计费的场景。选型时可以先问两个问题：团队有没有节点运维经验，业务负载是否存在明显的峰谷差异。答案不同，后面要操心的节点池和网络问题也不一样。
一个电商团队的迁移过程
某中型电商团队原本把订单、商品和搜索服务跑在虚拟机上，大促前要提前好几天手动扩容，预估稍有偏差就得临时加机器。迁移到ACK后，他们做了三件事。
- 拆分命名空间：按业务线划分namespace，每个环境配置独立的ResourceQuota，测试流量不会再挤占生产资源。
- 配置HPA：基于CPU和自定义指标（QPS）做水平自动伸缩，大促前不必再靠人工预估。
- 接入监控：用阿里云Prometheus托管服务采集指标，并与日志服务SLS联动，故障定位更快。
迁移两个月后，资源利用率从不足30%提升到接近55%，大促扩容从人工数小时缩短为几分钟内自动完成。这说明容器化的收益很大程度来自调度能力的释放。要让这些收益稳定下来，节点池和网络是绕不开的两块。
节点池：规格、标签和扩缩容要一起想
节点池的作用是把规格相近的节点归到一起，统一管理扩缩容。问题常出在图省事上：同一个池里混着不同机型，调度器很难把Pod摆整齐，资源碎片越积越多。建议同一个池只放同规格节点，不同规格的负载用节点标签区分，再通过nodeSelector或亲和性把Pod导向对应的池。
requests是另一个连锁点。定得过高，节点会被占着资源，实际用量很低却放不下新Pod；定得过低，调度看起来很顺，节点真正繁忙时又容易出现不稳定，严重时会OOM。节点池的规格选择和Pod的请求值要放在一起看。最好先用一段时间的历史监控数据确认实际用量，再决定机器配置和扩缩容阈值。
网络规划：一旦定了就很难改
ACK集群创建时要规划VPC网段、Pod网段和Service网段。三者不能冲突，而且创建之后很难修改。最常见的两个问题是：网段选得太小，后期节点扩容时IP不够用；或者与已有专线网段重叠，导致跨环境通信异常。这两个问题在上线初期不明显，等节点数量上去才会发作，事后处理的代价通常不小。
创建集群前，最好和网络团队一起确认未来三到五年的规模预估，为Pod网段留足余量。网络插件也要提前定。Terway支持为Pod分配弹性网卡IP，适合对网络性能和安全组隔离有要求的场景；Flannel方案相对简单，适合对这两点要求不高的业务。插件选错了，后续调整并不轻松，这一步不要图省事。
安全与权限：分层做，逐步收紧
安全是运行阶段要持续投入的部分。下面几个落点可以按顺序推进：
- RAM与RBAC分层：云账号权限走RAM，集群内的操作权限走Kubernetes RBAC，两层分开管理，避免一个账号什么都能做。
- 镜像扫描：在阿里云容器镜像服务ACR中开启镜像扫描，并在CI流程里拦截高危漏洞镜像，别等上线后才发现。
- 敏感信息不落YAML：数据库密码等不要明文写入清单文件，可以结合KMS或外部密钥管理服务注入。
- 默认拒绝的网络策略：用NetworkPolicy限制服务之间的访问，先整体默认拒绝，再按需放行。
收紧权限时，开发同学通常会有抵触。比较稳妥的做法是先在测试环境完整跑一遍，确认没有误伤，再逐步推到生产，同时保留审计日志，出了问题能回头查。
成本：从资源请求和节点池一起下手
很多团队在K8s上成本失控，根子往往在Pod的requests和limits没有设对。前面节点池一节已经提到这一点，这里补充几个具体动作：
- 非核心的离线任务可以放到抢占式实例上运行，计算成本会低不少，但要确保任务能容忍被中断。
- 弹性伸缩组件可以在低峰期自动缩减节点数量。前提是扩缩容阈值和HPA配置相互协调，否则节点数会来回抖动。
- 定期清理无用的PV、LoadBalancer和镜像。这些资源不会报错，但会悄悄计费。
发布与故障演练
发布推荐滚动更新或蓝绿发布，并配置就绪探针（readinessProbe）和存活探针（livenessProbe），让流量只进入已就绪的Pod。对关键服务，最好提前演练节点故障和可用区故障，验证PodDisruptionBudget和多可用区部署是否按预期生效。纸面配置和实际表现经常不一致，演练一次比反复看文档更有说服力。
集群配置、应用清单和基础组件统一放进Git管理，再用GitOps工具做声明式发布，是比较省心的做法。每次变更都有记录，回滚只需回退一次提交，出问题时也不用在多台机器之间翻找改动。
回到最初的问题，ACK上线后容易出问题的地方集中在节点池和网络规划两块。节点池要看规格、标签和扩缩容是否配套，网络要在建集群时就把网段和插件想清楚。两者都做到位，再加上分层的权限和标准化的发布流程，集群才能稳定地承接业务增长。
