kubeflow--使用图形界面

Posted 2023-03-19

参考技术A 按照前几篇文章搭建好Kubeflow集群后，所有的pod都能运行了。但是在自己本地浏览器访问界面时却发现网页一直打不开。访问不了jupyter。这样因为默认的这些服务都是使用cluster ip。只能集群内部访问，外网访问不了。

解决方法：
（1）查看当前的服务：kubectl -n kubeflow get svc

如图所示，这里注意，这是我修改完的结果，ambassador服务已经是LoadBalancer模式。未修改前所有的都应该是ClusterIP或者nodeport。

（2）修改模式的yaml文件
kubectl -n kubeflow edit svc ambassador

将 Type 修改成 LoadBalancer，并且新增 externalIPs 指定为 Master IP

（3）保存退出，这个时候在浏览器中输入你的 master ip就可以访问图形界面了。

Kubeflow 与其他选项 [关闭]

【中文标题】Kubeflow 与其他选项 [关闭]

【英文标题】：Kubeflow vs other options [closed]

【发布时间】：2020-07-02 09:16:42

【问题描述】：

我正在尝试寻找创建自己的 Kubeflow MLOps 平台的时机：

如果你只是 Tensorflow 商店，你还需要 Kubeflow 吗？为什么不只是 TFX？可以使用 Airflow 进行编排。 如果您使用的是 scikit-learn，为什么还要使用 Kubeflow，因为它不支持 GPU，无论如何，分布式训练？可以使用 Airflow 进行编排。 如果您确信使用 Kubeflow，云提供商（Azure 和 GCP）正在提供 ML 管道概念（Google 在后台使用 Kubeflow）作为托管服务。那么什么时候部署自己的 Kubeflow 环境才有意义呢？即使您需要在本地部署，您也可以选择使用云资源（云上的节点和数据）来训练您的模型，并且只将模型部署到本地。因此，使用 Azure 或 GCP AI Platform 作为托管服务最适合交付 ML 管道？

【问题讨论】：

市场上有很多可用的工具！我认为使用 Ploomber 是有意义的，因为它使团队能够快速移动并构建模块化管道。此外，它非常容易上手。看看这个！ github.com/ploomber/ploomber

【参考方案1】：

构建 MLOps 平台是公司为加速和管理生产中数据科学家的工作流程而采取的行动。此工作流体现在 ML 管道中，包括 feature engineering、training 和 serving 三个主要任务。

特征工程和模型训练是需要管道编排器的任务，因为它们依赖于后续任务，这使得整个管道容易出错。

软件构建管道不同于数据管道，而数据管道又不同于 ML 管道。

软件 CI/CD 流程将代码编译为可部署的工件并加速软件交付过程。所以，代码输入，工件输出。它是通过调用编译任务、执行测试和部署工件来实现的。此类管道的主要编排器是 Jenkins、Gitlab-CI 等。

数据处理流程获取原始数据并执行转换以创建特征、聚合、计数等。因此数据输入，数据输出。这是通过调用远程分布式任务来实现的，这些任务通过将中间工件存储在数据存储库中来执行数据转换。此类管道的工具有 Airflow、Luigi 和一些 hadoop 生态系统解决方案。

在机器学习流程中，ML 工程师编写代码来训练模型，使用数据对其进行评估，然后观察它们在生产中的表现以改进它们。所以编码和数据，模型出来。因此，此类工作流的实现需要结合我们上面讨论的编排技术。

TFX 展示了这个管道，并建议使用执行这些后续任务的组件。它定义了一个现代的、完整的 ML 管道，从构建功能到运行训练、评估结果、在生产中部署和服务模型

Kubernetes 是最先进的容器编排系统，是在生产中运行工作负载的实际工具，是与云无关的解决方案，可帮助您摆脱云供应商的束缚，从而优化您的成本。

Kubeflow 通过实现 TFX 定位为在 Kubernetes 中执行 ML 的方式。最终它处理代码和数据输入，模型输出。它通过以 kubernetes 资源的形式实现 jupyter notebook 来提供编码环境，称为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 目录中实施版本控制。

模型在生产中的部署和管理是通过KF服务使用inferenceservice的CRD完成的。它利用Istio 通过其virtualservices 对模型的安全访问，使用Knative Serving 的从零开始的规模pods、revisions 的无服务器资源用于版本控制，prometheus metrics 用于可观察性，logs 在 ELK 中用于调试等。在生产环境中运行模型对 SRE 的友好程度再好不过了。

在云和本地之间分离训练/服务的话题上，kubernetes 的使用更为重要，因为它抽象了每个提供者的自定义基础架构实现，从而为开发人员/ml 工程师提供了一个统一的环境.

【讨论】：

一个答案中包含了很多有用的信息。谢谢。