Kubernetes 原生 CI/CD 构建框架 Argo( 三 ) _框架

我们回到 Sidecar，在 Wait Container 中，有这样一段逻辑：

文章插图

文章插图

再来看看这个 Wait Container 的 Volume Mount 情况：

文章插图

现在就十分明确了，Wait Container 通过挂载 Docker.sock 以及 service account，获取到 Main Container 中的输出结果，并保存到 Workflow 中。当然，因为 Workflow 中保存了大量的信息，当一个 Workflow 的 Step 过多时，整个 Workflow 的结构会过于庞大。
Parameter
Parameter 提供了一种通用机制，可以将步骤的结果用作参数。Parameter 的工作原理与脚本结果类似，除了输出参数的值会被设置为生成文件的内容，而不是 stdout 的内容。如：

文章插图

Volume
这并不是 Argo 处理产物传递的一种标准方式，但是通过共享存储，我们显然也能达到共通产物的结果。当然，如果使用 Volume，我们则无需借助 Inputs 和 Outputs 。
在 Workflow 的 Spec 中，我们定义一个 Volume 模板：

文章插图

并在其他的 template 中 mount 该 volume：

文章插图

其他流程控制功能
循环
在编写 Workflow 时，能够循环迭代一组输入通常是非常有用的，如下例所示:

文章插图

在源码实现中，将会去判断 withItems，如果存在，则对其中的每个元素进行一次 step 的扩展。

文章插图

条件判断
通过 when 关键字指定：

文章插图

错误重尝

文章插图

递归
Template 可以递归地相互调用，这是一个非常实用的功能。例如在机器学习场景中：可以设定准确率必须满足一个值，否则就持续进行训练。在下面这个抛硬币例子中，我们可以持续抛硬币，直到出现正面才结束整个工作流。

文章插图

以下是两次执行的结果，第一次执行直接抛到正面，结束流程；第二次重复三次后才抛到正面，结束流程。

文章插图

退出处理
退出处理是一个指定在 workflow 结束时执行的 template，无论成功或失败。

文章插图

对比 Tekton
相较于 Tekton 而言，Argo 的流程控制功能更加丰富。拥有着循环、递归等功能，这对于一些机器学习的场景都是十分适用的。而 Argo 社区对自己的定位也是 MLOps、AIOps、Data/Batch Processing，这也正是 Kubeflow Pipeline 底层基于 Argo 的原因（尽管 KFP 也在做 Tekton 的 backend）。
但是在权限控制方面，Argo 做的就不如 Tekton，我个人认为，Tekton 的结构定义更为清晰。二者各有优劣，可以根据自己的需求进行选择。