关于Argo Workflow的流程数据传递方式,官方文档上提供的是三种方式:ParametersArtifactsVolume。其中,通过共享Volume传递数据方式官方只是提了个例子(https://argoproj.github.io/argo-workflows/examples/#volumes),来自于Kubernetes基本功能,并不属于Argo Workflow的自有特性。那么Argo WorkflowParametersArtifacts功能特性底层又是怎么实现的呢,我们这里着重探究前两种流程数据传递方式的本质。

一、Parameters

Parameters的参数传递分为两种,一种是不带Outputs输出的Parameters,另一种是带有Outputs输出的Parameters

1、不带Outputs输出的Parameters

这是 Argo Workflow中最简单的方式,甚至都不用做任何的脚本执行解析。因为变量都直接通过Yaml的形式配置到了Workflow中,Argo Workflow Controller中可以直接通过模板变量解析的方式即可将参数嵌入到命令行参数中。我们以官方示例steps.yaml作为示例演示一下。

我们查看一下创建的Pod情况:

hello1节点的执行:

hello2a节点的执行:

hello2b节点的执行:

2、带有Outputs输出的Parameters

这种情况会稍微复杂一些,因为会涉及到命令的执行以及执行结果的保存和传递。我们在之前的源码解析中有介绍到,在Wait Container中等待Main Container结束后,会根据Template的配置决定是否将Template的执行结果Json化之后,通过Patch方式写入到该Template运行PodMetaData.Annotation中,随后其他依赖该TemplateNode会读取该MetaData.Annotation,并解析该数据后存放到globalParams中,并使用globalParams做自身的模板变量替换,随后创建该Template Pod

Parameters存储到MetaData.Annotations

Argo Workflow ControllerTemplate使用MetaData.Annotations:

我们以官方实例output-parameter.yaml作为示例演示一下。

执行后我们看看Pod情况:

generate-parameter执行结果的保存:

consumer-parameter对于其他节点执行结果参数的输入:

二、Artifacts

Artifacts会稍微复杂一些。Argo默认使用minio来对Artifacts做存储和读取,并且Main Container对于Atifacts内容的操作原理都是基于共享Volume。也就是说往往必须要挂载Volume来使用Artifacts,不过Volume的挂载是由Argo Workflow Controller自动帮我们实现的,我们并不能直接感知到。我们以官方示例artifact-passing.yaml作为示例演示一下。

generate-artifact的节点Annotiations中只有Artifacts的输出路径及类型,真实的内容是保存到minio中的:

consume-artifact节点中Init/Wait/Main Containers挂载了相同的Volume,因此可以共享Artifacts数据。其中Init Container负责将Artifacts的内容拉取到本地的/argo/inputs/artifacts路径下,随后Main Container会读取/tmp/message路径下的内容,这两个路径均是来自于相同的Volume (input-artifacts)

                    


Content Menu

  • No labels