云原生 AI 前沿：Kubeflow Training Operator 统一云上 AI 训练

分布式训练与 Kubeflow

当开发者想要讲深度学习的分布式训练搬上 Kubernetes 集群时，首先想到的往往就是 Kubeflow 社区中形形色色的 operators，如 tf-operator、mpi-operator。

这些服务于各种深度学习训练（TensorFlow、PyTorch、MXNet 等）的 operators 主要的工作包括：

1. 在 Kubernetes 集群上创建 Pod 以拉起各个训练进程
2. 配置用作服务发现的信息（如 TF_CONFIG）以及创建相关 Kubernetes 资源（如 Service）
3. 监控并更新整个任务的状态

事实上，Kubeflow 的训练 Operators 已经成为在 Kubernetes 上运行分布式训练任务的实际标准。

不仅各大公有云厂商都已经基本收录或集成了 Kubeflow 的训练 operators，社区上其他与深度学习训练相关的项目（如用以自动机器学习的 Katib，又如提供自动化编排功能的 Flyte）都对接了 Kubeflow 中的 operators 作为下发创建分布式训练任务的工具。

Kubeflow Operators 的问题

在 2019 年初，Kubeflow 社区启动了 kubeflow/common 项目用以维护 operator 之间重复使用的部分代码。经过一年多的迭代和重构，在 2020 年中该项目逐渐稳定并开始接入训练 operator 。当前，tf-operator、mxnet-operator 和 xgboost-operator 即为构建在 kubeflow/common 项目之上的训练 operators。

然而，整个 Kubeflow 训练 operators 的项目维护依然存在许多挑战。

主要包括：

1. 大量开发者的精力耗费在针对不同训练框架的功能增强和故障修复上
2. 难以将测试和发布的基础功能与服务在不同 operators 之间复用
3. 第三方组件需要对接大量不同的 operators
4. 新的训练框架需要开发完整的对应的 operator 才能使用，开发成本过高
5. 众多的 operators 对刚刚接触 Kubeflow 的新人开发