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