Argo 工作流生态近期演进如何影响自动化平台

Argo 工作流生态的近期变化，真正影响自动化平台的地方，不是多了几个 YAML 字段，而是平台需要重新划分控制面、执行面、制品面和身份面。Argo Workflows v4.1 的官方变更集中在工作流级执行器插件、OpenTelemetry 链路、制品上传、资源声明、数据库身份认证等能力；Argo CD、Dex/SSO 与插件目录又把它放进了更大的交付平台中。

官方地址：https://argoproj.github.io/

因此，升级或接入时不要只问“工作流能不能跑”。更实用的问法是：谁能提交和重试，任务使用什么资源，制品经过哪个边界，失败由谁接收，观测信号能不能回到平台的发布记录。下面按自动化工作流的落地顺序拆开说明。

先看清 v4.1 改变了哪些平台边界

Argo Workflows 官方 v4.1 资料列出的方向包括：工作流级 Executor Plugin 配置、S3 上传线程与分片大小配置、工作流 OpenTelemetry tracing、可选的 initless pod 布局、Artifact streaming、DRA 资源声明、数据库 IAM 认证，以及从 UI 提交输入制品等。v4.1.5 的变更记录还继续处理了上下文绑定、暂停工作流终止、控制器队列和依赖安全更新。

这些变化有一个共同点：平台不再只托管一个“提交入口”，而是要为不同工作流提供可控的执行能力。工作流级插件有利于按任务选择能力，但也意味着平台必须明确允许哪些插件、插件使用什么凭据、插件产生哪些外部副作用。

把 Argo CD、Argo Workflows 和登录入口分开授权

Argo CD 负责持续比较 Git 中的期望状态与集群中的实际状态，Argo Workflows 负责 Kubernetes 上的步骤型或 DAG 型工作流。两者可以组成交付平台，但不应该把“能同步应用”直接等同于“能提交任意工作流”。

官方文档提供了让 Argo Workflows 使用 Argo CD Dex 进行认证的方式。接入时建议分成三组权限：

• 应用交付权限：允许用户查看或同步 Argo CD 中的应用。
• 工作流运行权限：允许用户提交、暂停、重试或终止指定命名空间中的工作流。
• 平台管理权限：允许修改控制器、执行器插件、制品仓库和观测出口。

这不是把所有权限都交给同一个 SSO 角色，而是让身份系统只负责认证，把资源范围和动作范围交给 Argo 的授权配置与平台策略。尤其要把“重试”视为一次可能重新消耗资源和重新写入制品的动作，不能简单按只读操作处理。

按阶段拆解升级影响，而不是一次性改完整个平台

可以把平台接入拆成四个相互独立的阶段。第一阶段确认控制器、CLI、CRD 和 Argo Server 的版本线；第二阶段确认工作流提交、暂停、重试、归档和终止的权限；第三阶段确认执行器、Pod 资源、制品存储和网络出口；第四阶段接入链路观测并把失败结果回写到发布系统。

先做版本盘点时，可以在有权限的运维终端执行下面的检查。部署名称因安装方式而异，示例中的名称需要按实际集群调整：

# 中文注释：先确认 CLI 版本，避免客户端与控制器跨版本排查
argo version

# 中文注释：查看控制器镜像，部署名称按实际安装清单调整
kubectl -n argo get deploy argo-workflows-workflow-controller \
  -o jsonpath='{.spec.template.spec.containers[0].image}'

# 中文注释：检查工作流 CRD 是否存在，先确认资源边界再安排升级
kubectl get crd workflows.argoproj.io

这几条命令只回答“当前运行的版本与资源入口是什么”，不等于升级已经安全。后续还要把控制器镜像、CRD、Server、CLI、插件镜像和制品访问配置放进同一份变更单，避免只升级其中一个组件。

把执行器插件、资源和制品纳入平台门禁

工作流级 Executor Plugin 让任务可以声明更贴近业务的执行能力，但平台要先定义允许清单。门禁至少要回答三个问题：插件是否来自受控镜像，插件能读取哪些 Secret，插件能访问哪些外部系统。

同样的治理思路也适用于资源和制品。DRA 资源声明意味着调度约束可能比普通 CPU、内存更具体；S3 上传线程和分片大小可以改善大制品传输，却也会改变网络并发和对象存储压力；Artifact streaming 则会让“任务开始前是否必须把全部制品落盘”成为平台设计问题。

可以先把这些条件写成平台自己的声明清单，再映射到具体的 Argo 配置：

platformBoundary:
  # 中文注释：只允许平台审核过的执行器插件
  executorPlugins: approved-only
  # 中文注释：按工作流类型绑定资源档位，避免任务自行突破上限
  resourceProfiles: [small, batch, accelerator]
  # 中文注释：制品只能进入登记过的仓库和前缀
  artifactStores: registered-prefixes
  # 中文注释：每个工作流必须带可关联到发布记录的观测标识
  observability: required-trace-label
  # 中文注释：重试和终止动作需要保留操作者与原因
  destructiveActions: audit-with-reason

上面的字段是平台治理清单，不是 Argo 官方 CRD 的可直接提交清单。这样写的价值在于先讨论边界，再把每一项落到 RBAC、Admission、控制器参数、制品仓库策略或观测系统中，避免把业务要求硬塞进一个巨大的 Workflow 模板。

失败处理要覆盖重试、归档和外部副作用

自动化平台最容易遗漏的是失败后的动作。一个工作流失败后，平台至少要区分：可以安全重试的临时错误、需要人工确认的资源或权限错误、已经产生外部副作用而不能直接重试的业务错误。

Argo Workflows 的近期变更涉及暂停工作流终止、归档、控制器队列以及数据库查询上下文等问题。平台在升级时应把这些变化翻译成运行规则：暂停状态如何结束，终止是否需要保留原因，归档是否可检索，重试是否会重复上传制品，数据库或对象存储不可用时通知谁。

1. 先给每类失败定义归属：工作流定义、权限、资源、外部服务或平台自身。
2. 再定义动作：自动重试、延迟重试、转人工、终止或保留现场。
3. 最后定义副作用账本：制品、镜像、数据库写入和外部通知分别记录什么幂等键。

如果没有这张失败矩阵，升级后的新能力越多，平台越容易出现“任务看似失败，外部系统已经成功写入”的重复执行问题。

用观测信号把工作流结果接回发布复盘

官方 v4.1 规划把 Workflow tracing with OpenTelemetry 列为重点能力。对平台团队来说，价值不只是在 Argo UI 中多一条链路，而是可以把一次发布、一次数据任务或一次模型构建关联到工作流节点、Pod、制品上传和外部依赖。

建议至少保留以下关联字段：发布记录 ID、工作流名称、命名空间、提交者、版本或 Git SHA、制品位置、重试次数、最终状态和 trace ID。通知内容则应优先给出“失败在哪个边界”和“下一步动作”，而不是只发送一个 Failed。

给平台团队的一份升级顺序

如果现在要评估 Argo 近期演进，可以按下面的顺序推进，而不是同时改动所有工作流：

1. 建立版本基线：记录 Argo Workflows、Argo CD、CLI、CRD、插件和存储组件的版本。
2. 建立权限基线：分别列出提交、暂停、重试、终止、归档、同步和平台配置权限。
3. 选一条低副作用工作流：优先验证制品上传、资源约束和观测关联，不要先拿有外部写入的核心任务试验。
4. 把失败矩阵接入通知：让权限、资源、制品和外部依赖失败分别进入不同处理队列。
5. 完成一次回滚演练：确认旧版本 CLI、CRD、工作流模板、制品路径和观测字段都能恢复。

我的判断是，Argo 生态的下一阶段竞争点不再只是“谁能编排更多步骤”，而是能否把执行能力、身份、资源、制品和复盘做成清晰的可治理边界。平台团队越早把这些边界拆开，越容易吸收新插件、新资源类型和新的观测能力。

相关问题

Argo CD 能替代 Argo Workflows 吗？

不能简单替代。Argo CD 的核心是 Kubernetes 应用的声明式持续交付，Argo Workflows 的核心是步骤型或 DAG 型工作流执行；它们可以通过平台入口和身份系统协作，但职责不同。

升级 Argo Workflows 时最先检查什么？

先检查版本线、CRD、控制器、Server、CLI、插件和制品存储是否属于同一变更范围，再检查权限、重试和归档规则。

为什么要单独治理 Executor Plugin？

因为插件可能改变任务的执行方式、凭据读取范围和外部网络访问。工作流可配置不等于任何插件都应该对所有租户开放。

参考资料

https://github.com/argoproj/argo-workflows/blob/main/CHANGELOG.md

https://github.com/argoproj/argo-workflows/blob/main/docs/new-features.md

https://github.com/argoproj/argo-workflows/issues/16529

https://argoproj.github.io/argo-workflows/plugin-directory/

https://argoproj.github.io/argo-workflows/argo-server-sso-argocd/

https://argoproj.github.io/argo-cd/