Kubeflow机器学习工具包-概述_kubeflow中文文档-CSDN博客

什么是Kuberflow

Kubeflow是Kubenetes的机器学习工具包。Kubeflow是运行在k8s之上的一套技术栈，这套技术栈包含了很多组件，组件之间的关系比较松散，我们可以配合起来用，也可以单独用其中的一部分。下图为Kuberflow官网上所展示的架构图：

当我们开发和部署ML系统时，ML工作流程通常包括几个阶段。开发ML系统是一个反复的过程。我们需要评估ML工作流各个阶段的输出，并在必要时对模型和参数进行更改，以确保模型不断产生所需的结果。

为了便于理解，下图按顺序显示了工作流程阶段，并将Kubeflow添加到工作流中，显示在每个阶段都有哪些Kubeflow组件有用。工作流末尾的箭头指向流程，以表示流程的迭代性质：

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

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

Kubeflow的优势

0侵入性，为用户提供与本地开发相似或相同的体验（Jupyter）
基于云的环境，为用户提供更高级的特性（分布式训练、工作流编排）
与后续机器学习流程的对接（部署等）

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工作流；是一个基于Argo实现了面向机器学习场景的流水线项目，机器学习流程的创建、编排调度和管理，还提供了一个Web UI
Tools for Serving: 提供在Kubernetes上对机器学习模型的部署
- 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的组件
Operator：是针对不同的机器学习框架提供资源调度和分布式训练的能力（TF-Operator，PyTorch-Operator，Caffe2-Operator，MPI-Operator，MXNet-Operator）
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，因为缺乏隔离和资源限制，目前仅适用数据科学家的solo场景，无法支持数据科学家团队合作场景。所以平心而论，它还未获得用户的信任。

Kubeflow将default-editor ServiceAccount 分配给Jupyter notebook Pod。该服务账户绑定到kubeflow-edit ClusterRole，它对许多Kubernetes资源具有命名空间范围的权限，其中包括：

Pod
Deployment
Service
Job
TFJob
PyTorchJob

因此，可以直接从Kubeflow中的Jupyter notebook创建上述Kubernetes资源。notebook中已预装了Kubernetes kubectl命令行工具，可以说也是非常简单了。

将Jupyter notebook绑定在Kubeflow中时，可以使用Fairing库使用TFJob提交训练作业。训练作业可以运行在单个节点，也可以分布在同一个Kubernetes集群上，但不能在notebook pod内部运行。通过Fairing库提交作业可以使数据科学家清楚地了解Docker容器化和pod分配等流程。

总体而言，Kubeflow-hosted notebooks可以更好地与其他组件集成，同时提供notebook image的可扩展性。

Pipelines

在Kubeflow v0.1.3之后， pipeline已经成为Kubeflow的核心组件。Kubeflow的目的主要是为了简化在Kubernetes上运行机器学习任务的流程，最终希望能够实现一套完整可用的流水线，来实现机器学习从数据到模型的一整套端到端的过程。而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创建的Kubernetes资源，并将这些资源的状态持久化在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定义。这也是流水线项目中的核心部分，它负责真正地在Kubernetes上按照拓扑序创建出对应的容器完成流水线的逻辑。
Python SDK负责构造出流水线，并且根据流水线构造出 ScheduledWorkflow的YAML定义，随后将其作为参数传递给流水线系统的后端服务。
后端服务依赖关系存储数据库（如MySQL）和对象存储（如S3），处理所有流水线中的CRUD请求。
前端负责可视化整个流水线的过程，以及获取日志，发起新的运行等。
Persistence agent负责把数据从Kubernetes Master的etcd中sync到后端服务的关系型数据库中，其实现的方式与CRD operator类似，通过informer来监听 Kubernetes apiserver对应资源实现。