Kubeflow核心组件
训练operator - JupyterHub是用于数据初始实验和ML作业原型的良好工具。然而，当在生产中进行训练时，Kubeflow提供了一些训练组件来自动执行机器学习算法，包括： - ·Chainer训练 - ·MPI训练 - ·Apache MXNet训练 - ·PyTorch训练 - ·TensorFlow训练 - 在Kubeflow中，分布式训练作业由特定于应用程序的控制器（称为operator）管理。这些operator扩展了Kubernetes API，用于创建、管理和修改资源的状态。例如，要运行一个分布式的TensorFlow训练作业，用户只需要提供一个描述所需状态的规范（工作节点和参数服务器的数量等），TensorFlow operator组件将负责其余的工作，并负责管理训练作业的生命周期。 - 这些operator允许自动化重要的部署概念，例如，可扩展性、可观测性和故障转移。它们也可以被Pipeline使用，与系统中的其他组件进行链式执行。
Kubeflow Pipeline - 除了提供实现特定功能的专门参数外，Kubeflow还包括Pipeline组件，用于编排机器学习应用程序的执行。Pipeline实现基于Argo Workflow，这是一个开源的、容器原生的Kubernetes工作流引擎。Kubeflow安装了所有的Argo组件。 - 在高层次上，Pipeline的执行包含以下组件： - Python SDK - 你可以使用Kubeflow Pipeline领域专用语言（DSL）创建组件或指定Pipeline。 - DSL编译器 - DSL编译器将Pipeline的Python代码转换为静态配置（YAML）。 - Pipeline Service - Pipeline Service从静态配置中创建一个Pipeline运行。 - Kubernetes资源 - Pipeline Service调用Kubernetes API服务器来创建必要的Kubernetes自定义资源定义（CRD）来运行Pipeline。 - 编排控制器 - 一组编排控制器执行Kubernetes资源指定Pipeline所需的容器。容器在虚拟机上的Kubernetes pod中执行。一个示例控制器是Argo Workflow控制器，它负责编排任务驱动的工作流。 - 制品存储 - Kubernetes pod存储以下两类数据。 - 元数据 - 实验、作业、运行、单标量指标（一般为排序和过滤而汇总）等。Kubeflow Pipeline将元数据存储在MySQL数据库中。 - 制品 - Pipeline包、视图、大规模指标（如时间序列）通常用于调试和检测单个运行的性能。Kubeflow Pipeline将制品存储在MinIO服务器（https://docs.minio.io）、Google Cloud Storage（GCS）或Amazon S3（https://aws.amazon.com/s3）等存储库中。 - Kubeflow Pipeline让你拥有了让机器学习作业重复持续进行并处理新数据的能力。它在Python中提供了一个直观的DSL来编写Pipeline。随后，Pipeline会被编译成现有的Kubernetes工作流引擎（目前是Argo工作流）。Kubeflow的Pipeline组件使得用于构建端到端机器学习项目的所需工具更加容易使用和协调。除此之外，Kubeflow可以同时跟踪数据和元数据，提高我们对作业的理解能力。Pipeline还可以公开内置的机器学习算法的参数，方便Kubeflow进行调优。
超参调优 - 为训练模型寻找合适的超参集可能是一项很有挑战性的任务。传统的方法（如网格搜索）不仅耗时且相当乏味。现有的超参系统大多被绑定在一个机器学习框架上，只有少数几个参数空间的搜索选项。 - Kubeflow提供了Katib组件，方便用户在Kubernetes集群上轻松执行超参优化。Katib的灵感来自Google的黑盒优化框架Vizier。它利用贝叶斯优化等先进的搜索算法来寻找最优的超参配置。 - Katib支持超参调优，并可以与任何深度学习框架集成工作，这些框架包括TensorFlow、MXNet和PyTorch。 - 与Google Vizier一样，Katib基于4个主要概念： - 实验（experiment） - 在可行空间上的单一优化运行。每个实验都包含描述可行空间的配置以及一组尝试。假设目标函数f（x）在实验过程中不发生变化。 - 尝试（trial） - 一个参数值列表x，将导致f（x）的单一评估。一次尝试可以是“完成”，即已经对它进行了评估，并给它分配了目标值f（x）；否则就是“待定”。一次尝试对应一个作业。 - 作业（job） - 负责评估“待定”尝试并计算其目标值的过程。 - 建议（suggestion） - 一种构建参数集的算法。目前，Katib支持以下探索算法： - ·随机（Random） - ·网格（Grid） - ·超频（Hyperband） - ·贝叶斯优化 - 通过使用这些核心概念，你可以提高模型的性能。由于Katib不绑定在一个机器学习库上，因此你可以用最少的修改探索新的算法和工具。
模型推理 - Kubeflow使在大规模生产环境中轻松部署机器学习模型变得容易。它提供了几种模型服务选项，包括TFServing、Seldon服务、PyTorch服务和TensorRT。它还提供了一个总括性的实施方案KFServing（https://oreil.ly/qEvqq），包括自动缩放、联网、健康检查和服务器配置等模型推理的关注点。 - KFServing的整体实现是基于利用Istio（https://istio.io）（后面会讲到）和Knative服务（https://knative.dev）——Kubernetes上的Serverless容器。正如Knative文档中所定义的那样，Knative服务项目提供了中间件原语： - ·快速部署Serverless容器 - ·自动扩容和缩容至零 - ·Istio组件的路由和网络编程 - 由于模型服务本身就很棘手，所以快速的扩缩容很重要。通过自动将请求路由到较新的模型部署，Knative服务简化了对模型持续更新的支持。这就需要将未使用的模型缩容到零（最小化资源利用率），同时保持功能回滚的能力。由于Knative是云原生的，它受益于基础架构技术栈，因此提供了Kubernetes集群中的监控能力，如日志记录、跟踪和监控。KFServing还通过Knative事件为可插拔的事件源提供了可选的支持。 - 与Seldon类似，每个KFServing部署都是一个编排器，将以下组件连接在一起： - 前置处理器 - 可选的组件，负责将输入数据转换为模型服务所需的内容或格式。 - 预测器 - 必选组件，负责实际的模型服务。 - 后置处理器 - 可选的组件，负责将模型服务结果转换/加强为输出所需的内容或格式。 - 其他组件可以增强整体模型服务的实施，但不在执行Pipeline之内。异常检测和模型解释器等工具可以在此环境中运行，且不会降低整个系统的速度。 - 虽然所有这些单独的组件和技术已经存在了很长时间，但将它们集成到Kubeflow的服务系统中，可以降低将新模型引入生产带来的复杂性。 - 除了直接支持ML操作的组件外，Kubeflow还提供了一些支持组件。
元数据 - Kubeflow的重要组成部分是元数据管理，它提供了捕获和跟踪有关模型创建信息的功能。许多组织每天都建立数百个模型，但是很难管理所有模型的相关信息。ML元数据既是一个基础设施，也是一个库，用于记录和检索与ML开发人员和数据科学家的工作流相关的元数据。可在元数据组件中注册的信息包括： - ·用于创建模型的数据来源。 - ·通过Pipeline中的组件/步骤产生的制品。 - ·组件/步骤的执行情况。 - ·Pipeline和关联的沿袭信息。 - ML元数据跟踪ML工作流中所有组件和步骤的输入输出以及沿袭信息。
标签：Pipeline,架构,Kubernetes,模型,notebook,Kubeflow,组件 From： https://www.cnblogs.com/muzinan110/p/18031944