ArgoWorkflow教程(二)---快速构建流水线:Workflow & Template 概念
上一篇我们部署了 ArgoWorkflow,并创建了一个简单的流水线做了个 Demo。本篇主要分析 ArgoWorkflow 中流水线相关的概念,了解概念后才能更好使用 ArgoWorkflow。
本文主要分析以下问题:
- 1)如何创建流水线? Workflow 中各参数含义
- 2)WorkflowTemplate 流水线模版如何使用,
- 3)Workflow、WorkflowTemplate、template 之间的引用关系
- 4)ArgoWorkflow 流水线最佳实践
1.基本概念
ArgoWorkflow 中包括以下几个概念:
- Workflow:流水线,真正运行的流水线实例,类似于 Tekton 中的 pipelinerun
- WorkflowTemplate:流水线模板,可以基于模板创建流水线,类似于 Tekton 中的 pipeline
- ClusterWorkflowTemplate:集群级别的流水线模板,和 WorkflowTemplate 的关系类似于 K8s 中的 Role 和 ClusterRole
- templates:Workflow 或者 WorkflowTemplate/ClusterWorkflowTemplate 的最小组成单位,流水线由多个 template 组成,可以理解为流水线中的某一个步骤。
WorkflowTemplate 和 ClusterWorkflowTemplate 暂时统称为 Template。
Workflow、Template(大写)、template(小写)之间的关系如下:
三者间关系比较复杂,官方也有提到这块因为一些历史遗留问题导致命名上比较混乱
个人感觉下面这种方式比较好理解:
- template(小写):为 Template(大写)的基本组成单位,可以理解为流水线中的步骤
- Template(大写):一条完整的流水线,一般由多个 template(小写) 组成
- Workflow:真正运行的流水线实例,一般由 Template 直接创建,类似于流水线运行记录,每一条记录就是一个 Workflow
理清基本概念之后,接下来就看下看具体对象的分析。
2.Workflow
Workflow
是Argo中最重要的资源,具有两个重要功能:
- 1)工作流定义
- 2)工作流状态存储
先看下 Workflow 是怎么样的,以下是一个简单的 Workflow 例子:
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: steps-
spec:
entrypoint: hello # We reference our first "template" here
templates:
- name: hello # The first "template" in this Workflow, it is referenced by "entrypoint"
steps: # The type of this "template" is "steps"
- - name: hello
template: whalesay # We reference our second "template" here
arguments:
parameters: [{name: message, value: "hello"}]
- name: whalesay # The second "template" in this Workflow, it is referenced by "hello"
inputs:
parameters:
- name: message
container: # The type of this "template" is "container"
image: docker/whalesay
command: [cowsay]
args: ["{{inputs.parameters.message}}"]
整个 Workflow 对象核心内容分为以下三部分:
templates
:模板列表,此处定义了流水线中的所有步骤以及步骤之间的先后顺序。entrypoint
: 流水线入口,类似于代码中的 main 方法,此处一般引用某一个template invocators
即可。parameters
:流水线中用到的参数,包括 arguments 块中的全局参数和 inputs 块中的局部参数两种
entrypoint
Workflow 中必须要指定 entrypoint,entrypoint 作为任务的执行起点,类似于程序中的 main 方法。
templates
ArgoWorkflow 当前支持 6 种 template,接下来挨个分析一下。
container
和 Kubernetes container spec 是一致的,这个类型的 template 就是启动一个 container,用户可以指定image、command、args 等信息来控制具体执行的动作。
- name: whalesay
container:
image: docker/whalesay
command: [cowsay]
args: ["hello world"]
script
script 实际上是 container 的封装,spec 和 container 一致,同时增加了 source 字段,用于定义一个脚本,脚本的运行结果会记录到{{tasks.<NAME>.outputs.result}}
or {{steps.<NAME>.outputs.result}}
。
script 可以理解为简化了使用 container 来执行脚本的配置
- name: gen-random-int
script:
image: python:alpine3.6
command: [python]
source: |
import random
i = random.randint(1, 100)
print(i)
resource
Resource 类型的 template 用于操作集群中的资源,action 参数表示具体的动作,支持 get, create, apply, delete, replace, patch。
- name: k8s-owner-reference
resource:
action: create
manifest: |
apiVersion: v1
kind: ConfigMap
metadata:
generateName: owned-eg-
data:
some: value
suspend
Suspend 类型的 template 比较简单,就是用于暂停流水线执行。
默认会一直阻塞直到用户通过
argo resume
命令手动恢复,或者通过duration
参数指定暂停时间,到时间后会自动恢复。
- name: delay
suspend:
duration: "20s"
steps
Steps 用于处理模版之间的关系,具体包含两方面:
- 1)哪些任务需要运行
- 2)这些任务按照什么先后顺序运行
看下面这个例子:
- name: hello-hello-hello
steps:
- - name: step1
template: prepare-data
- - name: step2a
template: run-data-first-half
- name: step2b
template: run-data-second-half
哪些任务需要运行?
该 steps 则定义了要运行 step1、step2a、step2b 3 个 template。
这些任务按照什么先后顺序运行?
steps 中元素定义的先后顺序就是各个任务的执行先后顺序,在这里就是 step1 先运行,然后 step2a、step2b 并行运行。
注意:仔细看 yaml 中 step2a 和 step2b 是同一个元素中的,steps 是一个二维数组, 定义如下:
type Template struct {
Steps []ParallelSteps `json:"steps,omitempty" protobuf:"bytes,11,opt,name=steps"`
}
type ParallelSteps struct {
Steps []WorkflowStep `json:"-" protobuf:"bytes,1,rep,name=steps"`
}
转换为 json 形式就像这样:
{
"steps": [
["step1"],
["step2a", "step2b"]
]
}
这样应该比较清晰了,先后顺序一目了然
dag
Dag template 的作用和 steps 是一样的。
这里的 DAG 就是 Directed Acyclic Graph 这个 DAG。
DAG 和 Steps 区别在于任务先后顺序的定义上:
- Steps 以定义先后顺序作为 template 执行先后顺序
- DAG 则可以定义任务之间的依赖,由 argo 根据依赖自行生成最终的运行的先后顺序
看下面这个例子:
- name: diamond
dag:
tasks:
- name: A
template: echo
- name: B
dependencies: [A]
template: echo
- name: C
dependencies: [A]
template: echo
- name: D
dependencies: [B, C]
template: echo
DAG 中新增了 dependencies 字段,可以指定当前步骤依赖的的依赖。
哪些任务需要运行?
该 steps 则定义了要运行 A、B、C、D 4 个任务。
这些任务按照什么先后顺序运行?
不如 Steps 那么直接,需要根据 dependencies 分析依赖关系。
A 没有依赖,因此最先执行,B、C 都只依赖于 A,因此会再 A 后同时执行,D 则依赖于 B、C,因此会等B、C都完成后才执行。
转换为 json 形式如下:
{
"steps": [
["A"],
["B", "C"],
["D"]
]
}
ps:相比之下 steps 方式更为直接,任务先后顺序一目了然。如果整个 Workflow 中所有任务先后顺序理清楚了就推荐使用 steps,如果很复杂,只知道每个任务之间的依赖关系那就直接用 DAG,让 ArgoWorkflow 计算。
template definitions & template invocators
大家可以发现,steps、dag 模板和另外 4 个不一样,他们都是可以指定多个 template 的。
前面分别介绍了 ArgoWorkflow 中的 6 种 template,实际上可以按照具体作用将这 6 个 template 分为 template definitions(模板定义)以及 template invocators(模板调用器)两种。
- template definitions(模板定义):该类型 template 用于定义具体步骤要执行的内容,例子中的 whalesay 模板就是该类型
- 包含
container
,script
,resource
,suspend
等类型
- 包含
- template invocators(模板调用器):该类型 template 用于组合其他 template definitions(模版定义) ,定义步骤间的执行顺序等,例子中的 hello 模板就是该类型。
- 一般 entrypoint 指向的就是该类型的模板
- 包含
dag
和steps
两种类型,例子中的 hello 模板就是 steps 类型。
吐槽一下:template 这里有点绕,如果能将 模板定义 、模板调用器 拆分为两个不同的对象就比较清晰。
了解完 template 分类之后再回头看之前的 Workflow 例子就比较清晰了:
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: steps-
spec:
entrypoint: hello # We reference our first "template" here
templates:
- name: hello # The first "template" in this Workflow, it is referenced by "entrypoint"
steps: # The type of this "template" is "steps"
- - name: hello
template: whalesay # We reference our second "template" here
arguments:
parameters: [{name: message, value: "hello"}]
- name: whalesay # The second "template" in this Workflow, it is referenced by "hello"
inputs:
parameters:
- name: message
container: # The type of this "template" is "container"
image: docker/whalesay
command: [cowsay]
args: ["{{inputs.parameters.message}}"]
- 1)首先 whalesay 模板是一个
container
类型的 template,因此是 template definitions(模板定义) - 2)其次 hello 是一个
steps
类型的 template,因此是 template invocators(模板调用器)- 在该调用器中 steps 字段中定义了一个名为 hello 的步骤,该步骤引用的就是 whalesay template
- 3)entrypoint 指定的是 hello 这个 template invocators(模板调用器)
接下来就是 Workflow 中另一重要对象 entrypoit。
entrypoint
entrypoint 作为任务的执行起点,类似于程序中的 main 方法,每个 Workflow 中都必须要指定 entrypoint。
注意:只有被 entrypoint 指定的任务才会运行,因此,entrypoint 一般只会指定 Steps 和 DAG 类型的 template,也就是template invocators(模板调用器)。然后由 Steps 中的 steps 或者 DAG中的 tasks 来指定多个任务。
因此,并不是 Workflow 中写了的 templates 都会执行。
看下面这个例子:
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: steps-
spec:
entrypoint: hello # We reference our first "template" here
templates:
- name: hello # The first "template" in this Workflow, it is referenced by "entrypoint"
steps: # The type of this "template" is "steps"
- - name: hello
template: whalesay # We reference our second "template" here
arguments:
parameters: [{name: message, value: "hello"}]
- name: whalesay # The second "template" in this Workflow, it is referenced by "hello"
inputs:
parameters:
- name: message
container: # The type of this "template" is "container"
image: docker/whalesay
command: [cowsay]
args: ["{{inputs.parameters.message}}"]
Entrypoint 指定 hello,然后 hello 是一个 steps 类型的 template,也就是template invocators。然后在 hello template 的 steps 中指定了 whalesay 这个 template,最终 whalesay template 为 container 类型,也就是 template definitions。这里就是最终要运行的任务。
当然,entrypoint 也可以指定 template definitions(模板定义)类型的 template,不过这样只能运行一个任务,就像这样:
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: steps-
spec:
entrypoint: whalesay
templates:
- name: whalesay
container:
image: docker/whalesay
command: [cowsay]
args: ["hello"]
至此,我们应该基本搞清楚了 Workflow 对象(参数部分除外)。接下来就看一下最后一部分,parameters。
Demo
列出几个复杂一点点的 Workflow,看一下是不是真的搞懂 Workflow 了。
下面是一个包含 4个任务的 Workflow:
- 1)首先打印 hello
- 2)然后执行一段 python 脚本,生成随机数
- 3)sleep 20s
- 4)创建一个 Configmap
提供了 steps 和 dag 两种写法,可以对比下
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: steps-
spec:
entrypoint: hello
templates:
- name: hello
steps:
- - name: hello
template: whalesay
arguments:
parameters: [{name: message, value: "hello"}]
- - name: runscript
template: gen-random-int
- - name: sleep
template: delay
- - name: create-cm
template: k8s-owner-reference
# - name: diamond
# dag:
# tasks:
# - name: hello
# template: whalesay
# arguments:
# parameters: [{name: message, value: "hello"}]
# - name: runscript
# dependencies: [hello]
# template: gen-random-int
# - name: sleep
# template: delay
# dependencies: [runscript]
# - name: create-cm
# template: k8s-owner-reference
# dependencies: [sleep]
- name: whalesay
inputs:
parameters:
- name: message
container:
image: docker/whalesay
command: [cowsay]
args: ["{{inputs.parameters.message}}"]
- name: gen-random-int
script:
image: python:alpine3.6
command: [python]
source: |
import random
i = random.randint(1, 100)
print(i)
- name: k8s-owner-reference
resource:
action: create
manifest: |
apiVersion: v1
kind: ConfigMap
metadata:
generateName: owned-eg-
data:
host: lixueduan.com
wx: 探索云原生
- name: delay
suspend:
duration: "20s"
parameters
Workflow 中的参数可以分为以下两种:
- 形参:在 template(template definitions) 中通过 inputs 字段定义需要哪些参数,可以指定默认值
- 实参:在 template(template invocators) 中通过 arguments 字段为参数赋值,覆盖 inputs 中的默认值
以上仅为个人理解
inputs 形式参数
template 中可以使用 spec.templates[*].inputs
字段来指定形式参数,在 template 中可以通过{{inputs.parameters.$name}}
语法来引用参数。
下面这个例子则是声明了 template 需要一个名为 message 的参数,这样调用方在使用该 template 时就知道需要传哪些参数过来。
templates:
- name: whalesay-template
inputs:
parameters:
- name: message
container:
image: docker/whalesay
command: [cowsay]
args: ["{{inputs.parameters.message}}"]
当然也可以指定默认值
templates:
- name: whalesay-template
inputs:
parameters:
- name: message
value: "default message"
container:
image: docker/whalesay
command: [cowsay]
args: ["{{inputs.parameters.message}}"]
注意:如果未指定默认值,则调用该 template 时必须指定该参数,有默认值则可以不指定。
arguments 实际参数
spec.arguments
用于定义要传递的实际参数,这部分参数在当前 Workflow 下的所有 Template 中都可以使用,可以使用 {{workflow.parameters.$name}}
语法来引用。
例如下面这个例子中指定了一个名为 message 的参数,并赋值为 hello world。
arguments:
parameters:
- name: message
value: hello world
参数复用
除了在 steps/dag 中指定 arguments,甚至可以直接在 Workflow 中指定,然后 steps/dag 中通过{{workflow.parameters.$name}}
语法进行引用。这样即可实现参数复用,Workflow 中定义一次,steps/dag 中可以多次引用。
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: example-
spec:
entrypoint: main
arguments:
parameters:
- name: workflow-param-1
templates:
- name: main
dag:
tasks:
- name: step-A
template: step-template-A
arguments:
parameters:
- name: template-param-1
value: "{{workflow.parameters.workflow-param-1}}"
- name: step-template-A
inputs:
parameters:
- name: template-param-1
script:
image: alpine
command: [/bin/sh]
source: |
echo "{{inputs.parameters.template-param-1}}"
Demo
通过下面这个 Demo 来理解参数传递:
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: steps-
spec:
entrypoint: hello # We reference our first "template" here
templates:
- name: hello # The first "template" in this Workflow, it is referenced by "entrypoint"
steps: # The type of this "template" is "steps"
- - name: hello
template: whalesay # We reference our second "template" here
arguments:
parameters: [{name: message, value: "hello"}]
- name: whalesay # The second "template" in this Workflow, it is referenced by "hello"
inputs:
parameters:
- name: message
container: # The type of this "template" is "container"
image: docker/whalesay
command: [cowsay]
args: ["{{inputs.parameters.message}}"]
上述例子中,template whalesay 定义了需要一个名为 message 的参数,同时在 steps template 中引用 whalesay 时通过 arguments 指定了参数 message 的值为 hello。因此最终会打印出 hello。
3.WorkflowTemplate
官方原文:
A WorkflowTemplate is a definition of a Workflow that lives in your cluster.
WorkflowTemplate 就是 Workflow 的定义,WorkflowTemplate 描述了这个流水线的详细信息,包括有哪些任务,任务之间的先后顺序等等。
根据前面对 Workflow 的描述可知,我们能直接创建 Workflow 对象来运行流水线,不过这种方式存在的一些问题:
- 1)如果 template 比较多的话,Workflow 对象就会特别大,修改起来比较麻烦
- 2)模板无法共享,不同 Workflow 都需要写一样的 template,或者同一个 template 会出现在不同的 Workflow yaml 中。
因此,关于 Workflow 和 WorkflowTemplate 的最佳实践:将 template 存到 WorkflowTemplate,Workflow 中只引用 Template 并提供参数即可。
而 ArgoWorkflow 中的工作流模板根据范围不同分为 WorkflowTemplate 和 ClusterWorkflowTemplate 两种。
- WorkflowTemplate:命名空间范围,只能在同一命名空间引用
- ClusterWorkflowTemplate:集群范围,任意命名空间都可以引用
WorkflowTemplate
下面是一个简单的 WorkflowTemplate:
apiVersion: argoproj.io/v1alpha1
kind: WorkflowTemplate
metadata:
name: workflow-template-submittable
namespace: default
spec:
entrypoint: whalesay-template
arguments:
parameters:
- name: message
value: tpl-argument-default
templates:
- name: whalesay-template
inputs:
parameters:
- name: message
value: tpl-input-default
container:
image: docker/whalesay
command: [cowsay]
args: ["{{inputs.parameters.message}}"]
可以看到 WorkflowTemplate 和 Workflow 参数是一模一样,这里就不在赘述了。
只需要将 kind 由 Workflow 替换为 WorkflowTemplate 即可实现转换。
workflowMetadata
workflowMetadata 是 Template 中独有的一个字段,主要用于存储元数据,后续由这个 Template 创建出的 Workflow 都会自动携带上这些信息。
通过这些信息可以追踪到 Workflow 是由哪个 Template 创建的。
使用方式就像下面这样,workflowMetadata 中指定了一个 label
apiVersion: argoproj.io/v1alpha1
kind: WorkflowTemplate
metadata:
name: workflow-template-submittable
spec:
workflowMetadata:
labels:
example-label: example-value
然后由该 Template 创建的 Workflow 对象都会携带这个 label:
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
annotations:
workflows.argoproj.io/pod-name-format: v2
creationTimestamp: "2023-10-27T06:26:13Z"
generateName: workflow-template-hello-world-
generation: 2
labels:
example-label: example-value
name: workflow-template-hello-world-5w7ss
namespace: default
ClusterWorkflowTemplate
类似于 WorkflowTemplate,可以理解为 k8s 中的 Role 和 ClusterRole 的关系,作用域不同罢了。
和 WorkflowTemplate 所有参数都一致,只是将 yaml 中的 kind 替换为 ClusterWorkflowTemplate 即可。
4.TemplateRef
创建好 WorkflowTemplate 之后就可以在 Workflow 中使用 TemplateRef 直接引用对应模板了,这样 Workflow 对象就会比较干净。
对于 WorkflowTemplate 的引用也有两种方式:
- 1)workflowTemplateRef:引用完整的 WorkflowTemplate,Workflow 中只需要指定全局参数即可
- 2)templateRef:只引用某一个 template,Workflow 中还可以指定其他的 template、entrypoint 等信息。
workflowTemplateRef
可以通过workflowTemplateRef
字段直接引用 WorkflowTemplate。
注意:这里需要 Workflow 和 WorkflowTemplate 在同一个命名空间。
就像这样:
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: workflow-template-hello-world-
spec:
arguments:
parameters:
- name: message
value: "from workflow"
workflowTemplateRef:
name: workflow-template-submittable
workflowTemplateRef
指定要引用的 Template 名字即可,这一句就相当于把对应 Template 中 spec 字段下的所有内容都搬过来了,包括 entrypoint、template 等。
Workflow 中一般只需要通过 argument 字段来实现参数覆盖,当然也可以不指定,若 Workflow 中不指定参数则会使用 Template 中提供的默认值
一个最精简的 Workflow 如下:
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: workflow-template-hello-world-
spec:
workflowTemplateRef:
name: workflow-template-submittable
只有 workflowTemplateRef
字段,未提供 argument 参数。
和前面的 Workflow 对比起来,内容就更少了,因为大部分都写在 WorkflowTemplate 里了,Workflow 中一般只需要指定参数就行。
clusterWorkflowTemplateRef
和 workflowTemplateRef 类似,只需要增加 clusterScope: true
配置即可。
默认为 false,即 WorkflowTemplate
就像这样:
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: workflow-template-hello-world-
spec:
entrypoint: whalesay
templates:
- name: whalesay
steps: # You should only reference external "templates" in a "steps" or "dag" "template".
- - name: call-whalesay-template
templateRef: # You can reference a "template" from another "WorkflowTemplate or ClusterWorkflowTemplate" using this field
name: cluster-workflow-template-whalesay-template # This is the name of the "WorkflowTemplate or ClusterWorkflowTemplate" CRD that contains the "template" you want
template: whalesay-template # This is the name of the "template" you want to reference
clusterScope: true # This field indicates this templateRef is pointing ClusterWorkflowTemplate
arguments: # You can pass in arguments as normal
parameters:
- name: message
value: "hello world"
核心部分:
workflowTemplateRef:
name: cluster-workflow-template-submittable
clusterScope: true
当指定为集群范围时,ArgoWorkflow 会去搜索 ClusterWorkflowTemplate 对象,否则会在当前命名空间搜索 WorkflowTemplate。
templateRef
除了使用 workflowTemplateRef / clusterWorkflowTemplateRef 引用整个 WorkflowTemplate 之外,还可以使用 templateRef 参数来实现引用 WorkflowTemplate 中的某一个 template。
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: workflow-template-hello-world-
spec:
entrypoint: whalesay
templates:
- name: whalesay
steps: # You should only reference external "templates" in a "steps" or "dag" "template".
- - name: call-whalesay-template
templateRef: # You can reference a "template" from another "WorkflowTemplate" using this field
name: workflow-template-1 # This is the name of the "WorkflowTemplate" CRD that contains the "template" you want
template: whalesay-template # This is the name of the "template" you want to reference
arguments: # You can pass in arguments as normal
parameters:
- name: message
value: "hello world"
核心为:
templateRef:
name: workflow-template-1
template: whalesay-template
参数分析:
- name 指的是 WorkflowTemplate 名称,即 workflow-template-1 这个 WorkflowTemplat
- template 指的就是 template 的名称 ,即 workflow-template-1 这个 WorkflowTemplat 中的名为 whalesay-template 的 template
注意:根据官方文档,最好不要在 steps
和 dag
这两个template invocators(模板调用器)之外使用 templateRef 。
原文如下:
You should never reference another template directly on a template object (outside of a steps or dag template). This behavior is deprecated, no longer supported, and will be removed in a future version.
Parameters
WorkflowTemplate 中使用参数和 Workflow 基本一致,没有太大区别。
- template definitions 中通过 inputs 字段定义需要的参数
- template invocators 中通过 arguments 字段为参数复制
Workflow 中引用 WorkflowTemplate 时可以再次定义 arguments 以覆盖 WorkflowTemplate 中的默认参数。
最佳实践
根据 workflowTemplateRef 和 templateRef 描述可以得出以下最佳实践:
- 1)workflowTemplateRef 使用:WorkflowTemplate 中定义完整流水线内容,包括 entrypoint、template,Workflow 中通过 workflowTemplateRef 引用并通过 argument 指定参数覆盖默认值。
- 2)templateRef 使用:WorkflowTemplate 中不定义完整流水线内容,只定义常用 template,Workflow 中需要使用该类型 template 时,通过 templateRef 引用,而不是在 Workflow 中再定义一次该 template。
第一种情况 WorkflowTemplate 可以称为流水线模板,第二种情况下 WorkflowTemplate 充当 template-utils 角色。
【ArgoWorkflow 系列】持续更新中,搜索公众号【探索云原生】订阅,阅读更多文章。
5.小结
本文主要分析了 ArgoWorkflow 中的 Workflow、WorkflowTemplate、template 对象及其之间的联系。
1)Workflow 对象:由 templates、entrypoint 组成。
- templates:按照作用分为 template definitions(模板定义)以及 template invocators(模板调用器)
- template definitions:用于定义具体步骤要执行的内容,包括 container、script、resource、suspend
- template invocators:用于组合其他模板,控制任务先后顺序,包括 steps、dag
- entrypoint:任务执行起点
2)WorkflowTemplate/ClusterWorkflowTemplate 对象:和 Workflow 对象一致,但只用于定义流水线,不可运行
- Workflow 中可以通过 WorkflowTemplateRef/clusterWorkflowTemplateRef 引用整个 WorkflowTemplate
- 或者通过 templateRef 引用某个 template
3)Parameters:分为形参和实参
- inputs:形参,申明该 template 需要使用哪些参数,可指定默认值
- arguments:实参,为对应 template 中的参数赋值,会覆盖 inputs 提供的默认值
4)参数优先级:
- Workflow arguments > WorkflowTemplate arguments > WorkflowTemplate inputs
最后则是Workflow、WorkflowTemplate、template 这三者之间的关系
5)一些最佳实践:
WorkflowTemplate:
- 1)可以用作流水线模版:WorkflowTemplate 中定义全部的 entrypoint 和 templates,Workflow 中通过 WorkflowTemplateRef 引入即可使用
- 2)用作 template-utils:WorkflowTemplate 中仅包含常用的 template,Workflow 中要使用时通过 templateRef 引入,避免重复定义 template
steps 和 dag 选择:
- steps 方式更为直接,任务先后顺序一目了然,但是需要理清所有任务的先后顺序
- dag 则不够直观,但是填写时只需要知道某个任务的依赖关系就可以添加新任务
建议:如果整个 Workflow 中所有任务先后顺序理清楚了就推荐使用 steps,如果很复杂,只知道每个任务之间的依赖关系那就直接用 DAG,让 ArgoWorkflow 计算。
ArgoWorkflow教程(二)---快速构建流水线:Workflow & Template 概念的更多相关文章
- Gradio入门到进阶全网最详细教程[二]:快速搭建AI算法可视化部署演示(侧重参数详解和案例实践)
Gradio入门到进阶全网最详细教程[二]:快速搭建AI算法可视化部署演示(侧重参数详解和案例实践) 相关文章:Gradio入门到进阶全网最详细教程[一]:快速搭建AI算法可视化部署演示(侧重项目搭建 ...
- CRL快速开发框架系列教程二(基于Lambda表达式查询)
本系列目录 CRL快速开发框架系列教程一(Code First数据表不需再关心) CRL快速开发框架系列教程二(基于Lambda表达式查询) CRL快速开发框架系列教程三(更新数据) CRL快速开发框 ...
- Docker搭建disconf环境,三部曲之二:本地快速构建disconf镜像
Docker下的disconf实战全文链接 <Docker搭建disconf环境,三部曲之一:极速搭建disconf>: <Docker搭建disconf环境,三部曲之二:本地快速构 ...
- docker&flask快速构建服务接口(二)
系列其他内容 docker快速创建轻量级的可移植的容器✓ docker&flask快速构建服务接口✓ docker&uwsgi高性能WSGI服务器生产部署必备 docker&g ...
- SpringCloud核心教程 | 第一篇: 使用Intellij中的Spring Initializr来快速构建Spring Cloud工程
spring cloud简介 spring cloud 为开发人员提供了快速构建分布式系统的一些工具,包括配置管理.服务发现.断路器.路由.微代理.事件总线.全局锁.决策竞选.分布式会话等等.它运行环 ...
- SpringCloud核心教程 | 第二篇: 使用Intellij中的maven来快速构建Spring Cloud工程
spring cloud简介 spring cloud 为开发人员提供了快速构建分布式系统的一些工具,包括配置管理.服务发现.断路器.路由.微代理.事件总线.全局锁.决策竞选.分布式会话等等.它运行环 ...
- Hexo快速构建个人小站-自定义域名和自定义主题(二)
背景交代: 在上一章<Hexo快速构建个人小站-Hexo初始化和将项目托管在Github(一)>中,我们已经成功的利用hexo初始化了博客项目,并托管在Github上,且通过Github的 ...
- 快速构建Windows 8风格应用31-构建磁贴
原文:快速构建Windows 8风格应用31-构建磁贴 引言 磁贴是吸引用户经常使用应用重要手段之一.我们可将应用程序内较好的内容使用磁贴进行展示. 另外应用程序磁贴是应用程序中的核心部分,而且很可能 ...
- 用前端姿势玩docker【四】基于docker快速构建webpack的开发与生产环境
目录 用前端姿势玩docker[一]Docker通俗理解常用功能汇总与操作埋坑 用前端姿势玩docker[二]dockerfile定制镜像初体验 用前端姿势玩docker[三]基于nvm的前端环境构建 ...
- Rancher 快速构建k8s容器管理平台解决方案(图片见原文链接)
转载自Rancher 快速构建k8s容器管理平台解决方案_IT干货的博客-CSDN博客_k8s容器管理平台 一.Rancher 概述 Rancher 是企业级多集群Kubernetes管理平台,一个为 ...
随机推荐
- 我又学会了使用Range实现网络文件下载的断点续传
目录 前言 1.Range请求头 1.1.概述 1.2.使用限制 1.3.范围请求 1.4.预防资源变更 2.断点续传下载实现 2.1.流程设计 2.2.代码实现 2.3.运行结果 3.RandomA ...
- “国产双系统”出炉,RK3568J非对称AMP:Linux+RTOS/裸机
"非对称AMP"双系统是什么 AMP(Asymmetric Multi-Processing),即非对称多处理架构."非对称AMP"双系统是指多个核心相对独立运 ...
- mapreduce的shuffle机制
1.1 概述: mapreduce中,map阶段处理的数据如何传递给reduce阶段,是mapreduce框架中最关键的一个流程,这个流程就叫shuffle:(从map的输出到reduce的输入) s ...
- [UG 二次开发 PYTHON] 添加螺纹规格
NX 1988 系列 在添加螺纹特征时,不能自定义螺纹规格, 从网上找到的资料上讲,改一个XML文件,在文件中添加自定义的螺纹规格,从而实现需要的效果. 自己写了一个小程序,方便手动添加螺纹规格. 效 ...
- kafka3.0创建topic出现zookeeper is not a recognized option
在linux云服务器上搭建了一套kafka3.0集群,然后安装以前的创建topic指令,例如这样-- ./kafka-topics.sh --bootstrap-server master:2181, ...
- 使用Selenium爬取动态网页
1.使用Selenium爬取动态网页 In [ ]: from selenium import webdriver driver = webdriver.Chrome() driver.get('ht ...
- 学习 React 需要具备的 JavaScript 知识
学习 React 需要具备的 JavaScript 知识 为什么要学习 React? React 可以与任何其他库或框架无缝集成,因为 React 是一个仅视图库(它是 Model View C on ...
- 70%的人都答错了的面试题,vue3的ref是如何实现响应式的?
前言 最近在我的vue源码交流群有位面试官分享了一道他的面试题:vue3的ref是如何实现响应式的?下面有不少小伙伴回答的是Proxy,其实这些小伙伴只回答对了一半. 当ref接收的是一个对象时确实是 ...
- idea2020修改help的vm options之后导致idea打不开的问题
如图所示,如果你修改了VM参数,导致启动没反应,证明你的参数配置有误. 这个时候你可能会想着直接修改idea安装目录bin中的配置文件,但是这个文件并不是你在idea中修改的配置文件,所以你修改这里的 ...
- Jmeter的安装(Windows)
1.选择和本机JDK兼容的jmeter版本下载 Jmeter历史版本下载地址:https://archive.apache.org/dist/jmeter/binaries/ 此处我的jmeter5. ...