参考网址:Kubeflow-K8S的机器学习工具包,太牛了! - 知乎

什么是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-OperatorPyTorch-OperatorCaffe2-OperatorMPI-OperatorMXNet-Operator
  • Katib是基于各个Operator实现的超参数搜索和简单的模型结构搜索的系统,支持并行搜索和分布式训练等。超参优化在实际的工作中还没有被大规模的应用,所以这部分的技术还需要一些时间来成熟
  • Serving支持部署各个框架训练好的模型的服务化部署和离线预测。Kubeflow提供基于TFServingKFServingSeldon等好几种方案。由于机器学习框架很多,算法模型也各种各样。工业界一直缺少一种能真正统一的部署框架和方案。这方面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 SDKpersistence agent

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

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

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐