作者
本文是系列文章的第二部分，在这一部分中，我们将介绍使用 Mlflow 记录模型、将其作为 API 端点提供以及最后根据应用需求对其进行扩展的过程。在上一篇文章中，我们介绍了如何在 k8s 上部署跟踪实例，并检查了实际操作的先决条件（秘密、环境变量......）。.
下面，我们将展示如何为已在 Mlflow 中注册的机器学习模型提供服务，并将其作为 API 端点在 k8s 上公开。.
第 2 部分--如何在 Kubernetes 上将模型作为 API 提供？
导言
显而易见，跟踪和优化模型性能是创建 ML 模型的重要部分。一旦完成，下一个挑战就是将它们集成到应用程序或产品中，以便使用它们的预测结果。这就是我们所说的模型服务或推理。有不同的框架和技术可以让我们做到这一点。不过，在这里我们将重点介绍 Mlflow，并向大家展示它是如何高效、直接地完成这项工作的。.
构建和部署服务映像
这里使用的不同配置文件是 实践库 基本上，我们需要
1.准备好 Mlflow 服务的 docker 镜像，并将其推送到 GCP 上的容器注册中心。.
cd mlflow-serving-exampledocker build --tag $/mlflow_serving:v1
--文件 docker_mlflow_serving .docker push $/mlflow_serving:v1
2.准备 Kubernetes 部署文件
通过修改容器部分并将其映射到 docker 映像 先前推送到 GCR、, 模型路径 和 服务端口。.
| api 版本: apps/v1 | |
| 一种: 部署 | |
| 元 data: | |
| 名字: mlflow-serving | |
| 标签: | |
| 应用: 服务-ML-模型-mlflow | |
| 规格: | |
| 复制品: 1 | |
| 选举人: | |
| matchLabels: | |
| 应用: mlflow-serving | |
| 模板: | |
| 元 data: | |
| 标签: | |
| 应用: mlflow-serving | |
| 规格: | |
| 集装箱: | |
| - 名字: mlflow-serving | |
| 图像: GCR_REPO/mlflow_serving:v1 #change here | |
| 环境: | |
| - 名字: MODEL_URI | |
| 价值: “gs://../artifacts/../../artifacts/..“ #change here | |
| - 名字: 服务端口 | |
| 价值: “8082“ | |
| - 名字: 谷歌应用程序凭据 | |
| 价值: “/etc/secrets/keyfile.json“ | |
| 卷挂载: | |
| - 名字: gcsfs-creds | |
| mountPath: “/etc/secrets“ | |
| 只读: 真 | |
| 资源: | |
| 要求: | |
| CPU: “1000m“ | |
| 流量: | |
| - 名字: gcsfs-creds | |
| 秘密: | |
| 秘密名称: gcsfs-creds | |
| 项目: | |
| - 密钥: keyfile.json | |
| 路: keyfile.json |
3.运行部署命令
kubectl create -f deployments/mlflow-serving/mlflow_serving.yaml
4.将部署对外开放
通过以下命令，将创建一个新资源，用于将外部流量重定向到我们的 API。.
kubectl expose deployment mlflow-serving --port 8082 --type="LoadBalancer"
5.检查部署情况并查询端点
如果部署成功，mlflow-serving 应已启动，并且有一个 pod 可用。您可以键入 kubectl get pods
最后一步是检查分配给将流量重定向到 API 容器的负载平衡器的外部 IP 地址，使用 kubectl get services 并测试对一些查询的响应。.
执行这些查询的代码示例如下 笔记本 其中，我们加载了 data 的几行数据，选择了特征，将其转换为 JSON 格式，并通过 post request 将其发送到 API。.
现在，结合我们之前和当前文章中的步骤，我们的最终架构将如下所示：
结论
在本文中，我们展示了如何使用 Mlflow 服务模块将机器学习模型作为 API 端点轻松部署。.
您可能会注意到，在我们当前的部署中，只创建了一个 pod 来为模型提供服务。虽然这对于我们不需要进行多次并行查询的小型应用程序来说效果不错，但对于其他应用程序来说，这很快就会显示出它的局限性，因为单个 pod 的资源是有限的。此外，这样一来，应用程序就无法使用超过一个节点的计算能力。在本系列的下一篇也是最后一篇文章中，我们将讨论可扩展性问题。我们将首先强调瓶颈问题，并尝试解决这些问题，以便获得一个可扩展的应用程序，充分利用 Kubernetes 集群的强大功能。.
