【K8S】SRE项目，多集群 AI 训练推理平台底座建设，问题解决/能力沉淀

【K8S】SRE项目，多集群 AI 训练推理平台底座建设，问题解决/能力沉淀

文章目录

• • 一、项目背景与平台架构
  • 二、关键实践与问题治理
  • • [1. GPU 资源利用率和稳定性需要同时满足](#1. GPU 资源利用率和稳定性需要同时满足)
    • [2. 训练与推理混跑必须建立明确隔离策略](#2. 训练与推理混跑必须建立明确隔离策略)
    • [3. P0/P1 故障处理要从"救火"变成"可复用流程"](#3. P0/P1 故障处理要从“救火”变成“可复用流程”)
    • [4. 多集群管理必须统一入口、统一策略和统一治理](#4. 多集群管理必须统一入口、统一策略和统一治理)
    • [5. 平台能力需要通过插件化和二次开发来承接](#5. 平台能力需要通过插件化和二次开发来承接)
    • [6. 分布式训练通信和 GPU 特性需要纳入平台设计](#6. 分布式训练通信和 GPU 特性需要纳入平台设计)
  • 三、能力沉淀与匹配
  • • [1. 与职责的匹配](#1. 与职责的匹配)
    • [2. 与要求的匹配](#2. 与要求的匹配)

一、项目背景与平台架构

XXX参与的项目，是公司面向内部模型训练与推理场景建设的统一 AI 基础设施平台，核心目标不是单纯提供一个可用的 Kubernetes 集群，而是围绕 GPU 资源池、多集群治理、稳定性保障和平台扩展能力，搭建一套可长期支撑业务增长的底座。

这个平台承载的业务类型比较复杂，既包括大规模训练任务，也包括在线推理服务、批量实验任务和平台控制类组件。刚开始我们做的事情并不是谈架构，而是先从值班、告警和任务失败现象里倒推问题：哪类任务最容易卡住，卡住以后通常先出现什么信号，业务侧最先会在哪个时间点来找平台。随着业务规模扩大，平台逐步暴露出几个典型问题：

• 比如训练任务经常出现"节点上明明还有 GPU，但就是一直 Pending"的情况，排查下来往往不是单纯资源不够，而是显存规格、节点标签、污点容忍和亲和性条件没有同时满足。
• GPU 资源碎片化明显
• 训练与推理混跑带来稳定性波动
• 单集群承载压力持续升高
• 多集群之间缺少统一治理
• 以及业务侧提出的定制需求越来越多，标准 K8s 能力已经无法完全覆盖

从架构上看，平台大致可以拆成五层：

• 统一接入层：负责租户接入、权限控制、资源申请、任务提交和入口治理。
• 多集群编排层：负责多个 GPU 集群之间的资源分发、策略同步、故障切换和统一管理。
• 调度与放置层：负责训练、推理和批处理任务的调度决策，结合优先级、亲和性、污点容忍、资源预留等机制完成放置。
• 资源供给层：包括 GPU 节点池、CNI、CSI、Device Plugin、容器运行时以及节点侧系统参数。
• 运行与治理层：包括监控、告警、日志、容量规划、发布管控、故障响应和复盘闭环。

在这个架构里，Kubernetes 只是基础运行环境，真正决定平台上限的，是调度、隔离、可观测性、插件扩展能力和跨集群治理能力。也正因为如此，项目从一开始就不是按"集群运维"来设计，而是按"平台底座建设"来推进。

二、关键实践与问题治理

1. GPU 资源利用率和稳定性需要同时满足

GPU 资源成本高，平台自然希望尽可能提高利用率，但如果只追求填满资源，就很容易引发调度碎片、通信争抢、节点压力上升和故障扩散。XXX的处理方式不是单纯提升利用率，而是在稳定边界内做资源治理。

主要措施包括：

• 按训练、推理和实验场景拆分节点池，减少互相干扰。
• 通过标签、污点和容忍度控制工作负载进入范围。
• 使用 PriorityClass、亲和性和反亲和性策略，避免关键任务被低优先级任务挤占。
• 对 GPU 共享场景结合 MIG、MPS、TimeSlicing 等能力做资源切分。
• 对碎片化严重的资源池做定期治理和容量回收。

通过这类治理，平台不再只关注"还有没有 GPU"，而是进一步关注"资源是否以合适的形态被使用"，从而降低了 Pending 积压和资源争抢问题。

比如有些大训练任务并不是卡在总量，而是卡在单卡显存或通信拓扑上，后来调整节点池和资源切分后，调度成功率就明显好一些。

还有些场景是节点看上去资源还行，但因为前面留给系统组件和中间件的余量太小，业务任务一上来就把磁盘 IO 和内存一起顶满，后面新来的 Pod 就开始排队。

2. 训练与推理混跑必须建立明确隔离策略

训练任务和推理任务的特性差异很大。

训练任务通常是长时间运行、通信密集、批量型负载；推理任务更关注时延、稳定性和弹性扩缩。

如果两类任务共用同一套粗放策略，推理业务会直接感受到抖动，训练任务也会因为资源争抢而出现吞吐下降。

XXX的实践重点放在"策略隔离"而不是"硬切割"：

• 为推理业务设置更高优先级和更严格的发布门槛。
• 为训练任务保留批量资源和弹性调度空间。
• 使用 taints / tolerations、affinity、PodTopologySpread 等机制降低混跑带来的干扰。
• 为关键推理服务预留容量，避免高峰期被训练任务挤占。
• 在发布和变更层面增加灰度、回滚和限流控制。

这样做的结果，是让平台能够在同一资源体系下服务不同类型业务，而不是简单依赖人工协调。

比如推理服务发版后，如果同池子里正好有训练任务在打满网络，业务侧最先感知到的就是接口延迟抖动，所以XXX们会先把这类推理服务拆到更稳的池子里。

实际操作里，XXX们还会看发布窗口和流量高峰，尽量避开训练任务集中起量的时段，不让平台侧先顶不住。

3. P0/P1 故障处理要从"救火"变成"可复用流程"

在 GPU 平台场景里，故障可能出现在节点、网络、存储、调度、控制面或者插件层，定位链路很长。

如果没有统一的排障方式，工程师在故障期会频繁切换系统，恢复效率会非常低。

XXX重点补齐了三件事：

• 建立分层定位思路，把问题拆成控制面、调度层、节点层、网络层、存储层和业务层。
• 建立事件、日志、指标联动的观测体系，减少对单一信号的依赖。
• 为高频问题整理标准化 Runbook，并把复盘结论沉淀为长期治理动作。

对于 P0/P1 级故障，重点不只是恢复服务，更重要的是把恢复过程变成可复用的方法，把一次故障变成后续减少故障的能力。

比如一次卷挂载异常，前面会先看 PVC 绑定、节点上的 CSI 驱动状态和事件时间线，先把业务拉起来，再回头补根因。

还有一种很常见的情况，是 Pod 自己的资源申请和节点实际可用资源没有完全对上，表现出来就是调度没报太多错，但任务就是起不来，这种就要把事件、日志和节点状态放在一起看。

4. 多集群管理必须统一入口、统一策略和统一治理

随着业务和区域扩展，单集群已经无法覆盖全部需求，平台逐步进入多集群并行阶段。

这个阶段最容易出现的问题，是每个集群都能独立运行，但整体缺少统一标准，最后演变成多个孤岛。

为避免这种情况，XXX围绕多集群治理做了几项工作：

• 设计统一接入方式，让业务通过同一入口提交任务和管理资源。
• 建立跨集群的资源分发和策略同步机制。
• 明确不同集群的业务定位和隔离边界。
• 为核心业务设计容灾和故障切换策略。
• 统一镜像、证书、配额、告警和发布规范。

这部分工作的核心不是"多连几个集群"，而是让多个集群具备一个统一的治理面，从而支撑更高层次的业务连续性。

比如主集群切到灾备集群时，镜像仓库地址、StorageClass 和节点标签如果不统一，任务即使漂过去也可能重新卡住，所以前置治理很关键。

我们当时做统一治理，不只是为了"看起来整齐"，更重要的是后面真切流量、真切任务的时候，少踩一次坑就少一次人工介入。

5. 平台能力需要通过插件化和二次开发来承接

AI 场景对底层能力的要求通常比较细，例如特定网络策略、专属存储、GPU 资源暴露方式、调度放置规则、任务生命周期控制等。

标准 K8s 对这些需求并不会天然全部满足，因此平台必须具备插件化扩展能力。

XXX参与过的相关工作主要集中在几个方向：

• 使用或定制 CNI 方案，满足网络隔离和策略控制需求。
• 基于 CSI 框架做存储接入和挂载适配。
• 通过 Device Plugin 暴露 GPU 资源。
• 在调度侧使用 Scheduler Extender 或调度框架扩展实现放置策略。
• 通过 Operator 和控制器机制承接业务对象的生命周期管理。

这类工作要求不仅理解 K8s 的原理，还要能够定位到源码级行为差异，并在业务约束下做定制化实现。

比如一个存储挂载问题，往往不是直接改 YAML 就结束，而是会去看节点上驱动容器日志、NodePublish 阶段报错和 PV/PVC 绑定链路。

有些网络侧问题也类似，表面看是业务连不上，实际上可能是 CNI 的策略没生效、节点路由没通，或者跨集群流量被中间层拦了一次。

6. 分布式训练通信和 GPU 特性需要纳入平台设计

在训练场景中，瓶颈往往不在单卡算力，而在通信、拓扑和显存使用方式上。

平台在资源规划和调度治理中，需要把 NCCL、RDMA、RoCE、IB 等因素一起考虑进来，同时关注 MIG、MPS、TimeSlicing 等 GPU 共享和隔离方案对任务运行行为的影响。

对应地，XXX在平台治理中重点关注以下内容：

• 根据通信拓扑优化节点布局和任务放置。
• 对高通信强度任务做资源预留和策略倾斜。
• 对网络抖动、丢包和带宽下降建立可观测性。
• 对显存、算子特性和资源切分方式建立基础认知，避免在不合适的资源形态上调度任务。

这一部分能力，直接决定平台能否真正支撑大模型训练和高并发推理业务。比如多机多卡训练一旦跨错节点，NCCL 的通信效率和任务启动时间会很明显地变差，所以调度时不能只看有卡，还要看拓扑是否合适。

我们在看这类任务时，除了看 GPU 数量，还会看网络带宽、节点分布、显存切分方式和通信路径，避免卡在"算力够但链路不对"的情况。

三、能力沉淀与匹配

项目背景 / 平台架构 / 业务场景 / 讲清楚这个平台为什么存在 / 业务压力是什么 / 架构怎么分层 / 为什么要做多集群、GPU、训练/推理治理

1. 与职责的匹配

项目怎么做: 在项目里做了什么 / 主要问题与解决方案 / 每个问题对应一类处理手段 / 强调怎么落地、怎么排障、怎么治理、怎么推动

• GPU 集群稳定性建设：XXX具备节点池划分、容量规划、资源配额、灰度发布、变更管控、稳定性指标建设和长期治理闭环的实践经验。
• 故障响应与处理：XXX具备 P0/P1 故障分层定位、应急响应、根因分析、Runbook 建设和复盘落地的能力。
• 多集群管理：XXX具备统一接入、跨集群治理、资源分发、容灾切换和策略同步的实践理解。
• 基础设施插件开发：XXX对 CNI、CSI、Device Plugin、Scheduler Extender、Operator 等扩展点有实际接触和二次开发思路。
• 跨团队协作：XXX能够将训练、推理和平台侧诉求转化为可落地的基础设施方案。

2. 与要求的匹配

凭什么能做: 通过这个项目，具备了什么能力

• K8s 核心组件 ：XXX理解 kubelet、kube-scheduler、controller-manager、apiserver、etcd 的工作链路及常见故障模式。
• GPU 调度经验：XXX理解 NVIDIA Device Plugin、Scheduler Extender、PriorityClass、PodTopologySpread、MIG、MPS、TimeSlicing 等机制的组合使用方式。
• CNI / CSI 深度定制能力：XXX具备对 Calico、Cilium、CSI Driver 框架进行调试和适配的基础能力。
• 多集群管理经验：XXX对 Karmada、KubeFed、Cluster API 以及类似方案的治理模型有明确认知。
• Go / Python 编程能力：XXX可以基于 Go 和 Python 完成控制器开发、自动化巡检、故障诊断和批量治理工具实现。
• 系统设计与排障能力：XXX能够把资源、调度、网络、存储、观测和发布串联成完整的稳定性治理体系。