作者：苏雅诗、才疏、木环
名字解释：
Argo Workflows：云原生工作流引擎，专为在 Kubernetes 集群上协调多个任务或步骤的执行而设计。
Artifacts：指在工作流执行过程中产生的、具有持久性的数据对象，通常代表了某个步骤或任务的输出结果。
OSS：阿里云对象存储服务，通常作为存储 Artifacts 的介质。
Argo Workflows 的出现，为 Kubernetes 用户提供了一个原生的、专为容器化工作负载设计的工作流编排工具，它结合了多种工具的优点，并为 Kubernetes 生态系统带来了新的灵活性和自动化能力。
Kubernetes Jobs 只提供基础的任务执行，但是无法定义步骤依赖关系和顺序、缺乏工作流模版、没有可视化界面，也不支持工作流级别的错误处理等，对于批处理、数据处理、科学计算、持续集成等业务场景，Kubernetes Job 无法胜任。
Argo Workflows
（
https://github.com/argoproj/argo-workflows
）
是开源的云原生工作流引擎，CNCF 的毕业项目。Argo Workflows 可以轻松自动化和管理 Kubernetes 上的复杂工作流程。适用于各种场景，包括定时任务、机器学习、ETL和数据分析、模型训练、数据流 pipline、CI/CD 等。
在使用 Argo Workflows 编排任务时，特别是在涉及
大数据量的场景如模型训练、数据处理、生物信息学分析
等，对 Artifacts（通常在阿里云环境中存储于对象存储服务 OSS）的高效管理至关重要。
然而，采用开源方案的用户可能会遭遇若干挑战，具体包括：
-
超大文件无法上传：
对于超过 5Gi 的文件，由于客户端上传限制导致上传失败。
-
缺乏文件清理机制：
随着工作流执行的推进，中间产生的临时文件或已完成任务的输出结果若未能得到及时清理，导致 OSS 存储空间的无谓消耗。
-
Argo Server 磁盘占用过高：
在使用 Argo Server 下载文件时，需要先落盘再传输，高磁盘占用不仅影响服务器性能，还可能导致服务中断或数据丢失。
ACK One Serverless Argo 工作流
（
https://help.aliyun.com/zh/ack/distributed-cloud-container-platform-for-kubernetes/user-guide/overview-12
）
作为一款完全遵循社区规范的全托管式 Argo Workflows 服务，致力于应对并解决大规模、高安全性的文件管理工作挑战。本文将详细介绍该服务在此方面所做出的一系列重要增强功能，包括
超大文件分片上传、Artifacts 自动垃圾回收（GC）以及 Artifacts 流式传输
等。这些特性旨在助力用户在阿里云环境下对 OSS 文件实现高效、安全的精细化管理。
在模型训练、数据处理、生物学信息分析、音视频处理等场景中，常常需要上传海量大文件。
但是，Argo 开源方案并不支持超大文件的上传，给用户带来了显著的操作不便与使用体验不佳的问题。
出于数据持久化、共享、缓解 Pod 临时存储压力及容灾备份等目的，在使用 Argo Workflows 编排任务时，需要通过 Artifacts 将中间产出、运行结果及过程日志等数据上传至对象存储服务中。
为了应对开源 Argo 方案的局限性，ACK One Serverless Argo 工作流优化了超大文件上传至 OSS（阿里云对象存储服务）逻辑，支持分片、断点续传，这对于提高大文件处理的效率和可靠性至关重要，尤其是在数据密集型任务和分布式计算环境中。这不仅优化了资源使用，还提高了处理大数据集的能力。每个分片支持独立的完整性校验，提高了数据完整性的保证，同时也增强了系统的容错性和数据的安全性。
该功能在 Serverless Argo 中默认开通，在配置好 Artifacts
（
https://www.alibabacloud.com/help/zh/ack/distributed-cloud-container-platform-for-kubernetes/user-guide/configure-artifacts
）
后，提交示例工作流，即可在 OSS 上获得一个大小为 20Gi 的文件 testfile.txt，说明超大文件完成了上传。
apiVersion: argoproj.io/v1alpha1kind: Workflowmetadata: generateName: artifact-spec: entrypoint: main templates: - name: main metadata: annotations: k8s.aliyun.com/eci-extra-ephemeral-storage: "20Gi" # 自定义设置要增加的临时存储空间大小 k8s.aliyun.com/eci-use-specs : "ecs.g7.xlarge" container: image: alpine:latest command: - sh - -c args: - | mkdir -p /out dd if=/dev/random of=/out/testfile.txt bs=20M count=1024 # 生成20Gi的文件 echo "created files!" outputs: # 触发文件上传到OSS artifacts: - name: out path: /out/testfile.txt
开源 Argo 方案，无法进行 OSS 上文件的自动回收，徒增了用户的使用和运维成本。
Argo Workflows 的 Artifact 垃圾回收（Garbage Collection, GC）机制主要用于在工作流结束后删除不再需要的工作流产生的文件（如中间结果、日志等），可以帮助节省存储空间及存储成本，防止存储资源的无限制消耗。
ACK One Serverless Argo 工作流优化了 OSS 上的文件清理方法，用户只需通过简单的回收逻辑配置，就可以实现：
-
在工作流完成、或管理员手动在集群中清理工作流相关资源一定时间后，自动回收上传至 OSS 的文件；
-
只为成功的工作流任务配置回收，避免清理失败日志、方便追踪；或只为失败的工作流任务配置回收，回收无效的中间产出。
-
利用 OSS 提供的生命周期管理策略，可以设置规则根据时间、前缀等参数，自动删除旧的 Artifacts；或将早起的 Artifacts 归档至冷存储，在保证数据完整的前提下有效降低成本。
使用示例：
配置 artifactGC 策略即可使用该功能。如下示例所示，该工作流整体的 artifactGC 策略为删除后回收，其中 on-completion 文件的回收策略为完成时回收。提交该工作流后，可以在 OSS 上观察到，在 workflow 完成时 on-completion.txt 被回收，删除工作流后 on-deletion.txt 文件被回收。
apiVersion: argoproj.io/v1alpha1kind: Workflowmetadata: generateName: artifact-gc-spec: entrypoint: main artifactGC: strategy: OnWorkflowDeletion # 全局回收策略,在workflow被删除时回收artifact,可被覆盖 templates: - name: main container: image: argoproj/argosay:v2 command: - sh - -c args: - | echo "hello world" > /tmp/on-completion.txt echo "hello world" > /tmp/on-deletion.txt outputs: # 上传文件到OSS artifacts: - name: on-completion path: /tmp/on-completion.txt artifactGC: strategy: OnWorkflowCompletion # 覆盖全局回收策略，在workflow完成时回收artifact - name: on-deletion path
