关于腾讯云:云原生-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 的新人开发者而言学习老本过高

以上问题都是 Kubeflow 的开发者和维护者面对的。除此之外，这些 operator 的使用者同样面临一些问题：

1. 用户须要装置多个 operator 组件能力反对多种训练 APIs
2. 各种 Kubeflow Jobs 的 JobSpec 看上去很相似，然而又有些许不同，并没有提供对立的应用体验

这问题的起因次要在于 每个深度学习框架都对应一个的 operator 独立在一个 repository 中进行保护。这种离开保护的模式使得诸如构建环境、测试环境、部署形式以及代码逻辑都无奈做到很好的整合。

只管深度学习框架的数量处在收敛的过程中，但仍然会有源源不断的新框架心愿通过 Kubeflow 能够疾速接入 Kubernetes 进行分布式训练，而这些新的增量使得问题变得更为严重。

Proposal：All-in-One

针对下面提到的各项问题，通过社区会议的屡次探讨，决定尝试 通过交融的形式将多个 Kubeflow 的训练 operator 代码汇聚到一个仓库。

同时，参照 controller-runtime 中举荐的 One-Manager-Multi-Controller 的模式，让多个解决不同 API 的 controller 能够共享一个 Manager 及其 cache，在 简化代码的同时也缩小了在多个 operator 同时部署时冗余的 APIServer 申请：

    mgr, err := ctrl.NewManager(ctrl.GetConfigOrDie(), ctrl.Options{...})
    ...
    for _, s := range enabledSchemes {setupFunc, supported := controller_v1.SupportedSchemeReconciler[s]
        if !supported {os.Exit(1)}
        if err = setupFunc(mgr, enableGangScheduling); err != nil {setupLog.Error(err, "unable to create controller", "controller", s)
            os.Exit(1)
        }
    }

所有的 Controller（Reconciler）都须要向 SupportedSchemeReconciler 提前完成注册：

var SupportedSchemeReconciler = map[string]ReconcilerSetupFunc{tensorflowv1.Kind: func(mgr manager.Manager, enableGangScheduling bool) error {return tensorflowcontroller.NewReconciler(mgr, enableGangScheduling).SetupWithManager(mgr)
    },
    pytorchv1.Kind: func(mgr manager.Manager, enableGangScheduling bool) error {return pytorchcontroller.NewReconciler(mgr, enableGangScheduling).SetupWithManager(mgr)
    },
    ...,
}

用户能够在启动 operator 过程时通过 --enable-scheme 来指定须要开启反对的 API。后续有新的 Controller 接入，依照这种“先注册后启动”的形式来选择性地开启对应的 controllers。

停顿与近期布局

以后交融曾经正式并入 tf-operator 的 master 分支。用户很快能够在行将公布的 Kubeflow 1.4 Release 中体验到交融后的 tf-operator：部署单个 operator 即可反对包含 TFJob、PyTorchJob、MXNetJob 和 XGBoostJob 在内的四种 API 反对。

在代码仓库层面的交融是 Kubeflow Training Operator 迈向下一个阶段的第一步 。这一步更多地解决了在我的项目经营层面，包含环境复用、整体代码治理上的一致性。而针对开发者的低代码开发，包含 新性能加强、bug 修复和新 API 接入，将是咱们布局的下一步指标。

依据这样的设计，开发者只须要批改十分无限的几个函数即可接入新的 API。

次要包含：

// 依据 ctrl.Request 获取对应的自定义 Job
GetJob(ctx context.Context, req ctrl.Request) (client.Object, error)
// 从自定义 Job 中以 map[commonv1.ReplicaType]*commonv1.ReplicaSpec 的格局抽取 ReplicasSpecs
ExtractReplicasSpec(job client.Object) (map[commonv1.ReplicaType]*commonv1.ReplicaSpec, error)
// 从自定义 Job 中抽取 RunPolicy
ExtractRunPolicy(job client.Object) (*commonv1.RunPolicy, error)
// 从自定义 Job 中抽取 JobStatus
ExtractJobStatus(job client.Object) (*commonv1.JobStatus, error)

开发者如果须要注入一些用以服务发现的环境变量，能够笼罩办法 DecoratePod(rtype commonv1.ReplicaType, podTemplate *corev1.PodTemplateSpec, job client.Object) 在 client 向 APIServer 提交创立申请前批改 Pod。

以上低代码开发方式的根底曾经以 pkg/reconciler.v1 的状态合入 kubeflow/common 仓库。很快，咱们也将在 tf-operator 上引入基于该 reconciler.v1 包的根底 API，心愿能够在验证 reconciler.v1 的同时为更多通用的实用案例提供一种更为简便接入 Kubernetes 的形式。

如果开发者心愿以更低层 API 的形式对 controller 进行开发，pkg/controller.v1 包能够满足这一类开发者的需要。

近景瞻望

只管针对 Kubeflow Training Operator 的优化革新还在进行中，咱们并没有止步于此。对于 Training Operator 的将来的倒退，咱们认为存在以下几个畛域值得继续投入：

1. 首先 是进一步提高 Kubeflow Training Operator 适配定制化需要 Job 时的灵活性。咱们打算提出与深度学习训练框架解耦的一种 Job API 以反对更宽泛的工作定义，并容许用户能够借助 kubeflow/common 中的 controller.v1 和 reconciler.v1 进行定制化开发，但其学习老本和开发成本仍然过高。甚至在未来，高级开发者能够不批改 operator 而仅仅增加 / 批改一些 webhook 或是 decorator server 来实现定制化批改。
2. 第二个方面 是进一步加强 Kubeflow Training Operator 和其余第三方组件交互时的便利性。咱们心愿将来利用 Kubeflow Training Operator 来构建 AI 平台的开发者能够不便地将其与其余模块对接，实现诸如工作队列、流水线、超参数搜寻等性能。
3. 最初也是最要害的，咱们仍然心愿能够进一步晋升 Kubeflow Training Operator 的稳定性。

咱们欢送更多的同学可能尝试、体验 Kubeflow 并且投入到 Kubeflow 我的项目中来。

参考资料

[1]add reconciler.v1:【https://github.com/kubeflow/c…】

[2]
reconciler.v1 implementation:【https://github.com/kubeflow/c…】

[3] All-in-one Kubeflow Training Operator:【https://docs.google.com/docum…】

对于咱们

更多对于云原生的案例和常识，可关注同名【腾讯云原生】公众号~

福利：公众号后盾回复【手册】，可取得《腾讯云原生路线图手册》&《腾讯云原生最佳实际》~

【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！