升级指南¶

重大变更通常（有时我们并未意识到它们是破坏性的）会在提交信息中包含"!"，遵循conventional commits的规范。

升级至v3.6版本¶

另请参阅3.6版本中的新功能列表。

弃用项¶

以下功能已被弃用，并将在未来版本的Argo Workflows中移除：

Python SDK 已弃用，我们建议迁移至 Hera
schedule 在 CronWorkflows 中，podPriority、mutex 和 semaphore 在 Workflows 和 WorkflowTemplates 中。

有关如何迁移这些内容的更多信息，请参阅弃用说明

修复服务器 `--basehref` 不一致问题¶

为了保持一致性，服务器现在使用--base-href和ARGO_BASE_HREF。之前使用的是--basehref(中间没有短横线)和ARGO_BASEHREF(中间没有下划线)。

移除了冗余的Server环境变量¶

ALLOWED_LINK_PROTOCOL 和 BASE_HREF 已被移除，因为它们是冗余的。请改用 ARGO_ALLOWED_LINK_PROTOCOL 和 ARGO_BASE_HREF。

移除了传统不安全的Pod补丁回退机制。(#13100)¶

为了使Emissary执行器正常工作，您必须设置RBAC。请参阅workflow RBAC

PostgreSQL上的归档工作流¶

为提高性能，本次升级将在控制器启动时自动将用于存储归档工作流的列从json类型转换为jsonb类型。此操作需要PostgreSQL 9.4或更高版本。

迁移过程需要对argo_archived_wokflows表获取ACCESS EXCLUSIVE锁，这将阻塞所有读写操作直至完成。对于绝大多数用户，我们预计该过程耗时不超过一分钟，但如果您有大量工作流（10万+）或平均工作流体积较大（100KB+），则可能耗时更久。 如果您不属于以上两种情况，或者停机时间对您影响不大，则无需继续阅读。 否则，您可以通过以下几种方式将停机时间降至最低：

如果您不再需要这些已归档的工作流，只需使用delete from argo_archived_workflows删除它们，迁移几乎可以立即完成。

采用Altering a Postgres Column with Minimal Downtime的变体方法，可以近乎零停机时间手动执行此迁移。这是一个两步流程：

在升级前，请运行以下查询来创建一个临时的workflowjsonb列并用现有数据填充它。在运行3.5版本时这样做是安全的，因为列类型是兼容的。

-- 添加临时workflowjsonb列
ALTER TABLE argo_archived_workflows ADD COLUMN workflowjsonb JSONB NULL;

-- 添加触发器以便每次插入时更新workflowjsonb
CREATE OR REPLACE FUNCTION update_workflow_jsonb() RETURNS TRIGGER AS $BODY$
BEGIN
    NEW.workflowjsonb=NEW.workflow;
    RETURN NEW;
END
$BODY$ LANGUAGE PLPGSQL;

CREATE TRIGGER argo_archived_workflows_update_workflow_jsonb
BEFORE INSERT ON argo_archived_workflows
FOR EACH ROW EXECUTE PROCEDURE update_workflow_jsonb();

-- 回填现有行
UPDATE argo_archived_workflows SET workflowjsonb = workflow WHERE workflowjsonb IS NULL;

当上述步骤完成并准备继续升级时，在启动控制器之前运行以下查询：

BEGIN;
LOCK TABLE argo_archived_workflows IN SHARE ROW EXCLUSIVE MODE;
DROP TRIGGER argo_archived_workflows_update_workflow_jsonb ON argo_archived_workflows;
ALTER TABLE argo_archived_workflows DROP COLUMN workflow;
ALTER TABLE argo_archived_workflows RENAME COLUMN workflowjsonb TO workflow;
ALTER TABLE argo_archived_workflows ADD CONSTRAINT workflow CHECK (workflow IS NOT NULL) NOT VALID;
COMMIT;

版本3.6保持了对存储为json类型工作流的兼容性。因此，目前可以通过设置skipMigration: true来跳过迁移是安全的。这仅应作为紧急临时措施使用，因为未来版本可能会在不通知的情况下停止对json的支持。

指标变更¶

您现在可以通过OpenTelemetry collector使用OpenTelemetry协议获取指标数据，这是推荐的方式。

这些说明解释了使用Prometheus /metrics端点来抓取指标以实现最小化升级工作量的差异。不建议盲目遵循本指南，新指标的引入是因为它们具有价值，因此值得收集和使用。

新增指标¶

以下是新增的指标：

cronworkflows_concurrencypolicy_triggered
cronworkflows_triggered_total
deprecated_feature
is_leader
k8s_request_duration
pod_pending_count
pods_total_count
queue_duration
queue_longest_running
queue_retries
queue_unfinished_work
total_count
version
workflowtemplate_runtime
workflowtemplate_triggered_total

并且可以通过以下方式禁用

metricsConfig: |
  modifiers:
    build_info:
      disable: true
...

重命名的指标¶

如果您在记录规则、仪表板或告警中使用这些指标，升级后需要更新它们的名称：

旧名称	新名称
`argo_workflows_count`	`argo_workflows_gauge`
`argo_workflows_pods_count`	`argo_workflows_pods_gauge`
`argo_workflows_queue_depth_count`	`argo_workflows_queue_depth_gauge`
`log_messages`	`argo_workflows_log_messages`

自定义指标¶

自定义指标名称和标签现在必须是有效的Prometheus和OpenTelemetry名称。这限制了:符号的使用，该符号在早期版本的workflows中是可用的。

自定义指标（由工作流定义）可能在一个工作流中被定义为某种类型（例如计数器），然后在另一个工作流中被定义为同名的直方图。在3.5版本中，如果该指标的首次使用已达到TTL并被删除，这种做法是可行的。但在3.6版本中将不再适用，且自定义指标不可被重新定义。以这种方式更改指标实际上并不合理，而且OpenTelemetry SDK会阻止您这样做。

metricsTTL 对于直方图指标无效，因为opentelemetry不允许删除指标。对于其他指标类型，这是通过异步仪表模拟实现的。

TLS¶

Prometheus的/metrics端点现在默认启用TLS。要禁用此功能，请将metricsConfig.secure设置为false。

移除Swagger UI¶

Swagger UI 已从 /apidocs 页面移除。它已被替换为指向版本化文档中的 Swagger UI的链接，以及 OpenAPI 规范和 JSON 模式的下载链接。

JSON模板修复¶

在表达式中返回映射或数组时，您会得到Golang的表示形式。现在返回的是纯JSON。

`ARGO_TEMPLATE` 已从主容器中移除¶

环境变量 ARGO_TEMPLATE 作为内部实现细节，将不再在您工作流pod的 main 容器中可用。我们在此记录这一点，因为我们知道有些Argo Workflows用户会使用它。

升级至v3.5版本¶

此版本中没有已知的重大变更。如果在升级后遇到任何意外问题，请提交问题报告。

统一工作流列表API与用户界面¶

UI中的工作流列表现在会在同一页面显示已归档的工作流。因此，之前UI中单独的已归档工作流页面已被移除。

List API /api/v1/workflows 现在也会返回两种类型的Workflows。这不会造成破坏性变更，因为Archived API仍然存在且未被移除，所以这是一个新增功能。

升级至v3.4版本¶

非Emissary执行器已被移除。(#7829)¶

Emissary执行器现在是唯一受支持的执行器。如果您正在使用其他执行器，例如docker、k8sapi、pns和kubelet，您需要从控制器的configmap中移除containerRuntimeExecutors和containerRuntimeExecutor配置。如果您的workflow使用了带有workflows.argoproj.io/container-runtime-executor标签的不同执行器，这不再受支持且不会生效。

chore!: 从代码库中移除dataflow流水线。(#9071)¶

如果您在UI界面或通过/pipelines端点使用数据流管道，则会受到影响。我们不再支持数据流管道功能，所有相关代码已被移除。

功能更新!: 添加入口点查找功能。修复问题 #8344¶

受影响条件：

使用Emissary执行器。
对images中的任何条目使用了args字段。

该PR会自动查找命令和入口点。之前的配置查找实现有误（允许指定args但不允许指定entrypoint）。现已移除args以修正此行为。

如果配置不正确，工作流控制器将在启动时报错。

操作¶

您不再需要配置使用v2清单的镜像，例如argoproj/argosay:v2。您可以移除它们：

% docker manifest inspect argoproj/argosay:v2
# ...
"schemaVersion": 2,
# ...

对于v1版本的清单，例如docker/whalesay:latest：

% docker image inspect -f '{{.Config.Entrypoint}} {{.Config.Cmd}}' docker/whalesay:latest
[] [/bin/bash]

images:
  docker/whalesay:latest:
    cmd: [/bin/bash]

功能：在配置无效时失败处理 (#8295)¶

如果配置不正确，工作流控制器将在启动时报错，而不是静默忽略错误配置。

Failed to register watch for controller config map: error unmarshaling JSON: while decoding JSON: json: unknown field \"args\"

功能：添加索引以提升归档工作流性能。(#8860)¶

该PR为归档的工作流表添加了索引。如果用户表数据量较大，此变更可能导致升级耗时较长。

功能：增强制品可视化 (#8655)¶

对于使用S3的AWS用户：在UI中可视化工件和下载它们现在需要在您的S3存储桶策略中配置额外的"Action"："ListBucket"。

升级至v3.3版本¶

662a7295b 功能: 将`patch pod`替换为`create workflowtaskresult`。修复 #3961 (#8000)¶

该PR修改了工作流可使用的权限，移除了pod patch权限。

参见 workflow RBAC 和 #8013。

06d4bf76f 修复: 减少智能体权限。修复 #7986 (#7987)¶

该PR修改了智能体用于报告HTTP模板请求结果所使用的权限。例如，权限patch workflowtasksets/status替换了patch workflowtasksets：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: agent
rules:
  - apiGroups:
      - argoproj.io
    resources:
      - workflowtasksets/status
    verbs:
      - patch

在升级期间运行的工作流应同时获得这两项权限。

参见 #8013。

功能更新!: 移除已弃用的配置标志¶

该PR移除了以下配置项 -

executorImage (请改用configmap中的executor.image) 例如：类似以下给出的工作流控制器配置映射将不再有效：

apiVersion: v1
kind: ConfigMap
metadata:
  name: workflow-controller-configmap
data:
  ...
  executorImage: argoproj/argocli:latest
  ...

从现在开始，仅在工作流控制器中以命令参数形式提供执行器镜像，如下所示：

apiVersion: v1
kind: ConfigMap
metadata:
  name: workflow-controller-configmap
data:
  ...
  executor: |
    image: argoproj/argocli:latest
  ...

executorImagePullPolicy（请改用configmap中的executor.imagePullPolicy）例如：类似以下给出的工作流控制器配置映射将不再有效：

data:
  ...
  executorImagePullPolicy: IfNotPresent
  ...

按如下所示进行更改：

data:
  ...
  executor: |
    imagePullPolicy: IfNotPresent
  ...

executorResources (请改用configmap中的executor.resources) 例如：类似以下给出的工作流控制器配置映射将不再有效：

data:
  ...
  executorResources:
    requests:
      cpu: 0.1
      memory: 64Mi
    limits:
      cpu: 0.5
      memory: 512Mi
  ...

按如下所示进行更改：

data:
  ...
  executor: |
    resources:
      requests:
        cpu: 0.1
        memory: 64Mi
      limits:
        cpu: 0.5
        memory: 512Mi
  ...

fce82d572 功能：移除Pod工作线程 (#7837)¶

该PR从代码中移除了pod workers，pod informer直接写入工作流队列。因此--pod-workers标志已被移除。

93c11a24ff 功能：为指标和遥测服务器添加TLS支持 (#7041)¶

该PR新增了通过TLS使用自签名证书发送指标的功能。在v3.5版本中此功能将默认启用，因此建议用户现在就启用该功能。

0758eab11 功能(服务器)!: 默认同步分发Webhook事件¶

预计这不会对用户产生影响。

Argo Server中的事件分发默认已从异步改为同步。这样可以将错误反馈给客户端，而不仅仅是记录在日志或Kubernetes事件中。但需要注意，在高负载情况下响应时间可能对您的客户端来说过长，您可以选择恢复之前的行为。

要恢复此行为，请使用ARGO_EVENT_ASYNC_DISPATCH=true重新启动Argo Server。确保日志中记录asyncDispatch=true。

bd49c6303 修复(artifact)!: 默认对缺少协议的URL使用https。修复 #6973¶

没有指定协议的HTTPArtifact现在将默认使用https而非http

如果用户希望通过http获取HTTPArtifact，需要明确包含http前缀

维护!: 从`argo submit`中移除隐藏标志`--verify`¶

隐藏标志 --verify 已从 argo submit 中移除。这是一个我们不再需要的内部测试标志。

升级至v3.2版本¶

e5b131a33 功能：在Pod名称中添加模板节点。修复 #1319 (#6712)¶

这会将模板名称添加到Pod名称中，以便更容易理解哪个Pod运行了哪个步骤。通过在workflow控制器上设置POD_NAMES=v1可以恢复此行为。

be63efe89 功能(执行器)!: 将`argoexec`基础镜像更改为alpine。关闭 #5720 (#6006)¶

从Debian切换到Alpine可以减小argoexec镜像的尺寸，从而加快工作流pod的启动速度，同时也能降低安全风险。但天下没有免费的午餐，这种改变可能会带来其他我们尚未知晓的行为变化。

部分用户发现这一变更导致带有超大参数的工作流无法运行。详见#7586

48d7ad3 优化: 移除onExit命名转换的脚手架代码 (#6297)¶

当从升级到>v3.2时，正在运行且包含onExit步骤的工作流可能会遇到onExit步骤运行两次的情况。这种情况仅适用于在workflow-controller升级前已开始运行且升级完成后仍在运行的工作流。此问题仅适用于从v2.12或更早版本直接升级到v3.2或更高版本的情况。即使在这些条件下，也可能不会出现重复执行的情况。

升级至v3.1版本¶

3fff791e4 构建!: 自动将清单文件添加到 `v*` 标签 (#5880)¶

仓库中该标签下的清单将不再包含镜像标签，而是会包含:latest。

您不能从Git仓库获取清单，必须从发布说明中获取。
请勿使用stable标签。该标签已失效，并将在v3.1版本中移除。

ab361667a 功能(控制器) Emissary执行器. (#4925)¶

Emissary执行器本身并非破坏性变更，但由于它是全新功能，我们目前不建议您默认使用。我们建议您先通过配置workflow-controller-configmap在某些工作流中进行测试。

# Specifies the executor to use.
#
# You can use this to:
# * Tailor your executor based on your preference for security or performance.
# * Test out an executor without committing yourself to use it for every workflow.
#
# To find out which executor was actually use, see the `wait` container logs.
#
# The list is in order of precedence; the first matching executor is used.
# This has precedence over `containerRuntimeExecutor`.
containerRuntimeExecutors: |
  - name: emissary
    selector:
      matchLabels:
        workflows.argoproj.io/container-runtime-executor: emissary

be63efe89 功能(控制器): 表达式模板标签。解决 #4548 和 #1293 (#5115)¶

该PR引入了一种称为"表达式标签模板"的新语法。有用户反馈这种语法与when条件语法(Goevaluate)并不总是能很好地配合使用。

这可以通过在您的when表达式中使用单引号来解决：

when: "'{{inputs.parameters.should-print}}' != '2021-01-01'"

了解更多

升级至v3.0版本¶

defbd600e 修复：默认设置 ARGO_SECURE=true。修复问题 #5607 (#5626)¶

如果密钥可用，服务器现在默认启用TLS启动。原始行为可通过--secure=false进行配置。

如果您配置了入口(Ingress)，可能需要添加适当的注解（根据入口类型而异）：

alb.ingress.kubernetes.io/backend-protocol: HTTPS
nginx.ingress.kubernetes.io/backend-protocol: HTTPS

01d310235 改进(server)!: 默认要求身份验证。解决 #5206 (#5211)¶

要登录用户界面，您必须提供登录令牌。原始行为可通过--auth-mode=server进行配置。

f31e0c6f9 更新：移除已弃用字段 (#5035)¶

2020年初已弃用的一些字段现已被移除。

字段	操作
template.template 和 template.templateRef	必须修改工作流规范以使用步骤或DAG，否则工作流将报错。
spec.ttlSecondsAfterFinished	change to `spec.ttlStrategy.secondsAfterCompletion`, otherwise the workflow will not be garbage collected as expected.

查找受影响的工作流：

kubectl get wf --all-namespaces -o yaml | grep templateRef
kubectl get wf --all-namespaces -o yaml | grep ttlSecondsAfterFinished

c8215f972 功能(控制器)!: 仅键值工件。修复 #3184 (#4618)¶

这一变更本身并非破坏性改动，但许多用户似乎并不了解artifact repository ref功能，因此若遇到问题请检查您对该特性的使用情况。

有问题吗？

Search on GitHub Discussions and Slack.