我试图寻找何时创建您自己的 Kubeflow MLOps 平台是有意义的：
The*_*tou 25
构建 MLOps 平台是公司为加速和管理数据科学家在生产中的工作流程而采取的行动。该工作流程反映在 ML 管道中，包括feature engineering、training和3 个主要任务serving。
特征工程和模型训练是需要管道编排器的任务，因为它们与后续任务具有依赖性，这使得整个管道容易出错。
软件构建管道不同于数据管道，而数据管道又不同于机器学习管道。
软件CI/CD 流程将代码编译为可部署的工件，并加速软件交付过程。所以，代码输入，工件输出。它是通过调用编译任务、执行测试和部署工件来实现的。此类管道的主要协调器是 Jenkins、Gitlab-CI 等。
数据处理流程获取原始数据并执行转换以创建特征、聚合、计数等。因此数据输入、数据输出。这是通过调用远程分布式任务来实现的，远程分布式任务通过在数据存储库中存储中间工件来执行数据转换。用于此类管道的工具有 Airflow、Luigi 和一些 hadoop 生态系统解决方案。
在机器学习流程中，机器学习工程师编写代码来训练模型，使用数据来评估它们，然后观察它们在生产中的表现以改进它们。所以代码和数据输入，模型输出。因此，此类工作流程的实现需要结合我们上面讨论的编排技术。
TFX展示了该管道并建议使用执行这些后续任务的组件。它定义了一个现代、完整的机器学习管道，从构建功能到运行训练、评估结果、在生产中部署和服务模型
Kubernetes是用于编排容器的最先进的系统，是在生产中运行工作负载的事实上的工具，是与云无关的解决方案，可帮助您摆脱云供应商的锁定，从而优化您的成本。
Kubeflow被定位为通过实现 TFX 在 Kubernetes 中进行 ML 的方式。最终它处理模型输出中的代码和数据。它通过以 kubernetes 资源（称为notebooks. 所有云提供商都参与了该项目，并在 KF 的组件中实施了他们的数据加载机制。编排是通过KF 管道实现的，模型的服务是通过KF 服务实现的。其组件的元数据在整个平台的 kubernetes 资源规范中指定。
在 Kubeflow 中，TFX 组件以可重用任务的形式存在，并作为容器实现。这些组件生命周期的管理是通过KF管道的编排器Argo来实现的。Argo 将这些工作流程实现为 kubernetes CRD。在规范中workflow，我们定义了 dag 任务、作为容器的 TFX 组件、将写入元数据存储中的元数据等。这些工作流程的执行使用 Pod 等标准 kubernetes 资源以及自定义资源定义（如experiments。这使得管道和组件的实现与语言无关，unline Airflow 仅在 python 中实现任务。然后，这些任务及其生命周期由 kubernetes 本地管理，无需使用 Airflow 的 kubernetes-operator 等管道胶带解决方案。由于所有内容都是作为 kubernetes 资源实现的，因此所有内容都是 yaml，因此您可以找到最适合 Git 的配置。祝您尝试在 Airflow 的 dag 目录中实施版本控制好运。
生产中模型的部署和管理是通过使用 的 CRD 的KF 服务inferenceservice完成的。它利用Istio通过其无服务器资源对模型的安全访问，virtualservices使用Knative Serving的从零缩放pods，revisions进行版本控制，利用 prometheusmetrics进行可观察性，logs在 ELK 中进行调试等。在生产环境中运行模型对 SRE 来说再友好不过了。
关于在云和本地之间分割培训/服务的主题，kubernetes 的使用更为重要，因为它抽象了每个提供商的自定义基础设施实现，从而为开发人员/机器学习工程师提供了统一的环境。