Kubeflow--Pipeline及Argo实现原理速析

转载已于 2022-05-10 14:26:15 修改 · 1.8k 阅读

4 ·

CC 4.0 BY-SA版权

原文链接：https://www.infoq.cn/article/5hhaoqxwhiwoq9itef5b

文章标签：

#容器 #运维

于 2022-05-10 11:27:49 首次发布

Kubeflow 专栏收录该内容

6 篇文章

订阅专栏

本文解析了Argo如何在Kubernetes上实现容器间的信息传递，重点介绍了KubeFlow Pipeline如何在Argo基础上增强流程管理和用户体验。讨论了Argo的局限性和KubeFlow的改进策略，包括扩展性、生产级可靠性和安全措施。

原文地址：

KubeFlow-Pipeline及Argo实现原理速析_容器_华为云开发者社区_InfoQ精选文章

摘要

Argo是一个开源原生容器工作流引擎用于在Kubernetes上开发和运行应用程序。Argo Workflow流程引擎，可以编排容器流程来执行业务逻辑，在20年4月进入CNCF孵化器组。

KubeFlow的Pileline子项目，由Google开源，其全面依赖Argo作为底层实现，并增强持久层来补充流程管理能力，同时通过Python-SDK来简化流程的编写。

Argo 流程引擎

Argo的步骤间可以传递信息，即下一步（容器）可以获取上一步（容器）的结果。结果传递有 2 种：

文件：上一步容器新生成的文件，会直接出现在下一步容器里面
信息：上一步的执行结果信息（如某文件内容），下一步也可以拿到

下面我们就来解读一下，Argo 怎么实现“信息”在容器间的传递的，以及它和其他的流程引擎实现传递的区别。

文件怎么从上一个容器跑到下一个容器里

Argo流程，可以指定2个步骤之间，传递结果文件（Artifact）。即假设流程为：A->B，那么 A 容器跑完，B 容器可以取得上一个容器的输出文件。

如下：A 容器生成一个 /tmp/hello_world.txt 文件，Argo 将这个文件，放到了 B 容器里面，并重命名为 /tmp/message 文件。

注意：流程上的每个步骤，都对应执行一个容器。在 A 跑完后容器就退出了，然后才跑的 B（这时候已经没有 A 容器在运行了）。

所以 Argo 怎么把一个文件从 A 容器“拷贝”到 B 容器里面的？

容器间通过共享存储?（NO）

一般容器间共享文件，首先想到的都是：咱使用共享存储呀，大家都挂载同一个 PVC 不就行了。

确实共享存储可以实现容器共享文件，但是这里 Argo 需要：

（1）任意指定文件传递。（2）传递后文件可以改名字。

这2个条件是共享Volume做不到的，毕竟容器挂载目录得提前设定好，然后文件名大家看到的也是一样。所以显然文件传递，不是通过共享PVC挂载实现的。

（PS：不过 Argo 也在考虑这种实现方式，毕竟共享目录不需要任何额外 IO，透传效率更高。见：Volume-based artifact passing system · Issue #1349 · argoproj/argo-workflows · GitHub）

通过管理面中转？（YES）

没有共享目录，那中转文件，只能是通过先取出来，再塞回去的方式喽。实际上 Argo 也确实这么做的，只是实现上还有些约束。

“临时中转仓库”需要引入第三方软件（Minio）
文件不能太大
需要在用户容器侧，增加“代理”帮忙上传&下载文件

中转文件具体实现（docker cp）

现在我们打开Argo看看具体怎么实现的。因为你要取一个容器里面的文件，或者把一个文件放入容器，也不容器实现。

小滑头Argo居然给用户容器设置了一个SideCar容器，通过这个SideCar去读取用户的文件，然后上传到临时仓库
一个 Pod 里面的两个 Container，文件系统也是独立的，并不能直接取到另一个 Container 的文件。所以Sidecar容器为了取另一个容器里的文件，又把主机上面的docker.sock挂载进了。这样就相当于拿到Root权限，可以任意cp主机上任意容器里面的文件。

事实上，Sidecar里面取文件的实现是：

docker cp -a 023ce:/tmp/hello_world.txt - | gzip > /argo/outputs/artifacts/hello-art.tgz

感觉稍微有点暴力。

中转实现的其他方式

实际上，通过 sidecar 容器提权到 root 权限，然后从用户的容器里面 copy 任意文件（即 docker cp 命令），只是 Argo 默认的实现。毕竟它自己也发现这样做安全上有点说不过去。

所以呢，它也留了其他方式去 copy 用户容器里面的文件。比如：kubectl 也是可以 cp 容器里面的文件的嘛。其他方式可参见：argo-workflows/workflow-executors.md at master · argoproj/argo-workflows · GitHub

下一步容器怎么拿到上一步容器的结果

Argo 流程，2 个步骤之间，除了传递文件，还可以传递结果信息（Information）。如：A->B，那么 A 容器跑完，B 容器可以取得上一个容器的一些 Information（不是整个文件）。

一般流程引擎透传信息，都是中转：

不过显然 Argo 自己没有存储 Information 的临时仓库，所以它得找个地方记录这些临时待中转的 information（虽然 Argo 找了 Minio 这个对象存储用来暂存中转文件，但是显然这货只能存文件，没有存 Metadata 元数据功能）。这里Argo又找了Pod里面的Annotation字段，当做临时中转仓库。先把信息记这里，下一步容器想要，就来这里取。

相信这里应该是有更好的实现方式的，这种把信息记录到 Annotation 的做法，约束比较大的（特别是 ETCD 的单个对象不能超过 1M 大小）。

可以考虑使用单独的 Configmap 来中转也可以。

Kubeflow-Pipeline项目

KubeFlow-Pipeline 项目（简称 KFP），是 Kubeflow 社区开源的一个工作流项目，用于管理、部署端到端的机器学习工作流。KFP 提供了一个流程管理方案，方便将机器学习中的应用代码按照流水线的方式编排部署，形成可重复的工作流。

为什么要在Argo之上重新开发一套？

部署一套 Argo 很简单，启动一个 K8s-Controller 就行。可是部署一套 Kubeflow-Pipeline 系统就复杂多了，总共下来有 8 个组件。那是 Argo 什么地方不足，需要新开发一套 KFP，并搞这么复杂呢？主要的原因还在于 Argo 是基于K8s云原生这套理念，即ETCD充当“数据库”来运行的，导致约束比较大。