最近经常有人问我阿里云 ACK 这种容器平台到底能不能扛住大模型的训练和推理问的人有做基础架构的也有刚把业务云原生化的小团队。大家下意识觉得AI 任务动辄几十张 GPU跑的是分布式批处理底层应该用高性能计算那一套普通 K8s 平台看着不够“硬核”。这个想法放在几年前还说得通现在基本可以放下了。阿里云 ACK容器服务 Kubernetes 版这轮升级核心就是把云原生底座延伸到智算场景做一个真正面向智算时代的现代化应用平台。下面我不会抄发布会的宣传文案而是从实际使用者的角度把升级后在调度、弹性、成本、安全几个维度的变化以及在迁移落地中踩过的坑一次讲清楚。这篇文章适合正在规划 AI 基础设施、准备从自建集群迁到托管集群、或者已经在 ACK 上跑微服务但想扩展 GPU 能力的开发者和平台工程师。1. 智算时代为什么需要一个“能算”的应用平台1.1 大模型任务不是特殊物种而是一群更挑剔的容器分布式训练任务跑起来之后你会发现它本质上还是那套容器编排逻辑一个 Job 启动若干个 Worker不同角色之间通过网络通信任何一个实例挂了都要自动重启。问题在于传统 K8s 对 GPU 资源的概念非常粗糙默认把一张卡当成一个只能整体分配的资源没办法按显存切分也没办法在多个小任务之间共享。这就导致很多 AI 团队拿到 K8s 集群后第一反应是“这平台跑微服务可以跑训练够呛”。我自己的体验是在物理机上直接跑训练最大的痛点是环境一致性。Python 版本、CUDA、cuDNN、依赖库稍有差异复现就变成灾难。容器把这些问题压缩成一个镜像而 Kubernetes 解决了“这个镜像应该在哪里跑、死了之后谁能拉起来”的问题。所以大模型训练和推理本质上还是一大群容器任务的组合只是它们对资源、网络、存储的要求更极端。ACK 的升级思路不是把 K8s 推翻重来而是在 K8s 的框架里补上这些极端场景需要的调度能力。1.2 托管版到底比自建强在哪自建 K8s 集群的苦只有维护过的人懂Master 节点高可用、etcd 备份、证书轮换、版本升级、集群故障恢复每一项都是实打实的运维负担。ACK 托管版把这层全部收走控制面由阿里云负责包括 API Server、etcd 的高可用和监控。对中小团队来说这几乎是决定性的选择——省出来的精力可以全部用来打磨业务应用。另一个容易被低估的点是云产品集成。ACK 跟底层 VPC、SLB、ECS、云盘、日志服务是原生打通的很多能力直接通过 CRD 和 Annotation 暴露出来不需要自己写一堆 controller。比如给 Service 挂一个 SLB只需要声明loadBalancerIP或service.beta.kubernetes.io/alicloud-loadbalancer-*注解。这种“云原生 阿里云基础设施”的粘合度是自建环境很难复制的。1.3 平台要同时服务两类人智算平台上的用户至少有两类一类是跑微服务的业务研发另一类是跑训练和推理的算法工程师。这两类人对平台的诉求完全不同。业务研发要稳定、便捷、好排查算法团队要高性能、高弹性、好调度。ACK 这次升级里一个很重要的变化是允许在同一个集群或一组节点池上同时服务两类负载而不是要求你为 AI 单独再搭一套平台。这个设计理念很关键。如果平台分裂成“微服务集群”和“AI 集群”两套运维模型会非常痛苦多一套集群就多一套监控、多一套告警、多一套权限管理。混部之后在线业务和白天的 CPU 峰值、训练任务和晚上的 GPU 长尾需求能互相错峰资源利用率提升明显。当然混部要搭配完善的资源隔离和驱逐机制这一点我在后面成本治理的章节会具体展开。2. 升级后最值得关注的四个能力变化2.1 从“按卡独占”到“按显存细粒度共享”的 GPU 调度以前想在一张 GPU 上跑多个小模型基本得手动设置CUDA_VISIBLE_DEVICES或者在物理机上做内核态隔离操作繁琐且容易出问题。ACK 的 GPU 共享调度把显存定义成可调度的扩展资源你在 Deployment 里声明需要多少显存调度器负责分配。比如一张 32GB 的卡跑两个需要 8GB 显存的推理服务各占一份不再需要为一个小模型独占整卡。我实际使用中比较典型的写法是这样的apiVersion: apps/v1 kind: Deployment metadata: name: gpu-share-demo spec: replicas: 1 selector: matchLabels: app: gpu-share-demo template: metadata: labels: app: gpu-share-demo spec: containers: - name: inference image: registry.cn-hangzhou.aliyuncs.com/your-app/inference:latest resources: limits: aliyun.com/gpu: 1 aliyun.com/gpu-mem: 8这里aliyun.com/gpu-mem是请求显存大小调度器会根据节点上剩余的 GPU 资源决定 Pod 落在哪台机器。要注意的是这种共享方式不等于性能隔离。如果不同推理服务对延迟特别敏感我还是建议用整卡或 MIG 方式避免因互相争抢算力导致 P99 延迟抖动。2.2 弹性扩容从“先扩容后跑”变成“边扩边跑”弹性伸缩有两种节奏。第一种是节点池层面的伸缩第二种是工作负载层面的 HPA。以往遇到突发算力时要等 ECS 实例创建出来、加入集群、再把 Pod 调度上去整体耗时经常在 3 到 8 分钟。对于在线推理服务来说这种分钟级的伸缩基本意味着流量已经损失了。ACK 升级后节点池弹性扩容和 ECI 的配合明显更顺滑了。ECI 可以理解为 Serverless 容器它不需要你预先创建 ECS 节点Pod 创建之后直接运行在托管的计算资源上。当节点池扩容速度跟不上工作负载扩容速度时队列里超出的 Pod 会自动调度到 ECI 上。我实测过同时拉起 200 个推理 Pod 做并发评测体感不到 1 分钟全部就绪。这个能力对压测、评测、周期性数据处理任务非常友好。2.3 运维视角从“看资源”走向“看业务”以前看 GPU 使用率只能看到节点层面的平均利用率。但训练任务卡住时GPU 利用率可能还在 90% 以上因为计算一直在空转loss 不降。运维同学看着监控面板很难判断这到底是“正在计算”还是“死循环”。ACK 的云原生 AI 套件默认带上任务级监控可以看到训练进度、日志、GPU 利用率、显存、网络吞吐还能直接查看几个 worker 是否健康。算法同学不用再 SSH 到容器里到处翻日志平台团队也能直接回答“这个训练任务什么时候能跑完”而不是只能说“有几张卡在用”。这个维度的切换对整个团队的协作方式有实打实的改善。2.4 安全隔离从“网络边界”下沉到“调度边界”智算平台最怕的是多团队共享时某个镜像或某个任务把宿主机搞挂。以往靠 Namespace 做软隔离效果有限。ACK 升级后Pod 安全策略、RuntimeClass 安全沙箱、镜像签名和供应链扫描、RAM OIDC 以及细粒度 RBAC 都变成了推荐配置。我服务过一个金融客户他们内部要求不可信镜像必须在安全沙箱里运行。做法是在 RuntimeClass 里指定安全沙箱然后通过策略强制某些命名空间下的 Pod 必须使用这个 RuntimeClass。这样即使镜像里有恶意代码也无法直接影响宿主机。对合规要求严格的行业来说这是决定能不能上生产的关键能力。2.5 与阿里云全栈能力的粘合度更高ACK 的价值从来不只是 K8s 本身。升级之后计算侧可以对接 ECS、ECI、超级计算集群存储侧支持 OSS、NAS、CPFS、云盘网络侧支持 Terway ENI 直通安全合规可以直接接 ActionTrail、云安全中心。再往上还有阿里云百炼负责模型服务PAI 负责建模实验。ACK 在中间扮演通用算力编排的角色。平台团队如果只想选一个底座同时又想留出后续接入上层 AI 平台的空间那 ACK 是接受度最高的方案。它不会逼你在早期就把模型部署方案定死而是先把容器编排、资源调度、弹性伸缩这些底层能力打好后续再逐步演进。3. 从自建 K8s 迁移到 ACK 的实操路径与排坑记录3.1 迁移前必须回答的四个设计问题第一个问题一个集群还是多个集群我的建议是生产集群和测试集群分开AI 和微服务可以共用生产集群但用节点池做物理隔离。我们最终采用的方式是生产集群 测试集群AI 和微服务在同一个生产集群内但通过节点池拆分CPU 节点池给微服务GPU 节点池给训练和推理。原因是这两类负载的峰值时间不同混部能错峰共享资源。第二个问题容器网络选 Terway 还是 FlannelACK 默认推荐 Terway它基于 ENI 给 Pod 分配独立网卡网络延迟更低还能配合安全组做 Pod 粒度的访问控制。自建集群如果还在用 Flannel迁移前最好先规划好 VPC 和交换机网段避免和现有业务网段冲突。第三个问题存储怎么选不同存储类型对应不同场景我整理了一个常用对照表存储类型典型场景注意事项云盘数据库、有状态服务的本地数据单节点读写容量固定不能多 Pod 共享NAS多 Pod 共享文件、代码、日志吞吐比 CPFS 低适合普通共享场景OSS模型文件、数据集的低频归档大量小文件性能差需要配合缓存CPFS大规模分布式训练成本高性能要求极高时使用我们实践中比较顺手的组合是代码和配置放 ACR 和 ConfigMap数据集放 OSS Fluid 缓存模型权重放 OSS训练 checkpoint 写 NAS日志直接走 SLS。第四个问题安全策略怎么设提前定义 Namespace、ResourceQuota、LimitRange避免一个团队的任务把集群资源全部占完。特别是 GPU 资源一定要给每个团队设置上限否则某个团队一个误操作就能把集群的 GPU 全抢走。3.2 迁移中容易被忽视的四个坑坑一镜像拉取超时。自建环境直接从 Docker Hub 拉镜像很快上了 ACK 后经常遇到ImagePullBackOff。原因是集群节点访问公网镜像源不稳定。解决办法很简单把业务镜像同步到 ACR集群通过 VPC 内网拉取。如果是第三方基础镜像先转存到 ACR 再同步。坑二GPU 驱动和 runtime 版本不匹配。新建 GPU 节点池后Pod 创建成功但容器内执行nvidia-smi直接报错。排查下来是节点池基础镜像里的驱动版本和容器内 CUDA 版本对不上。建议直接用 ACK 官方推荐的 GPU 镜像并保持 aliyun-acn 插件版本和集群版本兼容不要自己手工处理驱动。坑三RDS 连接被打满。微服务迁入集群后大量 Pod 同时连接 RDS连接数很快到上限业务开始报错。代码里要使用连接池给数据库实例预留足够连接数必要时加一层数据库代理。另外数据库密码不要写死在环境变量里用 K8s Secret 配合 KMS 或 external-secrets 管理。坑四存储性能不达预期。早期我们把 OSS 直接当训练数据目录跑小文件密集的 dataloader 时性能低到怀疑人生。后来用 Fluid 做数据集缓存把热数据缓存到节点本地盘训练速度提升了 4 倍以上。这个经验值得记下来OSS 不是不能用来训练而是要用对方式。3.3 一次实际迁移的时间线备忘以一套 30 个微服务加 2 个训练任务的自建集群为例我们的节奏大致是第一周做资源清单和元数据梳理包括所有 Deployment、Service、ConfigMap、StatefulSet第二周搭建 ACK 测试集群同步镜像改造 YAML第三周做业务灰度迁移和压测重点验证存储和网络性能第四周正式割接。如果想压缩时间最值得提前做的是把 YAML 里的旧版 API 升级到新版本比如extensions/v1beta1的 Ingress 全部改成networking.k8s.io/v1。另一个提前要验证的是 GPU 节点池的插件状态先在测试环境把 GPU 跑通比什么都重要。4. 把 ACK 用出性价比弹性伸缩、成本治理和“省钱三板斧”4.1 弹性伸缩策略要分层设计别只靠一个 HPA很多团队一说到弹性第一反应是配一个 HPA实际上这远远不够。我的经验是至少分三层第一层是工作负载 HPA按 CPU、内存或 QPS 伸缩第二层是集群节点自动伸缩工作负载扩容后节点不够时要能自动扩第三层是 ECI 喷发当节点池扩容跟不上时用 Serverless 容器承接临时算力。一个常见的 HPA 配置长这样apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: online-inference spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: online-inference minReplicas: 2 maxReplicas: 20 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70这里一定要关注behavior里的stabilizationWindowSeconds也就是缩容稳定窗口。如果不设置流量一抖动副本数会频繁增减反而影响稳定性。我见过不止一次因为 HPA 频繁伸缩导致发布时 Pod 反复重建的案例。4.2 Spot 实例专门承接“跑挂了也无所谓”的任务AI 训练中有很多任务是可以容忍失败的比如模型评估、批量评测、数据清洗、超参搜索。这些任务天然适合用抢占式实例。ACK 节点池支持 Spot 实例配合 Pod 的restartPolicy和任务的 checkpoint 机制即使节点被回收任务也能从最近一次保存的状态继续。但要注意不是所有任务都适合 Spot。不间断的主训练任务或者对显存连续性要求很高的推理服务建议还是用包年包月或按量付费的 GPU 实例。否则节点被回收后任务频繁重试浪费时间成本反而得不偿失。4.3 成本分析别到月底再看账单要实时盯ACK 自带成本分析功能可以按集群、命名空间、工作负载聚合资源消耗并生成对应的成本报告。我们给每个业务线一个独立的 Namespace并统一打上team、project标签。月底导出成本报告哪个团队用了多少 GPU、多少 CPU、多少存储一目了然。这才叫成本治理落到人。否则平台团队每个月只能对着账单总数一脸懵不知道成本是从哪儿涨起来的。4.4 混部是省钱的大头但要控制资源争抢在线微服务的波峰一般在上下午训练任务更多在晚上。如果各建一套集群资源利用率很难上去。我们把训练任务设置为低优的 BestEffort 或 Burstable通过 CPU 亲和性、弹性配额和 GPU 节点池错峰调度把在线业务的空闲资源利用起来。混部的前提是监控体系足够完善。一旦在线业务出现明显时延升高平台必须能快速定位是不是被低优任务抢了 CPU然后立刻驱逐或降级。我们一开始混部时踩过坑低优任务把宿主机 CPU 跑满导致在线服务 P99 延迟翻倍。后来给低优任务加了 CPU 和内存限额并开启抢占优先级情况才稳定下来。5. 生产环境的安全底线多租户隔离、镜像供应链和审计5.1 多租户隔离Namespace、ResourceQuota、NetworkPolicy 三件套K8s 的 Namespace 只是逻辑边界真正要落地隔离必须配合 ResourceQuota 限制资源占用配合 NetworkPolicy 限制 Pod 间通信。比如不同业务线的 Pod 不能互相访问默认拒绝所有东西向流量只放行同一命名空间内的必要访问。在 ACK 上启用 NetworkPolicy 之后我们可以把默认策略设置成拒绝再按业务需求逐条放开。这个过程要在一开始就做好等业务上线再补策略会频繁出现“网络不通”的投诉团队心态很容易崩。5.2 镜像供应链扫描、签名、白名单镜像来源越杂风险越高。生产环境一定要在 ACR 上开启镜像扫描并把高危漏洞的镜像加入拉取拦截。重要业务最好使用镜像签名K8s 端通过策略强制执行。我见过一个案例某团队为了省事从公网仓库拉取了一个好久没更新的基础镜像结果内部扫描发现存在多个高危漏洞。虽然短期内没出事但这种风险谁也不想赌。建议把镜像同步和扫描阶段放进 CI 流水线每一次构建都自动扫描高危直接阻断发布。5.3 审计与合规ActionTrail 加 Kubernetes API 审计平台团队最怕的是出了事说不清楚是谁改的。ACK 控制面的操作会写入 ActionTrail集群内部的 API 操作可以通过开启 Kubernetes 审计日志写入日志服务。建议把审计日志长期归档平时不查出问题时它就是唯一的还原手段。有一次我们排查线上配置被意外修改就是靠审计日志定位到某个同学在某时刻执行了一条kubectl scale命令。没有这个日志很难追责更别提复盘和改流程。6. 组建平台工程团队让 ACK 从“能用”走向“好用”6.1 给算法工程师提供自助式体验ACK 底层能力再强如果算法工程师每次跑任务都要提工单让平台同学执行命令平台一定会成为瓶颈。我们基于 ACK 做了一层自服务入口提供几个常用的工作负载模板算法同学填写资源需求、镜像地址、副本数点击提交就自动生成对应的 Deployment、Service、Ingress同时自动注入监控和日志采集的注解。这层封装不复杂核心是把最佳实践固化到模板里比如统一加resources.requests和limits、统一加健康检查探针、统一加 Pod 反亲和性。这样既保留 K8s 的灵活性又大幅降低使用门槛。6.2 GitOps 是配置管理的兜底所有集群配置、工作负载 YAML、Helm Release 都统一放在 Git 仓库里通过 Argo CD 或阿里云 flow 对接 CI/CD。一旦出问题可以快速回滚到上一个可用 commit。我们经历过一次事故有人手动改了线上 Deployment 的副本数结果忘记回滚凌晨流量高峰时资源不足业务直接报警。上了 GitOps 之后这类问题基本绝迹因为仓库里的 YAML 才是唯一真实状态手动改动会被自动覆盖。6.3 可观测性要一开始就建好APM、日志、监控、链路追踪这四类能力如果不在项目一开始选型后面再补会非常痛苦。ACK 本身的 Metrics 和事件可以通过 ARMS、SLS 和 Prometheus 接入。强烈建议把集群事件、审计日志、应用指标接入同一个看板排查问题时不用反复切换控制台。另外告警规则一定要结合实际场景设计不要全平台只配一个“节点 CPU 高”的通用告警。我们后来把告警收敛成三类可用性告警、性能告警、成本告警每一类都有明确的负责人告警量少了处理效率反而高了。最后分享一个我自己的习惯每次 ACK 控制台或组件有新版发布我都会先在测试集群里升级重点看 GPU 插件、Terway 和 CNI 的兼容性说明再决定是否滚动到生产。生产集群的升级尽量选在业务低峰并且提前做好快照和回退方案。智算时代给云原生带来的不是另一套新概念而是把已有的调度和弹性能力用到极致。如果你也正在纠结要不要把 AI 负载放到 ACK 上建议先从一个评测任务或推理服务开始跑通后再逐步扩大边界这条路比想象中要平滑很多。