Argo Workflows DAG 构建器

解决什么问题

在 Kubernetes 上跑机器学习训练或数据处理作业时，零散地 kubectl apply 一堆 Pod 很快就会失控：任务间的依赖关系没人维护，某一步失败后不清楚该重试还是整条链路回滚，中间产物散落在各节点的本地磁盘上无法跨节点复用，模板复用基本靠复制粘贴。Argo Workflows 提供了 DAG 的声明式定义能力，但手工编写 YAML 依然繁琐，重试策略、节点调度和工件传递这类细节尤其容易出错。

技能如何工作

这个技能围绕 Argo Workflows 的 CRD 体系展开，核心能力包括：

• DAG 声明式构建：用 WorkflowTemplate / ClusterWorkflowTemplate 定义任务依赖，替代手工编排
• 可配置重试策略：为每个 Step 或 Template 设置重试规则，控制重试次数、退避间隔与失败条件
• 工件传递：通过 S3 / MinIO 在节点间传递中间产物，摆脱对本地卷的依赖
• 模板组合：WorkflowTemplates 与 ClusterWorkflowTemplates 支持跨工作流复用
• 调度控制：支持 nodeSelector、affinity、toleration，把计算密集型作业调度到合适的节点
• 多语言客户端：Python（Hera）、Java、Golang、TypeScript（Juno）均有对应 SDK，可用代码生成工作流

典型流程：先用 CRD 或 SDK 描述 DAG 的节点、依赖和重试规则，提交给集群中的 Argo Workflows controller，运行时由控制器调度各 Step、处理失败重试，中间产物统一经 S3/MinIO 中转。

适用边界与注意点

• 需要集群中已部署 Argo Workflows controller，且具备足够的 RBAC 权限
• S3/MinIO 工件传递要求预先配置好 storage 凭证，否则 Step 之间无法传递产物
• DAG 规模过大时控制器调和压力会上升，超大依赖图需评估集群容量
• 重试策略解决不了根本性失败（如镜像拉不下来、资源配置超限），仍需监控告警兜底