Kubernetes 多集群管理：AI 平台跨集群调度的工程实践

Kubernetes 多集群管理AI 平台跨集群调度的工程实践一、单集群不是银弹为什么 AI 平台必须走向多集群任何一个从零开始搭建的 AI 推理平台最初都会把全部服务部署在一个 Kubernetes 集群里。这个阶段集群规模可控——几个推理服务、一个网关、一套监控——单集群的简单性让运维成本维持在合理水平。但当模型服务数量突破 50 个、GPU 节点扩展到三位数时单集群的边界效应开始显现。面临的问题非常具体。首先是资源碎片化。不同模型对 GPU 型号的需求不同——llama-3-70b 需要 A100-80G 才能装下权重而 bert-base 在 T4 上就能跑得很好。把这两种机器塞进同一个集群、统一调度会出现大模型被调度到小卡节点上启动失败、小模型占据大卡造成资源浪费的问题。其次是故障域过于集中。一个集群的控制面故障API Server 压力过大或 etcd 延迟抖动会影响所有推理服务的可用性。第三是运维策略的冲突。不同业务线的升级窗口期不同、安全补丁节奏不同、是否需要 GPU 驱动升级的决策也不同强行统一只会增加协调成本。基础设施不需要漂亮话。多集群不是追求架构上的高级感而是解决这些单集群无法回避的实际问题。AI 平台的跨集群调度本质上是一个资源效率与运维复杂度之间的平衡问题。二、多集群拓扑设计按 GPU 类型做资源分区我们的多集群设计遵循一条核心原则按 GPU 类型做资源分区每类 GPU 对应一个独立的 Kubernetes 集群。这个设计将异构硬件的调度复杂度从集群内转移到了集群间在集群内部保持同构简化 Kube-Scheduler 的工作。具体拓扑如下在这个拓扑中A100-80G 集群负责 70B 参数以上的大语言模型推理A10-24G 集群负责 7B-13B 参数的模型和 Embedding 服务T4-16G 集群负责轻量的分类模型和预处理服务。每个集群维护自己的节点池、自己的 GPU Operator、自己的自动扩缩策略Cluster Autoscaler 或 Karpenter。调度器的工作流程是接收到部署请求后先从全局模型注册表读取模型的 GPU 需求型号、显存、推荐副本数然后匹配对应的集群进行调度。如果目标集群资源不足调度器不降级到其他集群——因为降级意味着模型可能在不符合要求的 GPU 上运行导致性能退化或直接挂掉。三、关键实现跨集群部署与流量编排跨集群调度面临两个核心工程问题部署编排和流量分发。部署编排方面我们在模型注册表中为每个模型维护一个target_clusters字段指向它应该被部署到哪些集群上。当一个模型被注册并触发 CI 构建完镜像后调度器自动在各目标集群中创建对应的 Deployment 或 StatefulSet。这里的关键是保证部署的一致性——同一个模型在不同集群上的推理框架版本、启动参数、资源配置完全一致。我们通过 Helm Chart 模板化来实现每个模型对应的 Values 文件由注册表自动生成人工不允许直接修改。// ClusterScheduler 多集群调度器的核心接口 type ClusterScheduler struct { registry ModelRegistry clusters map[string]*ClusterClient helmClient *helm.Client } // ScheduleDeploy 根据模型元数据将服务调度到目标集群 func (s *ClusterScheduler) ScheduleDeploy(ctx context.Context, modelID string) error { meta, err : s.registry.GetByID(ctx, modelID) if err ! nil { return fmt.Errorf(获取模型元数据失败: %w, err) } // 从注册表获取目标集群列表非人工填写 targets : meta.TargetClusters var errs []error for _, clusterName : range targets { cli, ok : s.clusters[clusterName] if !ok { errs append(errs, fmt.Errorf(集群 %s 未在调度器注册, clusterName)) continue } // 检查目标集群 GPU 资源是否满足需求 if err : s.checkGPUQuota(ctx, cli, meta.GPU); err ! nil { errs append(errs, fmt.Errorf(集群 %s GPU 资源不足: %w, clusterName, err)) continue } // 通过 Helm 在目标集群部署服务 values : s.buildHelmValues(meta, clusterName) if err : s.helmClient.Install(ctx, cli.Namespace, meta.ID, values); err ! nil { errs append(errs, fmt.Errorf(集群 %s 部署失败: %w, clusterName, err)) continue } } if len(errs) len(targets) { return fmt.Errorf(所有目标集群部署均失败: %v, errs) } return nil }流量分发方面我们使用 Envoy 的加权路由策略按照各集群的副本数比例分配流量。当某个集群出现故障时Envoy 的健康检查机制会在 5 秒内将其从路由表中摘除流量自动切换到其他健康集群。这个过程对调用方完全透明。一个容易被忽略的细节是跨集群的镜像预热。模型推理镜像通常体积较大10-30GB如果在调度时才拉取镜像首次启动可能长达 10-15 分钟。我们的做法是在模型注册时就触发所有目标集群的镜像预拉取确保在服务真正被调度时镜像已经在节点上可用。四、多集群的代价你增加的复杂度不是免费的多集群方案增加的复杂度需要被认真量化。首先是集群管理本身的开销——三个集群意味着三套控制面需要维护升级、三套监控告警需要配置收敛、三套 etcd 需要备份恢复。运维团队的人力成本不会线性增长但认知负荷会显著上升。其次是跨集群的网络通信成本。如果两个模型之间存在推理调用链如 Embedding 模型 → LLM当它们被调度到不同集群时调用延迟会额外增加 2-5 毫秒的跨集群网络开销。在高并发的推理场景下这个延迟累积起来不可忽略。解决方案是根据调用亲和性将相关模型部署到同一集群——但这又回到了调度复杂度的老问题上。第三是成本核算的复杂度。多集群模式下每个业务线的 GPU 消耗需要跨集群汇总而不同 GPU 类型的单价差异很大。需要开发专门的计费系统来做跨集群的资源统计和费用归集。多集群方案的禁用场景包括模型数量少于 20 个、GPU 节点类型不超过两种、所有业务共用同一升级窗口。在这些场景下单集群加 GPU 节点池Node Pool混合调度的方案更合适——简单永远优先于花哨。五、总结多集群管理不是架构的炫耀而是当单集群的物理边界和运维边界被突破后的务实选择。核心原则是按 GPU 类型做资源分区通过统一的调度器和模型注册表实现部署编排通过 Envoy 实现流量编排。落地建议先不要急着拆集群。当你的平台同时满足以下三个条件时再考虑——GPU 型号超过两种且不可互换、单集群 GPU 节点超过 100 个、不同业务线对升级窗口有无法调和的冲突需求。满足其中任一项就可以开始规划多集群架构。多集群需要持续投入运维资源不是一个架设完就可以不管的基础设施。