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 插件来进行测试，使用之前首先要启用这个插件：
从
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 表中已经记录了这个工作流的信息。