早两年我们部署 CubeStudio 的时候就是一台高配服务器加一块大显卡装个 Kubernetes 单机版然后把 Jupyter 类型的交互环境挂上去几个算法同事用着也没觉得有什么问题。真正逼我动手改架构的是三个非常具体的业务信号第一同时跑训练任务的人一多单机上的 CPU 和 GPU 直接被打满谁的环境都慢第二机器一重启所有用户的 Notebook 和正在执行的训练全部断掉平台相当于整体挂了一次第三公司又组建了新项目组新组要在平台上单独做环境隔离和算力核算单机 Kubernetes 在 namespace 和资源配额上极其难搞。后来我把这套平台从单机扩成多机、接入多个 K8s 集群并且按项目组分算力池子过程踩了不少坑也沉淀了一套可以落地的实操路径。这篇文章会把我整个迁移过程中的设计思路、节点调度细节、多集群纳管方式、资源组分算力的配额方案以及真实遇到过的问题一一摊开来讲。适合正在做同类 ML 平台、想从“单机演示”走向“多机多集群生产环境”的运维或平台工程师也适合需要理解底层隔离逻辑的数据团队负责人。1. 先想清楚单机到多机平台架构到底缺了什么很多团队一上来就急着加机器、加集群其实没想明白单机环境的限制到底在哪。如果只是“机器不够用了”这一个原因那加几台服务器、把组件拆开跑也能撑一阵子。但 CubeStudio 这类平台和普通 Web 站点有本质区别它承载的不是无状态接口而是用户长久运行的交互式环境、GPU 训练任务和数据卷的持续挂载。1.1 单机走不远的四个真实信号单机部署最直接的问题是单点故障。机器重启、网络波动、磁盘写满任何一个动作都可能把平台上所有实时任务中断掉。我记得有次机房整体断电演练回来以后用户埋怨了很久因为大家都以为平台会自动恢复结果发现跑了一天的模型全没了。单机架构里平台组件和用户任务在同一台机器上任何组件出问题都会互相拖累。第二个信号是 GPU 资源利用率极度不均。有人申请了一张卡但只写代码不用有人同时在三个环境里并发训练单机环境下很难做比较细的资源回收和再分配。更麻烦的是单机 GPU 卡数有限一旦需求超过物理上限只能靠人为排队或者让用户相互协调这在多项目组并行的情况下基本不可接受。第三个信号是环境隔离形同虚设。单机 K8s 当然可以用 namespace 区分用户但底层磁盘、内核资源、GPU 显存都没有真正的租户边界。一个用户的训练代码写崩了可能把整张卡的风扇转速打满隔壁用户温度报警一个用户装了莫名其妙的 kernel module整个节点的内核态就开始不稳定。第四个信号是扩容路径被写死。单机就是单机加第二台机器时存储、调度、网络、镜像拉取全部要重新设计。不要说你要引入多集群就是同机房再加一个节点原有的平台组件和服务暴露方式也得改造。1.2 目标状态资源池化、故障域分离、租户隔离在动手之前我把目标拆成了三层。第一层是“多机”指一个 K8s 集群内有多个工作节点平台组件和用户任务可以分开调度节点可以按型号、用途划分成不同的资源池。这一层解决的是资源容量和单点故障的问题。第二层是“多集群”指平台控制面能够纳管多个独立的 K8s 集群。这些集群可能在不同机房也可能在同机房但独立运维。多集群不是为了炫技而是为了扩大故障域隔离范围顺带解决跨区域团队就近接入的问题。第三层是“多资源组”指在平台上层按项目组、部门或成本中心把物理资源划分成逻辑资源组。用户申请算力时不再直接选节点或集群而是选自己的项目组平台负责把申请映射到对应的底层集群和节点池并做配额校验。这个三层状态设计清楚之后后面每一步动作都变得有据可依。不会再出现“为了加一台机器把平台搞成一团乱麻”的情况。1.3 关键选型原则用 K8s 当底座但不被底座绑架无论多机还是多集群K8s 作为底座基本没有悬念。CubeStudio 本身所有计算环境都以 Pod 形态运行天然适合 Kubernetes 的资源模型。但我要特别强调一个原则平台只依赖 Kubernetes 的稳定核心能力不要绑定某个特定发行版、特定网络插件或者特定调度插件。原因很简单多集群环境下各个集群的交付方往往不一样。有的集群可能是机房运维用某套标准安装工具建的有的可能是云服务商托管的。如果 CubeStudio 强依赖某个网络插件或者某个存储类型接入新集群时就会非常痛苦。我在设计上只依赖四类能力Pod 调度、Service/Ingress 暴露、PVC 存储、ResourceQuota 配额校验。这四个能力在所有标准 Kubernetes 发行版上都是可用的。2. 多机部署的关键动作节点分区、调度策略与 GPU 分配多机部署本质上就是在 K8s 集群里把节点规划好让平台组件和用户 Pod 都按照你的意图落在合适的位置。这里有几个核心步骤顺序不能乱。2.1 节点角色分离打标签和污点的时机与细节节点标签和污点需要在一开始就规划好不然后期调整非常痛苦。我的习惯是把所有节点先打上三层标签用途层、硬件层、归属层。用途层用 role 字段区分比如 roleplatform 跑平台自身组件rolecompute 跑用户 Pod。硬件层用硬件型号和算力类型比如 gpuA100、cpu64c。归属层用资源组标识比如 groupalg-team-a这个标签是后面按项目组分算力的基础。标签只是“偏好”真正强制隔离要用污点。平台组件所在节点要加 taint 让用户 Pod 默认不往上面跑反过来计算节点如果不想让平台固定组件占用资源也可以加 taint 只放行带有对应 Toleration 的 Pod。实际操作用 kubectl 就能完成kubectl label node node01 node-role.kubernetes.io/platform kubectl taint nodes node01 dedicatedplatform:NoSchedule注意污点配 Toleration 时要精确不要图省事用一个宽泛的 key。我见过有同事给所有节点打了同一个污点结果平台组件调度器一启动就被自己堵住。建议的节点规划表大概是这样的节点组标签示例污点承载对象平台节点roleplatform, groupinfradedicatedplatform:NoSchedule平台 API、调度器、数据库、监控GPU 计算节点 Arolecompute, gpuA100, groupalg-agputrue:NoSchedule项目组 A 的训练 PodGPU 计算节点 Brolecompute, gpuA100, groupalg-bgputrue:NoSchedule项目组 B 的训练 PodCPU 计算节点rolecompute, cpu64c, groupshared无轻量 Notebook、数据处理任务2.2 调度配置让对的 Pod 落到对的节点节点标签打好之后最关键的是把 Pod 调度策略配置正确。CubeStudio 本身会为用户创建工作负载所以平台侧需要在创建工作负载时注入调度约束而不是让用户手动改 YAML。最常用的是 nodeSelector 和 nodeAffinity。nodeSelector 精确但呆板适合硬性归属nodeAffinity 灵活可以设置 operator支持 In、NotIn、Exists 等条件。在多资源组场景下我给每个用户工作负载注入的是 nodeAffinity 的 requiredDuringSchedulingIgnoredDuringExecution强制匹配项目组对应的节点标签。affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: group operator: In values: - alg-team-a这里有个非常重要的经验不要完全依赖亲和性来做资源组隔离。亲和性只是调度偏好资源组隔离必须以配额校验为准调度约束是辅助手段。你要是只配亲和性、不配配额用户完全可以直接创建一个没有亲和性字段的裸 Pod绕过平台调度逻辑跑到任何节点上去。2.3 GPU 资源如何上报、申请与切分GPU 是这类平台最核心、最容易出问题的资源。多机环境下GPU 不是简单地“插一张卡就能用”而是需要设备插件机制把物理 GPU 上报给 Kubernetes让调度器知道节点上有几张卡、每张卡多少显存然后以可分配资源的形式给 Pod 申请。我使用的是一套基于 NVIDIA 设备插件的标准方案。在 GPU 节点上正确安装驱动和容器运行时后再部署 Device Plugin节点上就会自动出现类似 nvidia.com/gpu 这样的可计数资源。用户 Pod 只需要在 limits 里声明这张卡调度器就会把 Pod 绑定到具体有对应 GPU 的节点。但 GPU 切分这块不同项目组的策略不一样。有的组需要整卡隔离申请就是 1不能多也不能少有的组则想做显存细粒度切分把一张卡分成几份给多个轻量任务用。我的建议是初期保持整卡隔离运营稳定后再考虑显存切分。原因很简单显存切分在调度和故障隔离上非常容易出“显存碎片化”和“复用时显存泄漏”问题投入产出比不划算。3. 多集群纳管的实现路径统一认证、统一入口和数据面打通多集群纳管是让我最费心思的一块。因为“能连上多个集群”和“真正把多集群作为一个整体平台来运营”是两码事。如果你只是把几个 kubeconfig 文件堆在一起让用户手动选集群那不叫纳管叫跳板机。3.1 kubeconfig 聚合只是第一步权限模型要单独设计平台要纳管多个集群第一步肯定是维护多个集群的接入信息。K8s 支持 kubeconfig 里用 context 来区分集群但在这里我建议不要直接把管理员 kubeconfig 塞给平台。你想平台接手用户的 Pod 创建请求如果它自己拿着集群管理员权限一旦平台侧被人提权所有纳管的集群全部沦陷这个风险太大了。正确的做法是为 CubeStudio 平台单独创建一套用于“平台代理”的 ServiceAccount并授予最小权限。平台需要什么权限就授予什么权限比如创建 Pod、读取节点状态、读写 PVC、查看 namespace 配额等。这样平台对集群的访问是受控的、可审计的。我实际维护的是一个多集群接入表每接入一个新集群都会确认四件事API Server 地址是否内网可达、平台用的 ServiceAccount 是否存在、集群的 storageclass 是否就绪、集群的 Prometheus 监控是否已对接到中心。任何一个不满足我不会让这个集群进入可用状态。3.2 统一入口与服务跨集群暴露多集群环境下最挠头的是用户怎么访问到自己的环境。同一个用户在集群 A 里开了一个 Notebook在集群 B 里开了一个训练任务如果两个集群各自暴露入口用户就得记住两个域名多集群等于把复杂度转嫁给了用户这肯定不行。我采用的是统一 Ingress 入口方案平台有一个全局域名入口根据用户请求中的路径或子域名把流量转发到对应集群的 Service 上。也就是说用户访问 Notebook 时始终是同一个地址平台在背后做了一层位置透明的映射。这个映射层需要解决 kubernetes 集群内容器的网络互通问题。我的经验是不强制要求所有集群的 Pod 网络完全打通只要平台入口到各个集群的 Service 网络可以打通即可。换句话说平台转发节点和目标集群的 Service 网段之间要有路由规则。这一层用传统负载均衡或者 Ingress Controller 都可以实现关键是不要走公网裸 IP否则证书、防火墙、审计都会很麻烦。3.3 跨集群调度的两种常见模式跨集群调度是整个多集群里最容易为了技术而技术的部分。实际上我见过可落地的模式无非两种。第一种叫“控制面分发、集群内落地”。平台维护一个全局调度器它负责决定用户任务放到哪个集群然后调用目标集群来创建 Pod。集群内部仍然由本集群的默认调度器来决定 Pod 落到哪台节点。这种模式实现简单、故障域清晰适合绝大多数场景。第二种叫“聚合资源池调度”。把所有集群的节点抽象成一个大的资源池调度器把 Pod 直接调度到某集群的某节点上。这种模式资源利用率最高但对网络、存储、监控的一致性要求极高一旦集群间网络抖动或存储延迟超标问题排查会非常痛苦。我们线上一直用的都是第一种。全局调度器只关注集群级的资源余量和队列情况不做节点级细致调度。节点级问题让集群自己的调度器去处理各有各的职责边界。3.4 多集群存储与网络的基本选择多集群和存储的关系是避不开的。这里有一个很实在的取舍如果你所有集群共用一套高速共享存储那是架构上的大工程如果每个集群各自有本地存储用户数据在集群之间迁移就得靠导出导入体验有损。我目前的策略是“核心成果集中、中间产物就地”。用户长期保存的数据集、模型、代码仓库放集中式共享存储训练中间产物允许写本地临时目录。这样即使集群故障核心数据不丢只是重启任务代价可控。网络层面多集群不要求 Pod 网段一致甚至可以重叠前提是平台入口做映射时不要依赖 Pod IP而是通过 Service 名称和端口访问。重叠网段的情况下内部 DNS 必须能够准确区分上下文否则很容易出现访问到错误集群的 Service。4. 按项目组分算力的落地方案Namespace 边界、配额体系和标签路由这一部分是我们平台从“所有人共用一台机器”走向“多租户资源治理”最核心的一步也是我踩坑最多的部分。按项目组分算力不是简单地在界面上加一个“工作组”选项就可以而是要在调度链路上真正落实隔离。4.1 为什么选 Namespace 作为资源组边界在 Kubernetes 里给项目组划定资源边界最标准的方式就是 Namespace。每个项目组分配独立的 Namespace平台在创建用户环境时直接写到该组的 Namespace 下用户只能看到自己组内的 Pod、服务和存储。选择 Namespace 而不是虚拟机级别的物理隔离原因很直接全平台的工作负载形态已经是 Pod 了Namespace 隔离在容器层面足够应对大多数场景而且 Kubernetes 原生的 RBAC、ResourceQuota 都能直接附着在 Namespace 上管理成本最低。真正要物理隔离的敏感数据不应该通过平台算力分发来解决而是通过网络策略和存储权限来实现。这里有一个容易忽视的坑Namespace 隔离不等于网络隔离。同一个 Namespace 内的 Pod 默认可以互通但不同 Namespace 之间如果网络策略开放一样互访。如果你要给项目组做数据安全隔离必须配合启用 NetworkPolicy而不是单纯分组完事。4.2 ResourceQuota 与 LimitRange 的设计ResourceQuota 是平台按组分算力的核心落地工具。在 Kubernetes 中ResourceQuota 可以限制一个 Namespace 内的 CPU、内存、GPU 数量也可以限制 PVC 数量、Service 数量等。收到项目组资源的申请后我会先按“整节点等价资源”换算。举个例子项目组 A 申请了 2 个节点每台节点 64C 512G 带 4 张 GPU 卡。那么配额可以这样设置apiVersion: v1 kind: ResourceQuota metadata: name: quota-alg-a namespace: alg-team-a spec: hard: requests.cpu: 64 requests.memory: 512Gi limits.cpu: 96 limits.memory: 768Gi requests.nvidia.com/gpu: 4这里我没有直接开满 128C而是留了 25% 左右的弹性余量。为什么因为用户提交的资源申请多数是 limits 偏高requests 偏低如果把 Limits 开满一旦同一组内的任务批量拉起节点 CPU 打满、调度器会开始驱逐用户体验会很差。留余量是为了给调度器的驱逐机制和节点自身系统进程留缓冲。与之配套的还有 LimitRange用来约束单个 Pod 的最小和最大资源申请防止某个用户一次性申请了整组的全部配额导致其他人没资源可用。我给每个项目组都配置了默认限制apiVersion: v1 kind: LimitRange metadata: name: limit-range-alg-a namespace: alg-team-a spec: limits: - default: cpu: 8 memory: 32Gi defaultRequest: cpu: 1 memory: 4Gi max: cpu: 16 memory: 64Gi min: cpu: 0.5 memory: 1Gi type: Container4.3 标签路由让配额和物理资源池对应起来配额只是逻辑上的上限最终 Pod 还需要落到具体具备相应资源的节点上。这时候就要把“资源组”概念延伸到节点标签。每个项目组对应一个节点标签组然后通过前面说的 nodeAffinity 强制绑定。这意味着即使平台因为 Bug 或人为误操作把一个项目组的 Pod 创建到了另一个项目组的节点上调度也是失败的。标签路由配合配额形成了一个软硬兼施的隔离体系。这里要注意必须定期核对节点标签与资源组配额的一致性。曾遇到过节点运维同事重装系统之后节点标签丢失导致某个项目组的任务全部 Pending。这种问题不能用自动化一劳永逸最好在平台里有一个人工复核界面专门展示“每个项目组实际可用节点列表”。4.4 配额从核算到发放的流程配额不能只靠运维拿 kubectl 敲。平台侧我实现了一个简单的审批流项目组发起资源申请平台自动核算申请是否在集群剩余容量允许范围内然后生成 ResourceQuota 和 LimitRange 的变更请求由管理员审批后下发到目标集群。这个流程的好处是可以留审计记录而且避免“谁手快谁多占”。团队成员之间以此为据做成本分摊也让算力提供方和算力使用方有了明确边界。在核算配额时我有一个粗算公式可分配量 节点数 × (单节点可分配 CPU - 系统保留 0.5C - 平台保留 0.5C)。内存类似GPU 卡数直接减掉每节点 0 或 1 张以防止节点上某些并行任务把显存占满导致系统卡死。这套粗算虽然不精确但足够避免“超额售卖后撞车”。5. 平台侧打通部署拓扑、监控聚合与高可用配置把前面几层做完架构基本具备但距离“平台稳定运营”还差一截。多机多集群的资源调度有了配额有了接下来要把平台自身的部署拓扑、监控和告警串起来。5.1 一条完整的算力分发链路长什么样链路是这样的用户登录 CubeStudio选择项目组提交计算环境或训练任务。平台 API 收到请求后先检查该用户在项目组命名空间下的资源占用情况判断是否超出配额然后在全局集群列表中过滤出至少满足资源需求的可用集群再决定把工作负载发送到目标集群的对应 Namespace 下。在目标集群内部Kube Scheduler 根据 nodeAffinity 将 Pod 调度到带有人群标签的节点。Pod 启动后平台在入口处把访问链接回传给用户。整个链路中配额判断发生在“入口”节点绑定发生在“目标集群内”两个环节相互独立。这样做的好处是全局集群列表挂了只能影响新任务的发放已经在跑的老任务不受影响目标集群本身挂了也只影响本集群的任务不会连坐其他集群。5.2 监控聚合与资源计费多集群多资源组一旦跑起来监控就必须打聚合。我是用中心化 Prometheus 抓取各个集群指标的方式把集群维度、Namespace 维度、Pod 维度的 CPU/内存/GPU/网络指标统一汇入平台时间序列库。按项目组分析算力消耗时我通常用 namespace 维度来做。仪表盘上展示三张表全局集群资源总览、项目组配额使用率排行、异常资源占用 Top N。这三张表基本能支撑日常运维判断到底是“节点不够”还是“任务写歪了”。另外建议在每个项目组配额使用率达到 80% 的时候就发通知而不是等到 100% 被拒绝才让用户来找你。通知要发到项目组接口人而不是所有人避免告警疲劳。5.3 高可用和升级节奏平台自身的组件全部部署在带污点隔离的专用节点上副本数至少 2配置了 PodAntiAffinity 让副本不落同一台机器。数据库和对象存储属于有状态服务我对这部分做的是定时备份和冷备恢复演练而不是轻易搭建分布式方案因为平台组件的有状态部分规模不大复杂方案反而增加故障点。升级多集群时我坚持一次只升级一个集群。先把最小集群升级完、跑几天测试任务确认稳定之后再推广到其他集群。多集群很容易让人想用“一键全量升级”但真实生产里多个集群的 API 版本、插件版本往往不完全一致全量升级一旦出问题连回滚都非常复杂。6. 常见问题速查部署、调度、配额里的高频坑以下是我在迁移和运营过程中碰到过的高频问题按典型程度整理出来方便以后排查时照着操作。现象根本原因排查命令解决动作新增节点后任务不往新节点上调度节点标签缺失或者没有移除污点kubectl describe node x检查 label 和 taint重新打标项目组任务全部 PendingResourceQuota 达到上限或者 nodeAffinity 没匹配kubectl describe pod x -n ns检查 quota 用量和节点标签GPU 任务启动报 UnexpectedAdmissionError容器运行时缺少 GPU 设备插件kubectl logs -n kube-system device-plugin重新部署设备插件核对驱动版本平台可以连上集群但创建 Pod 失败平台 ServiceAccount 权限不足kubectl auth can-i --list补齐最小权限并重新授予用户访问 Notebook 偶尔超时跨集群 Ingress 转发链路不稳定检查集群到平台入口网络路由增加超时重试并检查防火墙规则配额明明没满但任务被拒绝项目组各自配了独立 quota 且平台校验的是全局用量查看平台日志里的配额判定逻辑统一配额校验口径6.1 最容易踩的坑节点标签被别人改掉节点标签是整个调度体系里最脆弱的一环因为任何一个有集群权限的同事都可以通过 kubectl label 修改。我遇到过一次某同事在清理机器时顺手把标签写成了 rolecompute, group结果某个项目组的任务全部 Pending排查花了整整半天。后来我给平台加了一个定时巡检脚本每隔十分钟核对一次节点标签和预期规划不一致直接告警。6.2 最容易忽略的坑配额只限制 requests 不限制实际使用ResourceQuota 里如果只配置 requests.cpu 而不配置 limits.cpu用户任务可以把实际 CPU 使用打得很高因为 Kubernetes 限制的是 CPU 时间片而不是配额。特别是跑数据处理任务时有些库开了多线程CPU 飙到 100%同一个 Namespace 内其他任务响应就会变得极慢。所以配额里 requests 和 limits 必须同时配两者之间的差值要小于等于节点的弹性余量。6.3 关于“算力不够”的提前量很多项目组反馈算力不够其实不是物理资源真的不够而是配额分配策略偏保守或者某个任务长期占着资源不放。我的经验是每月做一次资源使用率复盘把每个项目组的配额申请量和实际使用量放一起看及时回收明显富余的配额。同时对长期运行但利用率极低的 Pod要敢于制定策略定期提醒用户让他们停掉闲置环境而不是一次性扩容到位。7. 写在最后这套拓扑还可以怎么扩展多机、多集群、多资源组改造做完之后平台的运营状态比之前好了不止一个量级但并不是说这套架构就一劳永逸了。我个人体会最深的一点是多集群和资源组最难的其实不是技术细节而是把“资源治理”这件事放到团队日常流程里。没有资源申请的审批流、没有月度复盘、没有持续巡检无论架构多漂亮最终都会退化回“谁的嗓子大谁多用”。如果后续还要扩展我计划从两个方向入手一是在多集群之上建立跨集群队列让同一个项目组的任务可以按优先级和排队策略在多个集群间动态分布二是做更细致的按项目的成本核算把 GPU 卡时数、存储容量、网络流量统一折算成成本数据反馈给各团队做预算管理。这两个方向不是必须但一旦组织规模上来它们会是下一个卡点。最后分享一个小技巧每次调整节点标签、配额或集群接入信息后都手动跑一遍“调度演练”也就是用一个空 Pod 模拟真实任务的标签和资源申请确认它能落到预期节点。这个动作花不了两分钟却能把绝大部分配置问题拦截在用户反馈之前。
早两年我们部署 CubeStudio 的时候就是一台高配服务器加一块大显卡装个 Kubernetes 单机版然后把 Jupyter 类型的交互环境挂上去几个算法同事用着也没觉得有什么问题。真正逼我动手改架构的是三个非常具体的业务信号第一同时跑训练任务的人一多单机上的 CPU 和 GPU 直接被打满谁的环境都慢第二机器一重启所有用户的 Notebook 和正在执行的训练全部断掉平台相当于整体挂了一次第三公司又组建了新项目组新组要在平台上单独做环境隔离和算力核算单机 Kubernetes 在 namespace 和资源配额上极其难搞。后来我把这套平台从单机扩成多机、接入多个 K8s 集群并且按项目组分算力池子过程踩了不少坑也沉淀了一套可以落地的实操路径。这篇文章会把我整个迁移过程中的设计思路、节点调度细节、多集群纳管方式、资源组分算力的配额方案以及真实遇到过的问题一一摊开来讲。适合正在做同类 ML 平台、想从“单机演示”走向“多机多集群生产环境”的运维或平台工程师也适合需要理解底层隔离逻辑的数据团队负责人。1. 先想清楚单机到多机平台架构到底缺了什么很多团队一上来就急着加机器、加集群其实没想明白单机环境的限制到底在哪。如果只是“机器不够用了”这一个原因那加几台服务器、把组件拆开跑也能撑一阵子。但 CubeStudio 这类平台和普通 Web 站点有本质区别它承载的不是无状态接口而是用户长久运行的交互式环境、GPU 训练任务和数据卷的持续挂载。1.1 单机走不远的四个真实信号单机部署最直接的问题是单点故障。机器重启、网络波动、磁盘写满任何一个动作都可能把平台上所有实时任务中断掉。我记得有次机房整体断电演练回来以后用户埋怨了很久因为大家都以为平台会自动恢复结果发现跑了一天的模型全没了。单机架构里平台组件和用户任务在同一台机器上任何组件出问题都会互相拖累。第二个信号是 GPU 资源利用率极度不均。有人申请了一张卡但只写代码不用有人同时在三个环境里并发训练单机环境下很难做比较细的资源回收和再分配。更麻烦的是单机 GPU 卡数有限一旦需求超过物理上限只能靠人为排队或者让用户相互协调这在多项目组并行的情况下基本不可接受。第三个信号是环境隔离形同虚设。单机 K8s 当然可以用 namespace 区分用户但底层磁盘、内核资源、GPU 显存都没有真正的租户边界。一个用户的训练代码写崩了可能把整张卡的风扇转速打满隔壁用户温度报警一个用户装了莫名其妙的 kernel module整个节点的内核态就开始不稳定。第四个信号是扩容路径被写死。单机就是单机加第二台机器时存储、调度、网络、镜像拉取全部要重新设计。不要说你要引入多集群就是同机房再加一个节点原有的平台组件和服务暴露方式也得改造。1.2 目标状态资源池化、故障域分离、租户隔离在动手之前我把目标拆成了三层。第一层是“多机”指一个 K8s 集群内有多个工作节点平台组件和用户任务可以分开调度节点可以按型号、用途划分成不同的资源池。这一层解决的是资源容量和单点故障的问题。第二层是“多集群”指平台控制面能够纳管多个独立的 K8s 集群。这些集群可能在不同机房也可能在同机房但独立运维。多集群不是为了炫技而是为了扩大故障域隔离范围顺带解决跨区域团队就近接入的问题。第三层是“多资源组”指在平台上层按项目组、部门或成本中心把物理资源划分成逻辑资源组。用户申请算力时不再直接选节点或集群而是选自己的项目组平台负责把申请映射到对应的底层集群和节点池并做配额校验。这个三层状态设计清楚之后后面每一步动作都变得有据可依。不会再出现“为了加一台机器把平台搞成一团乱麻”的情况。1.3 关键选型原则用 K8s 当底座但不被底座绑架无论多机还是多集群K8s 作为底座基本没有悬念。CubeStudio 本身所有计算环境都以 Pod 形态运行天然适合 Kubernetes 的资源模型。但我要特别强调一个原则平台只依赖 Kubernetes 的稳定核心能力不要绑定某个特定发行版、特定网络插件或者特定调度插件。原因很简单多集群环境下各个集群的交付方往往不一样。有的集群可能是机房运维用某套标准安装工具建的有的可能是云服务商托管的。如果 CubeStudio 强依赖某个网络插件或者某个存储类型接入新集群时就会非常痛苦。我在设计上只依赖四类能力Pod 调度、Service/Ingress 暴露、PVC 存储、ResourceQuota 配额校验。这四个能力在所有标准 Kubernetes 发行版上都是可用的。2. 多机部署的关键动作节点分区、调度策略与 GPU 分配多机部署本质上就是在 K8s 集群里把节点规划好让平台组件和用户 Pod 都按照你的意图落在合适的位置。这里有几个核心步骤顺序不能乱。2.1 节点角色分离打标签和污点的时机与细节节点标签和污点需要在一开始就规划好不然后期调整非常痛苦。我的习惯是把所有节点先打上三层标签用途层、硬件层、归属层。用途层用 role 字段区分比如 roleplatform 跑平台自身组件rolecompute 跑用户 Pod。硬件层用硬件型号和算力类型比如 gpuA100、cpu64c。归属层用资源组标识比如 groupalg-team-a这个标签是后面按项目组分算力的基础。标签只是“偏好”真正强制隔离要用污点。平台组件所在节点要加 taint 让用户 Pod 默认不往上面跑反过来计算节点如果不想让平台固定组件占用资源也可以加 taint 只放行带有对应 Toleration 的 Pod。实际操作用 kubectl 就能完成kubectl label node node01 node-role.kubernetes.io/platform kubectl taint nodes node01 dedicatedplatform:NoSchedule注意污点配 Toleration 时要精确不要图省事用一个宽泛的 key。我见过有同事给所有节点打了同一个污点结果平台组件调度器一启动就被自己堵住。建议的节点规划表大概是这样的节点组标签示例污点承载对象平台节点roleplatform, groupinfradedicatedplatform:NoSchedule平台 API、调度器、数据库、监控GPU 计算节点 Arolecompute, gpuA100, groupalg-agputrue:NoSchedule项目组 A 的训练 PodGPU 计算节点 Brolecompute, gpuA100, groupalg-bgputrue:NoSchedule项目组 B 的训练 PodCPU 计算节点rolecompute, cpu64c, groupshared无轻量 Notebook、数据处理任务2.2 调度配置让对的 Pod 落到对的节点节点标签打好之后最关键的是把 Pod 调度策略配置正确。CubeStudio 本身会为用户创建工作负载所以平台侧需要在创建工作负载时注入调度约束而不是让用户手动改 YAML。最常用的是 nodeSelector 和 nodeAffinity。nodeSelector 精确但呆板适合硬性归属nodeAffinity 灵活可以设置 operator支持 In、NotIn、Exists 等条件。在多资源组场景下我给每个用户工作负载注入的是 nodeAffinity 的 requiredDuringSchedulingIgnoredDuringExecution强制匹配项目组对应的节点标签。affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: group operator: In values: - alg-team-a这里有个非常重要的经验不要完全依赖亲和性来做资源组隔离。亲和性只是调度偏好资源组隔离必须以配额校验为准调度约束是辅助手段。你要是只配亲和性、不配配额用户完全可以直接创建一个没有亲和性字段的裸 Pod绕过平台调度逻辑跑到任何节点上去。2.3 GPU 资源如何上报、申请与切分GPU 是这类平台最核心、最容易出问题的资源。多机环境下GPU 不是简单地“插一张卡就能用”而是需要设备插件机制把物理 GPU 上报给 Kubernetes让调度器知道节点上有几张卡、每张卡多少显存然后以可分配资源的形式给 Pod 申请。我使用的是一套基于 NVIDIA 设备插件的标准方案。在 GPU 节点上正确安装驱动和容器运行时后再部署 Device Plugin节点上就会自动出现类似 nvidia.com/gpu 这样的可计数资源。用户 Pod 只需要在 limits 里声明这张卡调度器就会把 Pod 绑定到具体有对应 GPU 的节点。但 GPU 切分这块不同项目组的策略不一样。有的组需要整卡隔离申请就是 1不能多也不能少有的组则想做显存细粒度切分把一张卡分成几份给多个轻量任务用。我的建议是初期保持整卡隔离运营稳定后再考虑显存切分。原因很简单显存切分在调度和故障隔离上非常容易出“显存碎片化”和“复用时显存泄漏”问题投入产出比不划算。3. 多集群纳管的实现路径统一认证、统一入口和数据面打通多集群纳管是让我最费心思的一块。因为“能连上多个集群”和“真正把多集群作为一个整体平台来运营”是两码事。如果你只是把几个 kubeconfig 文件堆在一起让用户手动选集群那不叫纳管叫跳板机。3.1 kubeconfig 聚合只是第一步权限模型要单独设计平台要纳管多个集群第一步肯定是维护多个集群的接入信息。K8s 支持 kubeconfig 里用 context 来区分集群但在这里我建议不要直接把管理员 kubeconfig 塞给平台。你想平台接手用户的 Pod 创建请求如果它自己拿着集群管理员权限一旦平台侧被人提权所有纳管的集群全部沦陷这个风险太大了。正确的做法是为 CubeStudio 平台单独创建一套用于“平台代理”的 ServiceAccount并授予最小权限。平台需要什么权限就授予什么权限比如创建 Pod、读取节点状态、读写 PVC、查看 namespace 配额等。这样平台对集群的访问是受控的、可审计的。我实际维护的是一个多集群接入表每接入一个新集群都会确认四件事API Server 地址是否内网可达、平台用的 ServiceAccount 是否存在、集群的 storageclass 是否就绪、集群的 Prometheus 监控是否已对接到中心。任何一个不满足我不会让这个集群进入可用状态。3.2 统一入口与服务跨集群暴露多集群环境下最挠头的是用户怎么访问到自己的环境。同一个用户在集群 A 里开了一个 Notebook在集群 B 里开了一个训练任务如果两个集群各自暴露入口用户就得记住两个域名多集群等于把复杂度转嫁给了用户这肯定不行。我采用的是统一 Ingress 入口方案平台有一个全局域名入口根据用户请求中的路径或子域名把流量转发到对应集群的 Service 上。也就是说用户访问 Notebook 时始终是同一个地址平台在背后做了一层位置透明的映射。这个映射层需要解决 kubernetes 集群内容器的网络互通问题。我的经验是不强制要求所有集群的 Pod 网络完全打通只要平台入口到各个集群的 Service 网络可以打通即可。换句话说平台转发节点和目标集群的 Service 网段之间要有路由规则。这一层用传统负载均衡或者 Ingress Controller 都可以实现关键是不要走公网裸 IP否则证书、防火墙、审计都会很麻烦。3.3 跨集群调度的两种常见模式跨集群调度是整个多集群里最容易为了技术而技术的部分。实际上我见过可落地的模式无非两种。第一种叫“控制面分发、集群内落地”。平台维护一个全局调度器它负责决定用户任务放到哪个集群然后调用目标集群来创建 Pod。集群内部仍然由本集群的默认调度器来决定 Pod 落到哪台节点。这种模式实现简单、故障域清晰适合绝大多数场景。第二种叫“聚合资源池调度”。把所有集群的节点抽象成一个大的资源池调度器把 Pod 直接调度到某集群的某节点上。这种模式资源利用率最高但对网络、存储、监控的一致性要求极高一旦集群间网络抖动或存储延迟超标问题排查会非常痛苦。我们线上一直用的都是第一种。全局调度器只关注集群级的资源余量和队列情况不做节点级细致调度。节点级问题让集群自己的调度器去处理各有各的职责边界。3.4 多集群存储与网络的基本选择多集群和存储的关系是避不开的。这里有一个很实在的取舍如果你所有集群共用一套高速共享存储那是架构上的大工程如果每个集群各自有本地存储用户数据在集群之间迁移就得靠导出导入体验有损。我目前的策略是“核心成果集中、中间产物就地”。用户长期保存的数据集、模型、代码仓库放集中式共享存储训练中间产物允许写本地临时目录。这样即使集群故障核心数据不丢只是重启任务代价可控。网络层面多集群不要求 Pod 网段一致甚至可以重叠前提是平台入口做映射时不要依赖 Pod IP而是通过 Service 名称和端口访问。重叠网段的情况下内部 DNS 必须能够准确区分上下文否则很容易出现访问到错误集群的 Service。4. 按项目组分算力的落地方案Namespace 边界、配额体系和标签路由这一部分是我们平台从“所有人共用一台机器”走向“多租户资源治理”最核心的一步也是我踩坑最多的部分。按项目组分算力不是简单地在界面上加一个“工作组”选项就可以而是要在调度链路上真正落实隔离。4.1 为什么选 Namespace 作为资源组边界在 Kubernetes 里给项目组划定资源边界最标准的方式就是 Namespace。每个项目组分配独立的 Namespace平台在创建用户环境时直接写到该组的 Namespace 下用户只能看到自己组内的 Pod、服务和存储。选择 Namespace 而不是虚拟机级别的物理隔离原因很直接全平台的工作负载形态已经是 Pod 了Namespace 隔离在容器层面足够应对大多数场景而且 Kubernetes 原生的 RBAC、ResourceQuota 都能直接附着在 Namespace 上管理成本最低。真正要物理隔离的敏感数据不应该通过平台算力分发来解决而是通过网络策略和存储权限来实现。这里有一个容易忽视的坑Namespace 隔离不等于网络隔离。同一个 Namespace 内的 Pod 默认可以互通但不同 Namespace 之间如果网络策略开放一样互访。如果你要给项目组做数据安全隔离必须配合启用 NetworkPolicy而不是单纯分组完事。4.2 ResourceQuota 与 LimitRange 的设计ResourceQuota 是平台按组分算力的核心落地工具。在 Kubernetes 中ResourceQuota 可以限制一个 Namespace 内的 CPU、内存、GPU 数量也可以限制 PVC 数量、Service 数量等。收到项目组资源的申请后我会先按“整节点等价资源”换算。举个例子项目组 A 申请了 2 个节点每台节点 64C 512G 带 4 张 GPU 卡。那么配额可以这样设置apiVersion: v1 kind: ResourceQuota metadata: name: quota-alg-a namespace: alg-team-a spec: hard: requests.cpu: 64 requests.memory: 512Gi limits.cpu: 96 limits.memory: 768Gi requests.nvidia.com/gpu: 4这里我没有直接开满 128C而是留了 25% 左右的弹性余量。为什么因为用户提交的资源申请多数是 limits 偏高requests 偏低如果把 Limits 开满一旦同一组内的任务批量拉起节点 CPU 打满、调度器会开始驱逐用户体验会很差。留余量是为了给调度器的驱逐机制和节点自身系统进程留缓冲。与之配套的还有 LimitRange用来约束单个 Pod 的最小和最大资源申请防止某个用户一次性申请了整组的全部配额导致其他人没资源可用。我给每个项目组都配置了默认限制apiVersion: v1 kind: LimitRange metadata: name: limit-range-alg-a namespace: alg-team-a spec: limits: - default: cpu: 8 memory: 32Gi defaultRequest: cpu: 1 memory: 4Gi max: cpu: 16 memory: 64Gi min: cpu: 0.5 memory: 1Gi type: Container4.3 标签路由让配额和物理资源池对应起来配额只是逻辑上的上限最终 Pod 还需要落到具体具备相应资源的节点上。这时候就要把“资源组”概念延伸到节点标签。每个项目组对应一个节点标签组然后通过前面说的 nodeAffinity 强制绑定。这意味着即使平台因为 Bug 或人为误操作把一个项目组的 Pod 创建到了另一个项目组的节点上调度也是失败的。标签路由配合配额形成了一个软硬兼施的隔离体系。这里要注意必须定期核对节点标签与资源组配额的一致性。曾遇到过节点运维同事重装系统之后节点标签丢失导致某个项目组的任务全部 Pending。这种问题不能用自动化一劳永逸最好在平台里有一个人工复核界面专门展示“每个项目组实际可用节点列表”。4.4 配额从核算到发放的流程配额不能只靠运维拿 kubectl 敲。平台侧我实现了一个简单的审批流项目组发起资源申请平台自动核算申请是否在集群剩余容量允许范围内然后生成 ResourceQuota 和 LimitRange 的变更请求由管理员审批后下发到目标集群。这个流程的好处是可以留审计记录而且避免“谁手快谁多占”。团队成员之间以此为据做成本分摊也让算力提供方和算力使用方有了明确边界。在核算配额时我有一个粗算公式可分配量 节点数 × (单节点可分配 CPU - 系统保留 0.5C - 平台保留 0.5C)。内存类似GPU 卡数直接减掉每节点 0 或 1 张以防止节点上某些并行任务把显存占满导致系统卡死。这套粗算虽然不精确但足够避免“超额售卖后撞车”。5. 平台侧打通部署拓扑、监控聚合与高可用配置把前面几层做完架构基本具备但距离“平台稳定运营”还差一截。多机多集群的资源调度有了配额有了接下来要把平台自身的部署拓扑、监控和告警串起来。5.1 一条完整的算力分发链路长什么样链路是这样的用户登录 CubeStudio选择项目组提交计算环境或训练任务。平台 API 收到请求后先检查该用户在项目组命名空间下的资源占用情况判断是否超出配额然后在全局集群列表中过滤出至少满足资源需求的可用集群再决定把工作负载发送到目标集群的对应 Namespace 下。在目标集群内部Kube Scheduler 根据 nodeAffinity 将 Pod 调度到带有人群标签的节点。Pod 启动后平台在入口处把访问链接回传给用户。整个链路中配额判断发生在“入口”节点绑定发生在“目标集群内”两个环节相互独立。这样做的好处是全局集群列表挂了只能影响新任务的发放已经在跑的老任务不受影响目标集群本身挂了也只影响本集群的任务不会连坐其他集群。5.2 监控聚合与资源计费多集群多资源组一旦跑起来监控就必须打聚合。我是用中心化 Prometheus 抓取各个集群指标的方式把集群维度、Namespace 维度、Pod 维度的 CPU/内存/GPU/网络指标统一汇入平台时间序列库。按项目组分析算力消耗时我通常用 namespace 维度来做。仪表盘上展示三张表全局集群资源总览、项目组配额使用率排行、异常资源占用 Top N。这三张表基本能支撑日常运维判断到底是“节点不够”还是“任务写歪了”。另外建议在每个项目组配额使用率达到 80% 的时候就发通知而不是等到 100% 被拒绝才让用户来找你。通知要发到项目组接口人而不是所有人避免告警疲劳。5.3 高可用和升级节奏平台自身的组件全部部署在带污点隔离的专用节点上副本数至少 2配置了 PodAntiAffinity 让副本不落同一台机器。数据库和对象存储属于有状态服务我对这部分做的是定时备份和冷备恢复演练而不是轻易搭建分布式方案因为平台组件的有状态部分规模不大复杂方案反而增加故障点。升级多集群时我坚持一次只升级一个集群。先把最小集群升级完、跑几天测试任务确认稳定之后再推广到其他集群。多集群很容易让人想用“一键全量升级”但真实生产里多个集群的 API 版本、插件版本往往不完全一致全量升级一旦出问题连回滚都非常复杂。6. 常见问题速查部署、调度、配额里的高频坑以下是我在迁移和运营过程中碰到过的高频问题按典型程度整理出来方便以后排查时照着操作。现象根本原因排查命令解决动作新增节点后任务不往新节点上调度节点标签缺失或者没有移除污点kubectl describe node x检查 label 和 taint重新打标项目组任务全部 PendingResourceQuota 达到上限或者 nodeAffinity 没匹配kubectl describe pod x -n ns检查 quota 用量和节点标签GPU 任务启动报 UnexpectedAdmissionError容器运行时缺少 GPU 设备插件kubectl logs -n kube-system device-plugin重新部署设备插件核对驱动版本平台可以连上集群但创建 Pod 失败平台 ServiceAccount 权限不足kubectl auth can-i --list补齐最小权限并重新授予用户访问 Notebook 偶尔超时跨集群 Ingress 转发链路不稳定检查集群到平台入口网络路由增加超时重试并检查防火墙规则配额明明没满但任务被拒绝项目组各自配了独立 quota 且平台校验的是全局用量查看平台日志里的配额判定逻辑统一配额校验口径6.1 最容易踩的坑节点标签被别人改掉节点标签是整个调度体系里最脆弱的一环因为任何一个有集群权限的同事都可以通过 kubectl label 修改。我遇到过一次某同事在清理机器时顺手把标签写成了 rolecompute, group结果某个项目组的任务全部 Pending排查花了整整半天。后来我给平台加了一个定时巡检脚本每隔十分钟核对一次节点标签和预期规划不一致直接告警。6.2 最容易忽略的坑配额只限制 requests 不限制实际使用ResourceQuota 里如果只配置 requests.cpu 而不配置 limits.cpu用户任务可以把实际 CPU 使用打得很高因为 Kubernetes 限制的是 CPU 时间片而不是配额。特别是跑数据处理任务时有些库开了多线程CPU 飙到 100%同一个 Namespace 内其他任务响应就会变得极慢。所以配额里 requests 和 limits 必须同时配两者之间的差值要小于等于节点的弹性余量。6.3 关于“算力不够”的提前量很多项目组反馈算力不够其实不是物理资源真的不够而是配额分配策略偏保守或者某个任务长期占着资源不放。我的经验是每月做一次资源使用率复盘把每个项目组的配额申请量和实际使用量放一起看及时回收明显富余的配额。同时对长期运行但利用率极低的 Pod要敢于制定策略定期提醒用户让他们停掉闲置环境而不是一次性扩容到位。7. 写在最后这套拓扑还可以怎么扩展多机、多集群、多资源组改造做完之后平台的运营状态比之前好了不止一个量级但并不是说这套架构就一劳永逸了。我个人体会最深的一点是多集群和资源组最难的其实不是技术细节而是把“资源治理”这件事放到团队日常流程里。没有资源申请的审批流、没有月度复盘、没有持续巡检无论架构多漂亮最终都会退化回“谁的嗓子大谁多用”。如果后续还要扩展我计划从两个方向入手一是在多集群之上建立跨集群队列让同一个项目组的任务可以按优先级和排队策略在多个集群间动态分布二是做更细致的按项目的成本核算把 GPU 卡时数、存储容量、网络流量统一折算成成本数据反馈给各团队做预算管理。这两个方向不是必须但一旦组织规模上来它们会是下一个卡点。最后分享一个小技巧每次调整节点标签、配额或集群接入信息后都手动跑一遍“调度演练”也就是用一个空 Pod 模拟真实任务的标签和资源申请确认它能落到预期节点。这个动作花不了两分钟却能把绝大部分配置问题拦截在用户反馈之前。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
