详解Kubeflow这一K8S的机器学习利器

针对Kubeflow组件较多，容易搞不清每个组件是干什么的，本文先对Kubeflow进行一个系统的概括，让大家明白各个组件分别的用处，并对组件间的关系进行理顺，帮助大家合理快速的选择自己需要的组件，随后会对每个组件的底层架构和流程分别进行详细的介绍和剖析，供大家针对性的进一步学习。

什么是Kubeflow？

Kubeflow是的机器学习工具包。Kubeflow是运行在K8S之上的一套技术栈，这套技术栈包含了很多组件，组件之间的关系比较松散，我们可以配合起来用，也可以单独用其中的一部分。下图是官网显示Kubeflow作为在上安排ML系统组件的平台：

我们先大体看一眼Kubeflow都有哪些组件，是不是很多？接下来我会带大家逐步了解每个组件都有哪些作用。当我们开发和部署ML系统时，ML工作流程通常包括几个阶段。开发ML系统是一个反复的过程。我们需要评估ML工作流各个阶段的输出，并在必要时对模型和参数进行更改，以确保模型不断产生所需的结果。为了便于理解，下图按顺序显示了工作流程阶段，并将Kubeflow添加到工作流中，显示在每个阶段都有哪些Kubeflow组件有用。工作流末尾的箭头指向流程，以表示流程的迭代性质：

- 在实验阶段，我们将基于初始假设来开发模型，并反复测试和更新模型以产生所需的结果：
  - 确定我们要ML系统解决的问题。
  - 收集和分析训练ML模型所需的数据。
  - 选择一个ML框架和算法，并为模型的初始版本编码。
  - 试验数据并训练模型。
  - 调整模型超参数以确保最有效的处理和最准确的结果。
- 在生产阶段，我们将部署执行以下过程的系统：
  - 将数据转换为训练系统所需的格式（为了确保我们的模型在训练和预测过程中行为始终一致，转换过程在实验阶段和生产阶段必须相同）。
  - 训练ML模型。
  - 服务模型以进行在线预测或以批处理模式运行。
  - 监督模型的性能，并将结果输入到我们的程序中，以调整或重新训练模型。

由此可以看出，Kubeflow的目标是基于K8S，构建一整套统一的机器学习平台，覆盖最主要的机器学习流程（数据->特征->建模->服务→监控），同时兼顾机器学习的实验探索阶段和正式的生产环境。

Kubeflow组件

Kubeflow提供了一大堆组件，涵盖了机器学习的方方面面，为了对Kubeflow有个更直观深入的了解，先整体看一下Kubeflow都有哪些组件，并对Kubeflow的主要组件进行简单的介绍：

Central Dashboard：Kubeflow的dashboard看板页面
Metadata：用于跟踪各数据集、作业与模型
Jupyter Notebooks：一个交互式业务IDE编码环境
Frameworks for Training：支持的ML框架
- Chainer
- MPI
- MXNet
- PyTorch
- TensorFlow
Hyperparameter Tuning:Katib，超参数服务器
Pipelines：一个ML的工作流组件，用于定义复杂的ML工作流
Tools for Serving：提供在上对机器学习模型的部署
- KFServing
- Seldon Core Serving
- TensorFlow Serving(TFJob):提供对Tensorflow模型的在线部署，支持版本控制及无需停止线上服务、切换模型等
- NVIDIA Triton Inference Server(Triton以前叫TensorRT)
- TensorFlow Batch Prediction
- Multi-Tenancy in Kubeflow：Kubeflow中的多租户
- Fairing：一个将code打包构建image的组件

Kubeflow中大多数组件的实现都是通过定义CRD来工作。目前Kubeflow主要的组件有：

Operator是针对不同的机器学习框架提供资源调度和分布式训练的能力（TF-Operator，PyTorch-Operator，Caffe2-Operator，MPI-Operator，MXNet-Operator）;
Pipelines是一个基于Argo实现了面向机器学习场景的流水线项目，提供机器学习流程的创建、编排调度和管理，还提供了一个Web UI。
Katib是基于各个Operator实现的超参数搜索和简单的模型结构搜索的系统，支持并行搜索和分布式训练等。超参优化在实际的工作中还没有被大规模的应用，所以这部分的技术还需要一些时间来成熟；
Serving支持部署各个框架训练好的模型的服务化部署和离线预测。Kubeflow提供基于TFServing，KFServing，Seldon等好几种方案。由于机器学习框架很多，算法模型也各种各样。工业界一直缺少一种能真正统一的部署框架和方案。这方面Kubeflow也仅仅是把常见的都集成了进来，但是并没有做更多的抽象和统一。

以上，我对Kubeflow组件进行了系统的概括，来帮助我们对各个组件有一个基本的了解和整体的把握。趁热打铁，接下来我们详细介绍每一个组件的架构和工作流程。

Jupyter Notebooks

Jupyter本身包含很多组件。对于个人用户，使用JupyterLab + Notebook就足够了。但是如果把Jupyter当成一个公司级的平台来看待的话就远远不够了。这时候需要考虑的事情就比较多了，比如多用户、资源分配、数据持久化、数据隔离、高可用、权限控制等等。而这些问题恰恰是K8S的特长。因此把Jupyter和K8S结合起来使用就非常顺理成章。 JupyterHub是一个多用户的Jupyter门户，在设计之初就把多用户创建、资源分配、数据持久化等功能做成了插件模式。其工作机制如下图所示:

既然JupyterHub是个框架，因此出现了各种各样的插件。比如可以单机部署利用OS用户实现多用户和数据隔离；也可以使用OAuth完成用户鉴权等。当然，将整个JupyterHub和K8S结合起来，是最完美的姿势。Kubeflow中的Multi-Tenancy in Kubeflow多租户组件我还没看，后面可以对比研究一下是否是基于此实现的。下面我们再来说说Kubeflow，因为缺乏隔离和资源限制，目前仅适用数据科学家的solo场景，无法支持数据科学家团队合作场景。所以平心而论，它还未获得用户的信任。 Kubeflow将default-editor ServiceAccount分配给Jupyter notebook Pod。该服务帐户绑定到kubeflow-edit ClusterRole，它对许多资源具有命名空间范围的权限，其中包括：

Pod
Deployment
Service
Job
TFJob
PyTorchJob

因此，可以直接从Kubeflow中的Jupyter notebook创建上述资源。 notebook中已预装了命令行工具，可以说也是非常简单了。将Jupyter notebook绑定在Kubeflow中时，可以使用Fairing库使用TFJob提交训练作业。训练作业可以运行在单个节点，也可以分布在同一个集群上，但不能在notebook pod内部运行。通过Fairing库提交作业可以使数据科学家清楚地了解Docker容器化和pod分配等流程。总体而言，Kubeflow-hosted notebooks可以更好地与其他组件集成，同时提供notebook image的可扩展性。

Pipelines

在Kubeflow v0.1.3之后， pipeline已经成为Kubeflow的核心组件。Kubeflow的目的主要是为了简化在上运行机器学习任务的流程，最终希望能够实现一套完整可用的流水线, 来实现机器学习从数据到模型的一整套端到端的过程。而pipeline是一个工作流平台，能够编译部署机器学习的工作流。所以从这个层面来说，pipeline能够成为Kubeflow的核心组件一点也不意外。 kubeflow/pipelines实现了一个工作流模型。所谓工作流，或者称之为流水线（pipeline），可以将其当做一个有向无环图（DAG）。其中的每一个节点被称作组件（component）。组件处理真正的逻辑，比如预处理，数据清洗，模型训练等。每一个组件负责的功能不同，但有一个共同点，即组件都是以Docker镜像的方式被打包，以容器的方式被运行的。下图显示了Kubeflow Pipelines UI中管道的运行时执行图：

实验（experiment）是一个工作空间，在其中可以针对流水线尝试不同的配置。用户在执行的过程中可以看到每一步的输出文件，以及日志。步（step）是组件的一次运行，输出工件（step output artifacts）是在组件的一次运行结束后输出的，能被系统的前端理解并渲染可视化的文件。

Pipelines架构

下图是官方提供的Kubeflow Pipelines架构图：

看起来还是比较复杂的，但整体可以将pipeline主要划分为八部分：

Python SDK: 用于创建kubeflow pipelines组件的特定语言（DSL）。
DSL compiler: 将Python代码转换成YAML静态配置文件（DSL编译器）。
Pipeline Web Server: pipeline的前端服务，它收集各种数据以显示相关视图：当前正在运行的pipeline列表，pipeline执行的历史记录，有关各个pipeline运行的调试信息和执行状态等。
Pipeline Service： pipeline的后端服务，调用K8S服务从YAML创建 pipeline运行。
Kubernetes Resources: 创建CRDs运行 pipeline。
Machine Learning Metadata Service: 用于监视由Pipeline Service创建的资源，并将这些资源的状态持久化在ML元数据服务中(存储任务流容器之间的input/output数据交互）。
- Artifact Storage: 用于存储Metadata和Artifact。Kubeflow Pipelines将元数据存储在MySQL数据库中，将工件存储在Minio服务器或Cloud Storage等工件存储中。
- Orchestration Controllers：任务编排，比如 Argo Workflow控制器，它可以协调任务驱动的工作流。

Pipelines工作原理

流水线的定义可以分为两步，首先是定义组件，组件可以从镜像开始完全自定义。这里介绍一下自定义的方式：首先需要打包一个Docker镜像，这个镜像是组件的依赖，每一个组件的运行，就是一个Docker容器。其次需要为其定义一个python函数，描述组件的输入输出等信息，这一定义是为了能够让流水线理解组件在流水线中的结构，有几个输入节点，几个输出节点等。接下来组件的使用就与普通的组件并无二致了。实现流水线的第二步，就是根据定义好的组件组成流水线，在流水线中，由输入输出关系会确定图上的边以及方向。在定义好流水线后，可以通过 python中实现好的流水线客户端提交到系统中运行。虽然kubeflow/pipelines的使用略显复杂，但它的实现其实并不麻烦。整个的架构可以分为五个部分，分别是ScheduledWorkflow CRD以及其operator流水线前端，流水线后端，Python SDK和persistence agent。

ScheduledWorkflow CRD扩展了argoproj/argo的Workflow定义。这也是流水线项目中的核心部分，它负责真正地在上按照拓扑序创建出对应的容器完成流水线的逻辑。
- Python SDK负责构造出流水线，并且根据流水线构造出 ScheduledWorkflow的YAML定义，随后将其作为参数传递给流水线系统的后端服务。
- 后端服务依赖关系存储数据库（如MySQL）和对象存储（如S3），处理所有流水线中的CRUD请求。
- 前端负责可视化整个流水线的过程，以及获取日志，发起新的运行等。
- Persistence agent负责把数据从的etcd中sync到后端服务的关系型数据库中，其实现的方式与CRD operator类似，通过informer来监听对应资源实现。

Pipelines提供机器学习流程的创建、编排调度和管理，还提供了一个Web UI。这部分主要基于Argo Workflow。我相信这会是Kubeflow后续要大力发展的部分。

Fairing

Kubeflow Fairing是一个Python软件包，可轻松在Kubeflow上训练和部署ML模型。Fairing还可以扩展为在其他平台上进行训练或部署。目前，Fairing已扩展为可在Google AI Platform上进行训练。 Fairing简化了在混合云环境中构建，训练和部署机器学习（ML）训练job的过程。通过使用Fairing并添加几行代码，可以直接从Jupyter notebook在本地或在云中使用Python代码运行ML训练作业。训练工作完成后，可以使用Fairing将训练后的模型部署为预测端点。上面介绍了Kubeflow代码编辑器Jupyter Notebooks，用于将代码打包构建image的Fairing，以及工作流组件Pipelines核心组件，下面我们再介绍用来调参的Katib和发布部署服务的KFServing。

Katib

在了解katib的处理流程之前，先介绍下katib目前有哪些组件：

Experiment Controller：提供对Experiment CRD的生命周期管理。
Trial Controller：提供对Trial CRD的生命周期管理。
Suggestions：以Deployment的方式部署，用Service方式暴露服务，提供超参数搜索服务。目前有随机搜索，网格搜索，贝叶斯优化等。
Katib Manager：一个GRPC server，提供了对Katib DB的操作接口，同时充当Suggestion与 Experiment之间的代理。
Katib DB：数据库。其中会存储Trial和Experiment，以及Trial的训练指标。目前默认的数据库为 MySQL。

Katib架构

Katib工作原理

当一个Experiment被创建的时候，Experiment Controller会先通过Katib Manager在Katib DB中创建一个Experiment对象，并且打上Finalizer表明这一对象使用了外部资源（数据库）。随后，Experiment Controller会根据自身的状态和关于并行的定义，通过Katib Manager提供的GRPC接口，让Manager通过 Suggestion提供的GRPC接口获取超参数取值，然后再转发给Experiment Controller。在这个过程中，Katib Manager是一个代理的角色，它代理了Experiment Controller对Suggestion的请求。拿到超参数取值后，Experiment Controller会根据Trial Template和超参数的取值，构造出Trial的定义，然后在集群中创建它。

Trial被创建后，与Experiment Controller的行为类似，Trial Controller同样会通过Katib Manager在Katib DB中创建一个Trial对象。随后会构造出期望的Job（如batchv1 Job，TFJob，PyTorchJob等）和Metrics Collector Job，然后在集群上创建出来。这些Job运行结束后，Trial Controller会更新Trial的状态，进而Experiment Controller会更新Experiment的状态。然后Experiment会继续下一轮的迭代。之前的Trial已经被训练完成，而且训练的指标已经被收集起来了。Experiment会根据配置，判断是否要再创建新的Trial，如果需要则再重复之前的流程。下图是从网络上（知乎@高策）找到的Katib竞品对比分析图，可供参考：

超参优化是一种AutoML的方法。KubeFlow把Katib集成进来作为超参优化的一种方案。超参优化在实际的工作中还没有被大规模的应用，所以这部分的技术还需要一些时间来成熟。

KFServing

对于深度学习的产品化来说，训练只是手段不是目的，目的是将通过训练产生的模型放到手机的程序里或者互联网的应用中，用于语音或者文字的识别等应用场景中。

模型的服务化部署和离线预测也是机器学习流程中非常重要的部分。KubeFlow组件中可以看到，它提供基于TF Serving，KFServing，Seldon Core Serving等好几种方案。由于机器学习框架很多，算法模型也各种各样。工业界一直缺少一种能真正统一的部署框架和方案。这方面KubeFlow也仅仅是把常见的都集成了进来，但是并没有做更多的抽象和统一。 Kubeflow提供两个支持多框架的模型服务工具：KFServing和Seldon Core Serving。或者，可以使用独立的模型服务系统，以便可以选择最能满足模型服务要求的框架。对于TensorFlow模型，可以使用TensorFlow Serving将TFJob导出的模型进行实时预测。但是，如果打算使用多个框架，则应考虑如上所述使用KFServing或Seldon Core Serving。KFServing是Kubeflow项目生态系统的一部分，Seldon Core Serving是Kubeflow支持的外部项目。看起来KubeFlow社区更倾向KFServing这套方案。

KFServing提供了 CRD，用于在任意框架上服务机器学习（ML）模型。它旨在通过为常见ML框架（Tensorflow，XGBoost，ScikitLearn，PyTorch和ONNX等）提供高性能，高抽象的接口来解决模型服务用例。

NVIDIA Triton Inference Server是一项REST和GRPC服务，用于对TensorRT，TensorFlow，Pytorch，ONNX和Caffe2模型进行深度学习推理。该服务器经过优化，可以在GPU和CPU上大规模部署机器学习算法。Triton推理服务器以前称为TensorRT推理服务器。我们可以将NVIDIA Triton Inference Server用作独立系统，但如上所述，更应该考虑使用KFServing。KFServing也包括对NVIDIA Triton Inference Server的支持。赞！现在我们终于知道如何发布我们训练好的服务了！