Argo Workflow 中的卸载和归档

Mon, 16 Dec 2024 23:38:57 +0800

卸载

Argo workflow 使用 CR 方式来保存工作流的运行状态，众所周知 ETCD 有一个请求大小的限制：1MB，也就是说，如果我们的 Workflow 对象 YAML 尺寸大于 1MB，超出了 ETCD 限制，就无法正常保存了。这种场景最常见于对大量目标进行循环的情况下，作为一个成熟的工作流系统，Argo workflow 自然是考虑到这方面的限制，提供了称为卸载（Offload）的方式，用于处置超大尺寸的工作流。

简单来说，在遇到超大工作流时，Argo Workflow 会对其 status.nodes 字段进行压缩，然后保存到 ETCD 中，当需要查询时，会先从 ETCD 中查询出压缩后的数据，再进行解压，从而避免了 ETCD 的限制。如果压缩仍然无法满足这一要求，Argo workflow 会将它保存到数据库中。

那么什么才是“超大”呢？Argo workflow 中，默认 1024*1024 为超大，但是我们可以通过修改 Workflow 控制器中的 MAX_WORKFLOW_SIZE 环境变量来改变这个值。为了测试方便，我们将环境变量修改为 10240，也就是 10KB。

为了测试方便，我们选用 Hello 插件来进行测试，使用之前首先要启用这个插件：

从 https://github.com/argoproj-labs/argo-workflows-hello-executor-plugin 获取代码
kubectl apply -f hello-executor-plugin-configmap.yaml 即可启用该插件。

接下来编写一个最小的 Workflow：

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: little-
spec:
  entrypoint: main
  templates:
  - name: main
    steps:
    - - name: item
        template: atom
        withSequence:
          count: "5"
  - name: atom
    plugin:
      hello: { }

提交之后，看一下这个工作流的尺寸：

$ kubectl get wf little-xbg5g -o yaml | wc -c
    4549

只有 4K 多一点，不会触发压缩，如果查看这个 YAML，会看到里面的 Nodes 情况。那么我们将循环次数提高到 50 会发生什么？

...
  generateName: bigger-
spec:
...
    - - name: item
        template: atom
        withSequence:
          count: "50"
...

提交运行后，我们会发现，这个 WF 对象的 status.nodes 节点不见了，取而代之的是 status.compressedNodes，其中包含了一串编码内容，如果用 base64 -d | gunzip 处理后，就会看到 status.nodes 的内容了。

如果工作流再大一些呢？例如我们把循环次数放大到 500：

...
  generateName: huge-
spec:
...
    - - name: item
        template: atom
        withSequence:
          count: "50"
...

Argo workflow 提交直接会出错：workflow is longer than maximum allowed size. compressed size 18191 > maxSize 10240Tried to offload but encountered error: offload node status is not supported，也就是说，经过压缩之后，还是超出了最大限制，尝试卸载，结果失败了。那么如何启用卸载呢？

Wrokflow Controller 有一个可选的 Configmap，其中包含对持久化卸载的选项，例如我这样设置的：

apiVersion: v1
data:
  persistence: |
    connectionPool:
      maxIdleConns: 100
      maxOpenConns: 0
      connMaxLifetime: 0s
    nodeStatusOffLoad: true
    mysql:
      host: argo-mysql.default
      port: 3306
      database: argo
      tableName: argo_workflows
      userNameSecret:
        name: argo-mysql-cred
        key: user
      passwordSecret:
        name: argo-mysql-cred
        key: password
kind: ConfigMap
metadata:
  name: workflow-controller-configmap
  namespace: argo

提交之前首先要准备数据库：

在 argo 命名空间中创建一个 Secret 备用，其中包含两个字段，分别是 MySQL 的用户名和密码。
创建一个 MySQL Database，命名为 argo，并且让前面 Secret 中声明的凭据可以访问。
在配置中引用前面创建的 Secret。

提交 Configmap 之后，重启 Workflow Controller。再次提交上述的工作流，可以看到工作流已经可以运行了。

成功后，使用 argo watch 命令是无法获取详情的，但是可以在 Argo Server 的 Web 界面上查看。

如果进入数据库，可以看到 argo_workflows 的 nodes 字段已经保存了完整的 Node 信息。

归档

虽然我们可以使用垃圾搜集策略来适时删除 Pod，但是 WF 对象始终存在，除了 kubectl get wf > backup.yaml，Argo workflow 有没有提供更好的归档能力呢？

启用数据库之后，就可以进行归档了，用法很简单，仍然从 Configmap 配置入手：

archiveTTL: 180d
archiveLabelSelector:
  matchLabels:
    workflows.argoproj.io/archive-strategy: "always"

archiveTTL 表示归档寿命，默认为 0，也就是用不删除，archiveLabelSelector 则是标签选择器，用于指定哪些工作流需要被归档。例如下面的 metadata：

metadata:
  generateName: backup-
  labels:
    workflows.argoproj.io/archive-strategy: "always"

提交工作流，运行完成后，使用 kubectl get wf 可以看到他的标签发生了变化：

labels:
    workflows.argoproj.io/archive-strategy: always
    workflows.argoproj.io/completed: "true"
    workflows.argoproj.io/phase: Succeeded
    workflows.argoproj.io/workflow-archiving-status: Archived

此时查看数据库内容，可以看到 argo_archived_workflows 表中已经记录了这个工作流的信息。

Argo Workflow | 伪架构师

Argo Workflow 中的卸载和归档

卸载

归档