argo workflow笔记(一)

基于k8s的流程编排引擎argo概述

Posted by odin on April 14, 2020

1.关于argo

Argo 项目是一组 Kubernetes 原生工具集合,用于运行和管理 Kubernetes 上的作业和应用程序。Argo 提供了一种在 Kubernetes 上创建工作和应用程序的三种计算模式 – 服务模式、工作流模式和基于事件的模式 – 的简单组合方式。Argo Workflow 的项目名称就是 Argo(https://github.com/argoproj/argo), 是 Argo 组织最初的项目。Argo Workflow 专注于 Kubernetes Native Workflow 设计,拥有声明式工作流机制,能够通过 CRD 的模式完全兼容 Kubernetes 集群,每个任务通过 Pod 的形式运行。
Workflow 基于k8s的开源流程控制引擎,为Kubernetes提供容器本机工作流。Argo工作流程中的每个步骤都定义为一个容器。通过 Kubernetes CRD(Custom Resource Definition)来进行实现的。提供 DAG 等依赖拓扑,并且能够通过 Workflow Template CRD 实现多个 Workflow 之间的组合与拼接。 与k8s的DSL方式类似,Argo 中的工作流自动化是通过使用 ADSL(Argo 领域特定语言)设计的 YAML 模板进行驱动的。ADSL 中提供的每条指令都被看作一段代码,并与代码仓库中的源码一起托管。Argo 支持6中不同的 YAML 结构:

  • Container Templates(容器模板):creating a single container and parameters as required,创建单个容器模板
  • Workflow Templates(工作流模板):defining a job, in other words short-running-app which runs to completion,创建工作流模板,每个工作流节点都被定义为一个单独的容器
  • Policy Templates(策略模板): rules for triggering/invoking a job or a notification,触发或者调用作业/通知的规则
  • Deployment Template(部署模板): create long running applications,创建一个长期运行的应用程序模板
  • Fixture Templates(混合模板): glues third-party resources outside Argo,使用argo外部第三方的资源
  • Project Templates(项目模板): workflow definitions that can be accessed in Argo catalog,可以在 Argo 目录中访问的工作流定义

2.argo的特点

1、argo是基于容器的,不需要传统的虚拟机机系统和环境 2、argo是云无关的,可以在任意的k8s集群中运行 3、argo能定制计算资源,让云端的资源在我们的掌握之中

3.argo架构模式设计

从v2.5开始,Argo支持“local”和“hosted”两种部署模式,v2.5之前只能是Hosted这种模式。 argo workflow工作流 argo controller流程

4.argo template

The Structure of Workflow Specs We now know enough about the basic components of a workflow spec to review its basic structure:(一个缩进的是必须包含,两个缩进的是非必须)

  • Kubernetes header including metadata
  • Spec body
    • Entrypoint invocation with optionally arguments
    • List of template definitions
  • For each template definition
    • Name of the template
    • Optionally a list of inputs
    • Optionally a list of outputs
    • Container invocation (leaf template) or a list of steps
    • For each step, a template invocation

以上一级均为必选向,二级为非必选项
To summarize, workflow specs are composed of a set of Argo templates where each template consists of an optional input section, an optional output section and either a container invocation or a list of steps where each step invokes another template. Note that the container section of the workflow spec will accept the same options as the container section of a pod spec, including but not limited to environment variables, secrets, and volume mounts. Similarly, for volume claims and volumes.

argo模板中template代表可运行的节点,分为6类:

4.1)Container

该类型定义了我们一个容器运行的基础,会对应于我们在 kubernetes 中产生一个世纪的 pod,该实体的类型对应于标准 kubernetes 的 Container resource,kubernetes Container 具有的参数我们都可以在其中使用;

1
2
3
4
5
6
  // 简单实例
name: sleep-n-sec
container:
    image: alpine:latest
    command: [sh, -c]
    args: ["echo sleeping for  seconds; sleep ; echo done"]

4.2)Script

该类型支持我们直接在 template 中定义并允许一段脚本,该 template 类型也是基于 Container 的,不过在 Container 的类型上面添加了一个 Source 字段来表示我们的脚本,我们在 Container 的运行配置中应该注释初始化我们脚本运行的环境;

1
2
3
4
5
6
7
8
9
// 简单实例
name: gen-number-list
script:
    image: python:alpine3.6
    command: [python]
    source: |
        import json
        import sys
        json.dump([i for i in range(20, 31)], sys.stdout)

4.3)Resource

该类型支持我们在 tempalte 中对 kubernetes 中资源操作的能力,我们可以 create, apply, delete, replace(对应该模板的action字段) k8s 中的资源;并且支持设定相关的成功与失败条件用于判断该 tempalte 的成功与失败;

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
// 简单实例
name: pi-tmpl
resource:                   #indicates that this is a resource template
    action: create            #can be any kubectl action (e.g. create, delete, apply, patch)
    # The successCondition and failureCondition are optional expressions.
    # If failureCondition is true, the step is considered failed.
    # If successCondition is true, the step is considered successful.
    # They use kubernetes label selection syntax and can be applied against any field
    # of the resource (not just labels). Multiple AND conditions can be represented by comma
    # delimited expressions.
    # For more details: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/
    successCondition: status.succeeded > 0
    failureCondition: status.failed > 3
    manifest: |               #put your kubernetes spec here
        apiVersion: batch/v1
        kind: Job
        metadata:
            generateName: pi-job-
        spec:
            template:
            metadata:
                name: pi
            spec:
                containers:
                - name: pi
                image: perl
                command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
                restartPolicy: Never
            backoffLimit: 4

4.4)Suspend

该类型可以对我们的 Workflow 进行挂起操作,当我们运行到该类型的 template 时,我们的 Workflow 将会挂起,等待我们运行 argo resume {name} Workflow 才会继续运行下去;同时对于挂起操作,我们也可以直接运行 argo suspend {name} 来挂起某个 Workflow;

1
2
3
// 简单实例
name: suspend-test
suspend: {}

4.5)Steps

这类型可以指定我们的控制流,一般在其中会引用 tempalte 来进行基础单元进行工作。该类型可以让我们把 template 组合成一条 pipeline 来进行运行,并且在流程中还支持 tempalte 间参数的传递,条件的判断,递归调用…; 它使用一个二维数组来进行定义,在第一级数组串行运行,在第二级数组并行运行;

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// 简单实例
name: coinflip
steps:
# flip a coin
- - name: flip-coin
    template: flip-coin
# evaluate the result in parallel
- - name: heads
    template: heads                 # 条件判断, 目前只支持 `==` 与 `!=`
    when: " == heads"
  - name: tails                  
    template: coinflip              # 递归调用
    when: " == tails"  # 条件判断
  - name: heads1
    template: heads

4.6)DAG

有向无环图,该类型可以定义我们的 DAG 类型 workflow, 在其中我们根据 依赖 来进行 DAG 的定制,没有 依赖 的 Task 将会作为 DAG 的 root 首先运行; 但是目前 DAG 中 Task 还不支持相关条件判断表达式来进行条件判断;

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
// 简单实例
name: multiroot
dag:
    tasks:
    - name: A
      template: echo
      arguments:
        parameters: [{name: message, value: A}]
    - name: B
      dependencies:
      template: echo
      arguments:
        parameters: [{name: message, value: B}]
    - name: C
      dependencies: [A]
      template: echo
      arguments:
        parameters: [{name: message, value: C}]
    - name: D
      dependencies: [A, B]
      template: echo
      arguments:
        parameters: [{name: message, value: D}]

在argo的每个step都会创建一个相应的pod执行

5.使用模板

argo cli方式

1
2
3
4
5
6
7
8
9
10
# 创建模板
argo template create https://raw.githubusercontent.com/argoproj/argo/master/examples/workflow-template/templates.yaml
 
 
# 提交模板
argo submit https://raw.githubusercontent.com/argoproj/argo/master/examples/workflow-template/hello-world.yam
 
 
# 指定namespace应用模板
argo submit --namespace argo https://raw.githubusercontent.com/argoproj/argo/master/examples/workflow-template/hello-world.yam

同时支持使用kubectl方式

1
2
3
4
5
6
# 创建模板
kubectl create -f https://raw.githubusercontent.com/argoproj/argo/master/examples/hello-world.yaml
 
 
# 指定namespace应用模板
kubectl apply -n argo -f https://raw.githubusercontent.com/argoproj/argo/master/examples/hello-world.yaml

argocli比kubecli提供更多的参数支持,例如模板传参

6.常用指令

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# argo cli
argo submit hello-world.yaml    # submit a workflow spec to Kubernetes
argo list                       # list current workflows
argo get hello-world-xxx        # get info about a specific workflow
argo logs -w hello-world-xxx    # get logs from all steps in a workflow
argo logs hello-world-xxx-yyy   # get logs from a specific step in a workflow
argo delete hello-world-xxx     # delete workflow
 
 
# kubectl
kubectl create -f hello-world.yaml
kubectl get wf
kubectl get wf hello-world-xxx
kubectl get po --selector=workflows.argoproj.io/workflow=hello-world-xxx --show-all  # similar to argo
kubectl logs hello-world-xxx-yyy -c main
kubectl delete wf hello-world-xxx

7.关于argo ui

分析只用过程中没怎么用到,使用argo ui编辑流程配置也不是很方便,个人感觉没什么太大用处。

8.argo watch

argo查看workflow:argo –watch name 也可以在submit时同步使用watch查看执行过程:

1
argo submit --watch https://raw.githubusercontent.com/argoproj/argo/master/examples/hello-world.yaml