尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

Argo Workflows 4.1.0 新特性:使用 workflowTemplateRef 提交时自动打上 WorkflowTemplate 名称标签

Argo Workflows 4.1.0 新特性:使用 workflowTemplateRef 提交时自动打上 WorkflowTemplate 名称标签 云原生容器编排工作流自动化任务调度后端【免费下载链接】argo-workflowsWorkflow Engine for Kubernetes项目地址https://gitcode.com/gh_mirrors/ar/argo-workflows点击查看免费下载本指南介绍 Argo Workflows 4.1.0 引入的一项实用特性当Workflow或CronWorkflow通过workflowTemplateRef从WorkflowTemplate或ClusterWorkflowTemplate提交时系统会自动把模板名称写入工作流的标签Label中。读完本文你将掌握两个新标签workflows.argoproj.io/workflow-template与workflows.argoproj.io/cluster-workflow-template的语义、底层实现位置以及如何用它们对海量工作流做批量检索、统计与过滤。特性背景为什么需要模板来源标签在 Argo Workflows 中workflowTemplateRef允许工作流引用一个已定义好的WorkflowTemplate命名空间级或ClusterWorkflowTemplate集群级来获得完整的spec。引用模板提交工作流非常简单apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: generateName: workflow-from-template-label- spec: workflowTemplateRef: name: my-wftmplapiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: generateName: workflow-from-cluster-template-label- spec: workflowTemplateRef: name: my-cwftmpl clusterScope: true在 4.1.0 之前虽然工作流实际执行的是模板中定义的流程但从工作流自身的元数据上却无法直接看出它源自哪个模板。当模板数量多、通过同一模板提交的工作流成千上万时想按模板维度统计、筛选或治理这些工作流只能逐个比对spec.workflowTemplateRef非常低效。该特性对应 Issue 12670的解决思路正是把模板名称提升到工作流的标签层让 Kubernetes 原生的标签选择器Label Selector能力直接可用。两个新标签的定义与语义标签键定义在 workflow/common/common.go 中位于workflows.argoproj.io前缀命名空间之下标签键含义打标场景workflows.argoproj.io/workflow-template工作流源自的命名空间级WorkflowTemplate名称使用workflowTemplateRef且未开启clusterScopeworkflows.argoproj.io/cluster-workflow-template工作流源自的集群级ClusterWorkflowTemplate名称使用workflowTemplateRef且clusterScope: true两个标签的值都是模板的名称metadata.name。需要注意这是互斥关系一次提交只会命中其中一个标签由clusterScope决定二者不会同时出现标签由控制器在工作流开始执行时统一写入用户无需手动维护标签键固定、不可配置但标签值即模板名是标准的 Kubernetes 标签天然支持选择器查询。控制器侧的实现setWfTemplateLabel标签的实际写入逻辑在 workflow/controller/operator.go 的setWfTemplateLabel函数中func setWfTemplateLabel(wf *wfv1.Workflow) { if wf.Spec.WorkflowTemplateRef nil { return } if wf.Labels nil { wf.Labels map[string]string{} } if wf.Spec.WorkflowTemplateRef.ClusterScope { wf.Labels[common.LabelKeyClusterWorkflowTemplate] wf.Spec.WorkflowTemplateRef.Name } else { wf.Labels[common.LabelKeyWorkflowTemplate] wf.Spec.WorkflowTemplateRef.Name } }从源码结构可以归纳出三个关键实现事实提前返回若Spec.WorkflowTemplateRef为nil即工作流直接内联定义spec不引用模板函数直接返回不会写入任何模板标签惰性初始化若Labels为nil先创建 map 再写入避免空指针按作用域二选一clusterScope为真时写cluster-workflow-template标签否则写workflow-template标签。该函数在 setExecWorkflow 中被调用控制器在通过 informer 解析出模板的实际specsetStoredWfSpec并构建执行工作流之后随即调用setWfTemplateLabel(woc.wf)完成打标此时spec.workflowTemplateRef已被确认存在。也就是说标签与模板解析是同一处理批次完成的工作流一旦进入执行流程标签即已就位。CronWorkflow 场景模板标签的源头打标除了普通Workflow通过CronWorkflow按调度批量生成的工作流同样适用。由于CronWorkflow.spec.workflowSpec中可能携带workflowTemplateRef控制器在将 CronWorkflow 转换为待执行 Workflow 时就会打上模板标签。相关的两个转换入口都在 workflow/common/convert.go 中ConvertCronWorkflowToWorkflowworkflow/common/convert.go常规调度触发ConvertCronWorkflowToWorkflowWithPropertiesworkflow/common/convert.go带调度时间与属性传播的触发路径。两者最终都调用toWorkflowworkflow/common/convert.go将 CronWorkflow 的WorkflowSpec整体拷贝给新 Workflow因此workflowTemplateRef会一并继承随后由控制器的setWfTemplateLabel完成打标。另外workflow/common/convert.go 中的NewWorkflowFromWorkflowTemplate是 CLI/服务端基于模板创建新工作流的辅助函数它会在创建工作流对象的同时直接写入对应模板标签workflow/common/convert.go与控制器侧的打标行为保持一致。实战如何用模板标签检索与统计工作流有了标签就可以用 Kubernetes 原生的labelSelector做各种批量操作。使用 argo CLI 列出某个模板产出的所有工作流argo list -l workflows.argoproj.io/workflow-templatemy-wftmpl # 集群级模板同理 argo list -l workflows.argoproj.io/cluster-workflow-templatemy-cwftmpl使用 kubectl 直接过滤kubectl get workflows -n namespace -l workflows.argoproj.io/workflow-templatemy-wftmpl # 查看标签是否已写入 kubectl get workflow name -o jsonpath{.metadata.labels}按模板统计成功/失败情况标签与既有的workflows.argoproj.io/phase标签同样定义在 workflow/common/common.go可以组合查询例如argo list -l workflows.argoproj.io/workflow-templatemy-wftmpl,workflows.argoproj.io/phaseFailed在代码中按模板查询CLI 内部正是通过ListOptions.LabelSelector实现的参见 test/e2e/cli_test.go 中ExpectWorkflowList(metav1.ListOptions{LabelSelector: common.LabelKeyWorkflowTemplate workflow-template-whalesay-template}, ...)的用法。标签的价值不止于查询索引与预估模板标签不只是给人看的元数据它还被控制器内部机制直接使用Informer 索引在 workflow/controller/controller.go 中控制器分别以LabelKeyWorkflowTemplate和LabelKeyClusterWorkflowTemplate为索引键注册了模板索引WorkflowTemplateIndex、ClusterWorkflowTemplateIndex便于按模板维度高效检索缓存中的工作流运行时长预估在 workflow/controller/estimation/estimator_factory.go 中预估器工厂依据这两个标签查询历史工作流用同模板的历史运行数据估算新工作流的预计耗时支撑进度展示与超时判断其单元测试 estimator_factory_test.go 直接构造了携带这两个标签的 Workflow 对象进行验证。由此可见模板标签既是面向用户的查询入口也是控制器内部模板维度索引与估算能力的公共数据基础一个特性同时服务了外部可观测性与内部调度逻辑。测试佐证e2e 如何验证打标行为该特性有完整的端到端测试覆盖标记为//go:build functional命名空间级模板test/e2e/workflow_template_test.go 中的TestWorkflowTemplateHasLabel提交一个仅含workflowTemplateRef的工作流等待成功后断言metadata.Labels[common.LabelKeyWorkflowTemplate] workflow-template-label-test集群级模板test/e2e/cluster_workflow_template_test.go 中的TestClusterWorkflowFromWorkflowTemplateHasLabel以clusterScope: true提交断言metadata.Labels[common.LabelKeyClusterWorkflowTemplate] cluster-workflow-template-whalesay-templateCronWorkflow 场景test/e2e/cron_test.go 验证由 CronWorkflow 调度产生的工作流同样带有workflow-template标签事件/Webhook 场景test/e2e/argo_server_test.go 验证通过 WorkflowEventBinding 触发的工作流也会被打上对应标签。单元测试 workflow/util/util_test.go 则从另一个角度确认工具层处理后的工作流同时包含两个标签键且可通过wf.GetLabels()读取。使用前提与注意事项版本前提该特性随 v4.1.0 发布使用前请确认 controller 镜像版本不低于 4.1.0标签来源唯一标签由控制器在解析workflowTemplateRef时自动写入用户若在workflowMetadata.labels中手动指定同名标签会被控制器行为覆盖/以控制器写入为准建议不要在自定义元数据中占用这两个键区分两种模板命名空间级模板与集群级模板使用不同的标签键查询时需与创建时使用的clusterScope保持一致否则会查不到结果内联工作流无标签直接内联spec不引用模板的工作流不会获得模板标签setWfTemplateLabel对WorkflowTemplateRef nil的情况直接返回。小结Argo Workflows 4.1.0 的模板来源标签特性用最小的改动控制器侧一个setWfTemplateLabel函数把工作流源自哪个模板这一高频查询维度下沉到了 Kubernetes 标签体系workflows.argoproj.io/workflow-template与workflows.argoproj.io/cluster-workflow-template两个标签让argo list、kubectl乃至 API 层的labelSelector都能按模板批量检索工作流同时为控制器的模板索引与运行时长预估提供了数据基础。对于以模板为中心管理大规模工作流的团队这是一项低成本、高回报的查询与治理能力升级。赞分享云原生容器编排工作流自动化任务调度后端【免费下载链接】argo-workflowsWorkflow Engine for Kubernetes项目地址https://gitcode.com/gh_mirrors/ar/argo-workflows点击查看免费下载相关推荐Argo Workflows CLI 实战用 argo template create 命令创建 WorkflowTemplate 完整指南Argo Workflows CLI 实战用 argo template create 命令创建 WorkflowTemplate 完整指南 导读 argo云原生容器编排工作流自动化任务调度后端Argo Workflows CLI 实战使用 argo resubmit 重新提交已完成的 WorkflowArgo Workflows CLI 实战使用 argo resubmit 重新提交已完成的 Workflow argo resubmit 是 Argo Wo云原生容器编排工作流自动化任务调度后端Arclight部署实战如何在生产环境中稳定运行高并发服务器Arclight部署实战如何在生产环境中稳定运行高并发服务器 Arclight部署 是每个Minecraft服务器管理员必须掌握的核心技能特别是在面对高并发云原生容器编排工作流自动化任务调度后端上一篇零成本无限发Billion Mail开源邮件营销平台全面测评下一篇AirSim模仿学习完整工作流从采集驾驶数据到训练神经网络驾驶模型创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表