“ModelFlow” ，指流水化、可视化的实现AI模型的维护和部署。ModelFlow 是 DevOps 在ML领域的落地，实现了自动化、声明式、大规模的 ML Model 部署及管理。
Kubeflow 是基于容器的端到端 ModelFlow 解决方案，它构建在 k8s 生态系统之上，适用于各种个性化的模型开发场景，功能全面。
1. 前置知识
- K8S (Object, Kustomize, CRD)
- Golang
- Python
- Google ML Metadata
- Argo Workflow
2. Kubeflow 整体模块
Kubeflow 在不同的 AI 场景有不同的 Solution 可用，是一个大而全的 AI 运维平台。ML Model 的流水线部署主要由 KFP 解决，它能可视化的完成 Pipeline 的设计与运营。
| Solution | 描述 |
|---|---|
| Kubeflow Pipelines (KFP) | 一个用于构建和部署可移植且可扩展的机器学习工作流的平台，基于 Kubernetes |
| Kubeflow Notebooks | 允许在 Kubernetes 集群上用 Notebooks 的形式快捷地开发 |
| Kubeflow Central Dashboard | 集中的控制面板 |
| Katib (AutoML) | AutoML，简易化地实现超参数调优等技巧等高阶工具 |
| Kubeflow Training Operator | 统一的模型训练和微调接口，可在 Kubernetes 上运行可扩展和分布式训练任务，支持 PyTorch、TensorFlow、MPI、MXNet、PaddlePaddle 和 XGBoost 等框架 |
| KServe | 解决 Kubernetes 上的生产模型服务问题，为 TensorFlow、XGBoost、ScikitLearn、PyTorch 和 ONNX 等框架提供高度抽象和高性能接口 |
3. KFP 本机部署
KFP 是 Kubeflow 中最核心的流程编排模块。建议最好部署到虚拟机，因为一些 Mac 安全软件有限制，在本机Mac上部署不是最优方案。
3.1. 部署步骤
- 安装 Docker for Mac 并配置镜像
{
"registry-mirrors": [
"https://docker.m.daocloud.io"
]
}
2. 安装 Minikube 3. Standalone 安装 KFP
官方的这个方案有环境问题，参照3.2部署问题解决。
3.2. 部署问题
3.2.1. 部分 Pods 启动失败
Pod proxy-agent: 连接 GCP 内部地址失败，导致报错。
如果按照官方的 Standalone 指引安装 dev 环境的 kustomize，会带有依赖 GKE (Google Kubernetes Engine) 的 proxy-agent 服务。将指引中的 env/dev 替换为：
env/platform-agnostic
3.2.2. 调用接口失败
metadata 没有成功注入到 pipeline-ui
pipeline-ui 依赖 GKE 自动设置的 metadata 变量。有两种解决方案：
- 设置 dns record，metadata 解析到任意可连接地址。
- 在 pipeline-ui 的 pod 设置变量 DISABLE_GKE_METADATA=true
kubectl set env deployment/ml-pipeline-ui -n kubeflow DISABLE_GKE_METADATA=true
4. KFP 业务概念
Kubeflow Pipelines (KFP) 的整体逻辑可以分为几个关键部分来理解：
用户通过 KFP Python SDK 创建和编写 DSL；SDK 编译 DSL 后会生成 IR YAML中间表示文件。用户可以通过KFP Dashboard（仪表板界面）、KFP CLI（命令行工具），乃至 SDK 直连来上传和运行这些 YAML。
KFP Backend 是 YAML 配置的逻辑入口；作为后端服务，它负责接收和解析从客户端传来的YAML文件。解析后的内容会被组织成 Pipeline（管道）的形式，而 Pipeline 又由不同的 Components（组件）构成。
Pipeline 可以通过手动触发或循环触发的方式创建 Run（运行实例），每个 Run 都属于一个 Experiments。一个 Run 包含多个Step，Step 之间的输入输出可以生成 Artifacts（制品）。
Run 所有的运行记录和结果被存储在 ML Metadata 中，用于追踪和复现。
5. KFP 原理分析
5.1. KFP 架构
KFP 依赖于 Kubernetes 作为 Runtime，并通过 CRD 定义了多个集群级的 K8S 资源。KFP 默认依赖 Argo Workflow 编排和启动各种资源。Argo Workflow 是 K8S 上的工作流编排工具，支持 DAG，Parallel Run 等高级特性。
KFP 的一个重要功能是实现 ML Model 运行的可视化，这需要保存各类数据，包括 Pod 中的元数据，如时序度量指标、Run/Experiments配置、运行结果 Artifact 等。其中，元数据存储在 MySQL 数据库中，而制品存储在 MinIO。
为了获取资源的运行状态，KFP 使用 Persistence Agent 去监控随 Pipeline 运行创建的 Kubernetes 资源，并在元数据中实时维护相关的状态。
5.2. 模块整体分层（Pod 功能分析）
运行 Kubeflow Pipeline 需要一套成体系的模块，这些模块中只有一半和 KFP 直接相关。其他模块用于在数据存储、流程编排等方面支撑 KFP 运行。
抽象来看，Kubeflow Pipeline 的模块主要有以下几大类。
- KFP 核心，以"ml-" 为前缀的模块
- Cache；Kubeflow 自己实现，但独立部署
- Google ML Metadata
- MinIO
- MySQL
- Workflow-controller (argo)
| 模块/pod | 功能描述 |
|---|---|
| ml-pipeline | api-server，提供后端 API |
| ml-pipeline-persistenceagent | 监控 Pipeline 相关的 K8S Resource 的状态 |
| ml-pipeline-scheduledworkflow | 实现定时管道的 K8S CRD |
| ml-pipeline-ui | 提供 Web 界面 |
| ml-pipeline-viewer | 提供 tensorboard 的 K8S CRD |
| ml-pipeline-visualizationserver | 可视化渲染 |
| metadata-writer | 通过 K8S 事件监控 pipeline 执行，把元数据提取存储到 meta_store_server |
| metadata-envoy | 代理到 metadata-grpc 的 envoy，只比原生 envoy 增加了个性化 config；主要用于前端调试 |
| metadata-grpc | ml_metadata_store_server（MLMD）本身；名字中 grpc 为了表示其提供的接口协议类型 |
| cache-deployer & cache-server | 管理 Kubeflow 的缓存 |
| minio | 提供对象存储能力，argo-workflow 可用它存储制品 |
| mysql | 存储管道元数据和工作流信息的数据库 |
| workflow-controller | Argo Workflow，编排和管理 Pod 工作流 |
*打包核心模块的镜像的方法见：github.com/kubeflow/pi…
5.3. ml-pipeline 核心模块解析
| 组件名称 | 实现语言 | 代码位置 | 功能描述 |
|---|---|---|---|
| ml-pipeline (ml-pipeline-api-server) | Golang | backend/src/apiserver/*.go | 为前端提供各种后端接口 |
| ml-pipeline-visualizationserver | Python | backend/src/apiserver/visualization | 负责可视化渲染，接收并处理来自 api-server 的可视化请求 |
| ml-pipeline-persistenceagent | Golang | backend/src/agent | 监听 K8S 资源（argo workflow 和 ScheduledWorkflow）的运行状态并持久化（和 ML 业务状态不想关） |
| ml-pipeline-viewer | Golang | backend/src/crd/controller/viewer | K8S CRD，ML 实验的可视化 toolkit，可监控模型训练运行指标，只支持tensorboard(tensorflow) |
| ml-pipeline-scheduledworkflow | Golang | backend/src/crd/controller/scheduledworkflow | K8S CRD，当触发定义的 cron 条件时，能自动根据定义创建资源执行操作 |
| ml-pipeline-ui | 前端 | frontend/ | 提供前端界面 |
5.4. Google ML Metadata (MLMD)
Model 在训练运行过程中包含输入、输出，及中间状态数据。MLMD 实现结构化的保存这些中间数据，它提供了预置的类型（Artifacts、Executions等）属性、数据关联DAG、及版本回溯等能力。
MLMD 作为一种持久化中间件，分为客户端和中心端两个部分，客户端使用相应的 client libraries 远程连接到 MetadataStore 完成数据存储的代理增强。MLMD 支持自定义数据库作为数据源（Source），默认已支持 MySQL、SQLite。
KFP 集群中和 metadata 相关的有三种 Pod。KFP 实现了独立的 Pod (metadata-writer) 监控 Pipeline 运行，并把提取到的模型状态数据通过 MLMD Client 写入 MetadataStore (metadata-grpc)；metadata-grpc 后端默认连接 MySQL 进行元数据存储。metadata-envoy 只起到辅助作用，它通过 envoy 代理调用 metadata-grpc，以供前端对元数据进行调试。
5.4.1. Metadata Writer 原理
Metadata Writer 使用 Python 实现，代码位于：backend/metadata_writer。
它在一定程度上实现了自包含。故其 Cache 也由其自身实现，主要用于避免扫描 K8S 资源对象时出现 Race conditions。
5.5. Argo Workflow 原理分析
Argo Workflow 是最终容器编排的执行者，它负责解析传递给他的 DAG Schema，并按照 Schema 要求为 Workflow 中的每个 step 生成 Pod 来执行业务功能。Argo 会产生容器，但不会编译 Image，它会从 Registry 中拉取已经存在的基础镜像来运行业务逻辑。
Argo 生成的 Pod 运行在用户自定义的 K8S Namespace 中，并包含比较完整的运维周期。一个 Argo Pod 由三个 Container 组成：
- main，运行包含用户指令的镜像，其中 argoexec 被挂载作为主命令，并以子进程的形式调用用户配置的命令。
- init，用于获取制品和参数，并将它们提供给 main。
- wait，执行清理所需的任务，包含保存参数及制品。
