使用 Kubeflow Pipelines 基准测试脚本

本指南解释了 Kubeflow Pipelines 基准测试脚本，并演示了如何使用它们来收集给定 Kubeflow Pipelines 实例的基本性能数据。

关于 Kubeflow Pipelines 基准测试脚本

Kubeflow Pipelines 基准测试脚本模拟典型工作负载并记录性能指标，例如服务器延迟和 pipeline run 持续时间。为了模拟典型工作负载，基准测试脚本会将 pipeline manifest 文件上传到 Kubeflow Pipelines 实例作为 pipeline 或 pipeline 版本，并同时创建多个 runs。

您可以指定基准测试脚本中使用的 pipelines manifest，也可以使用预加载的示例 pipelines 之一。例如，可以使用 Kubeflow pipelines 中的预加载示例。此外，使用代表您特定用例的 pipeline manifest 也是一个好习惯。例如，如果您的 Kubeflow Pipelines 集群主要用于图像识别任务的 pipelines，那么在基准测试脚本中使用图像识别 pipeline 将是理想的选择。

选择合适的 pipeline 后，基准测试脚本将如前所述同时运行它多次。在 Kubeflow Pipelines 可以执行的所有操作中，运行 pipeline 无疑是最不可预测且成本最高的操作。其他操作，例如创建 pipeline（版本）或创建 experiment，通常会产生可预测且适中的成本。例如，创建 pipeline 版本会在 pipeline 版本表中引入新行，并在 minio 服务器中创建新文件。新文件的大小取决于 pipeline 版本的 manifest。如果我们排除极少数情况下 manifest 极大，并假设每个创建的 pipeline 版本都有平均大小的 manifest，则创建 pipeline 版本的总成本会随着 pipeline 版本数量的增加而线性增长。然而，另一方面，运行 pipeline 或 pipeline 版本的成本涉及更多不确定性，有时成本相当高。pipeline 或 pipeline 版本可以包含任意组件，因此运行 pipeline 或 pipeline 版本可能会产生任意的时间和空间复杂度。例如，pipeline 中的某个步骤可以使用执行非常昂贵训练任务的自定义容器镜像。此外，Kubeflow Pipelines 实例中的 runs 比 pipelines、pipeline 版本、experiments 等消耗更多的 DB 空间。因此，为了了解 Kubeflow Pipelines 实例中的性能和可伸缩性痛点，更有效地方法是关注工作负载中的 run 操作。

运行基准测试脚本的先决条件

要运行提供的基准测试脚本，您需要以下条件

• 一个 Jupyter notebook 环境，能够访问您的 Kubeflow Pipelines 集群上的 Kubeflow Pipelines API。例如，您必须能够从 Jupyter notebook 环境中调用 pipeline、pipeline 版本、run、job 和 experiment 服务的 CREATE、GET、DELETE 和 LIST 方法。
• 一个 Kubeflow Pipelines 集群。如果您没有 Kubeflow Pipelines 集群，请了解 安装 Kubeflow Pipelines 的更多选项。
• 一个 pipeline manifest。例如，本指南使用 taxi_updated_pool.yaml pipeline manifest 文件。

下面展示了设置一切并运行基准测试脚本的一种方法作为示例。

运行基准测试脚本

使用以下说明在您的 Kubeflow Pipelines 集群上运行基准测试脚本。

1. 在您的 Jupyter notebook 环境中下载 run_service_api.ipynb 基准测试脚本。

2. 在本地 Jupyter notebook 中打开 run_service_api.ipynb。此基准测试脚本会

   1. 创建新的 pipeline。
   2. 使用此 pipeline 的默认 pipeline 版本创建多个 runs。
   3. 记录成功 runs 的数量。
   4. 记录每个成功 run 的持续时间。
   5. 记录 CREATE、GET、DELETE 的延迟。
   6. 清理 pipeline 及其默认 pipeline 版本、experiment 和 runs。

3. 在基准测试脚本中，输入 host、pipeline_file_url、num_runs、run_status_polling_interval_sec 的正确值。

   • host：您的 Kubeflow Pipelines 集群中 API 服务器的 URL。

   • pipeline_file_url：用于基准测试的 pipeline manifest 文件的 URL。本示例使用 taxi_updated_pool.yaml。此示例 pipeline 使用 nodeSelector 将此 pipeline 的 runs 显式调度到名为 pool-1 的节点池上。如果您在基准测试中使用 taxi_updated_pool.yaml pipeline manifest，请确保您的集群中存在一个名为 pool-1 的节点池。

     注意：运行基准测试时，请勿使用 https://storage.cloud.google.com/ml-pipeline/sample-benchmark/taxi_updated_pool.yaml 的值。以 storage.cloud.google.com 开头的地址会产生重定向，这与 Kubeflow Pipelines 的兼容性不好。

   • num_runs：指定在基准测试脚本中将创建多少个 runs，是模拟工作负载的直接指标。

     注意：在云服务上运行基准测试脚本会因消耗云资源而产生费用。

   • run_status_polling_interval_sec：设置两次相邻 run 状态轮询之间的时间间隔。当 run 达到成功状态时，会记录 run 持续时间。仅记录成功 runs 的持续时间。

4. 参数设置正确后，您可以在 notebook 中运行基准测试脚本。

以下快照显示了在具有两个节点池的 Kubernetes 集群上，使用 taxi_updated_pool.yaml pipeline manifest 对 50 个 runs 运行基准测试脚本 run_service_api.ipynb 的结果。每个节点池包含三台 n1-standard-8 机器类型的节点。

解释结果

在上面的示例输出中，有两种图表。一种是分布图，用于测量延迟和持续时间；另一种是计数图，用于计算成功和失败的 runs。阅读这些图表通常很直观。

在计数图中，x 轴表示可能的 run 状态：成功或失败；y 轴分别显示有多少 runs 属于某种状态。

在分布图中，显示了直方图和 rug 图。此外，还可以显示 KDE (Kernel Density Estimate) 图。如果需要 KDE 图，请在 distplot() 方法中使用 kde=True。

使用不同配置进行调优

上述示例显示了通过运行基准测试脚本获得的一个性能报告。实际上，有多种方法可以调整 pipeline 和/或 Kubernetes 集群以获取性能报告。常见的方法包括尝试不同的

• 不同的集群大小/区域，集群中不同数量的池，每个池中不同数量的节点，不同的节点配置（例如，每个节点的 RAM 和磁盘配置，每个节点的 CPU 或 GPU 配置）

• 不同数量的 runs

• 不同的 pipeline 大小/复杂度，例如 pipeline 中的步骤数量

• 不同的运行配置，例如指定用于运行组件或 pipelines 的节点池

• 等等。

限制和未来工作

当基准测试脚本调整为生成适度工作负载时，例如上述示例中的 50 个 runs，可以正确进行延迟和 run 持续时间测量。然而，观察 Kubeflow Pipelines 实例在某些极端重负载下的表现或崩溃情况也很有趣，换句话说，探测 Kubeflow Pipelines 实例。示例基准测试脚本也可以用于此目的。在这种情况下，基准测试脚本的测量图表不再是预期的输出。相反，错误和错误日志提供了关于 Kubeflow Pipelines 部署性能和可伸缩性的信息。借助它们，可以发现并修复 bug 和痛点。此外，当使用极端工作负载探测 Kubeflow Pipelines 实例时，在服务器代码中添加内部监控来跟踪服务器性能将非常有帮助。例如，未来最好使用 Prometheus 来跟踪和可视化 Kubeflow Pipelines 服务器的指标。

服务器内部的性能监控与客户端的性能测量互补。当示例基准测试脚本测量客户端的延迟时，结果测量取决于 Kubeflow Pipelines 实例和网络传输。另一方面，内部监控侧重于服务器在收到特定请求后的实际处理成本。因此，同时拥有客户端测量和服务器端监控对于准确分析 Kubeflow Pipelines 的性能和可伸缩性非常有用。

联系方式

如果您在使用基准测试脚本时遇到任何问题，或者对 Kubeflow Pipelines 的性能和可伸缩性分析有任何建议，请向我们 提出问题。