针对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的主要组件进行简单的介绍：
(1) Central Dashboard：Kubeflow的dashboard看板页面
(2) Metadata：用于跟踪各数据集、作业与模型
(3) Jupyter Notebooks：一个交互式业务IDE编码环境
(4) Frameworks for Training：支持的ML框架
ChainerMPIMXNetPyTorchTensorFlow(5) Hyperparameter Tuning：Katib，超参数服务器
(6) Pipelines：一个ML的工作流组件，用于定义复杂的ML工作流
(7) Tools for Serving：提供在上对机器学习模型的部署
KFServingSeldon Core ServingTensorFlow Serving(TFJob):提供对Tensorflow模型的在线部署，支持版本控制及无需停止线上服务、切换模型等NVIDIA Triton Inference Server(Triton以前叫TensorRT)TensorFlow Batch Prediction(8) Multi-Tenancy in Kubeflow：Kubeflow中的多租户
(9) 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，它对许多资源具有命名空间范围的权限，其中包括：
PodDeploymentServiceJobTFJobPyTorchJob因此，可以直接从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)，处理所有流水线中的C
