# Argo Workflow 中的卸载和归档

## 卸载

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` 插件来进行测试，使用之前首先要启用这个插件：

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

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

```yaml
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: { }
```

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

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

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

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

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

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

```yaml
...
  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，其中包含对持久化卸载的选项，例如我这样设置的：

```yaml
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
```

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

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

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

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

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

## 归档

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

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

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

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

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

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

```yaml
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` 表中已经记录了这个工作流的信息。