Argo Workflows 工作流级 Executor Plugin 配置在 Workflow Spec 内声明插件并覆盖全局配置【免费下载链接】argo-workflowsWorkflow Engine for Kubernetes项目地址: https://gitcode.com/gh_mirrors/ar/argo-workflows导读本文聚焦 Argo Workflows v4.1.0 引入的工作流级workflow-levelExecutor Plugin 配置能力对应 issue #15234。该功能允许直接在Workflow的 spec 中声明 Executor Plugin 及其 sidecar 容器并通过ARGO_WORKFLOW_LEVEL_EXECUTOR_PLUGINStrue控制器环境变量开启一旦工作流级插件被声明它们将优先于Workflow Controller ConfigMap 中的全局插件配置。读完本文你将掌握功能开关的启用方式、spec.executorPlugins字段的完整结构与校验规则、工作流级与全局插件的优先级/回退逻辑、一个可运行的 Python 插件端到端示例以及插件失败重试、Re-Queue 等运行时行为。功能背景为什么需要工作流级 Executor Plugin 配置Argo Workflows 的 Executor Plugin 机制允许用户以自定义 HTTP 服务以 sidecar 容器形式运行在 Agent Pod 中扩展工作流的模板执行能力——例如接入 Slack 通知、第三方 CI 系统或内部任务平台。在 v4.1.0 之前Executor Plugin 只能全局配置在 Workflow Controller 的 ConfigMap 中通过ExecutorPlugin类型的 ConfigMap 声明所有工作流共享同一组插件。这种全局模式存在明显的局限性插件属于集群/命名空间级共享资源不同工作流无法按需选择不同的插件集合插件的启用需要修改控制器 ConfigMap 并依赖控制器重新发现变更影响面大无法在 CI/CD 流水线中以工作流清单manifest的形式将插件与工作流一起版本化、一起分发。工作流级 Executor Plugin 配置正是为了解决这些问题而设计插件定义可以直接内嵌在Workflow的spec.executorPlugins字段中随工作流一起提交、一起演进。该特性在 v4.1.0 的发布特性文档.features/released/v4.1.0/15234-argo-workflow-level-executor-plugin-configuration.md中正式宣告官方主文档 docs/executor_plugins.md 也同步更新了对应配置说明。功能开关两个独立的环境变量Executor Plugins 默认是禁用的disabled by default需要显式开启。官方文档docs/executor_plugins.md给出了两个相互独立、可单独或同时开启的开关环境变量作用ARGO_EXECUTOR_PLUGINStrue启用配置在控制器 ConfigMap 中的全局Executor PluginsARGO_WORKFLOW_LEVEL_EXECUTOR_PLUGINStrue允许使用直接写在Workflow spec中的 Executor Plugin 配置且优先级高于全局配置这两个选项相互独立可以只开全局插件、只开工作流级插件或者两者同时开启。在 Deployment 中启用在 Workflow Controller 的 Deployment 中为容器添加环境变量apiVersion: apps/v1 kind: Deployment metadata: name: workflow-controller spec: template: spec: containers: - name: workflow-controller env: - name: ARGO_EXECUTOR_PLUGINS value: true - name: ARGO_WORKFLOW_LEVEL_EXECUTOR_PLUGINS value: true使用 Helm Chart 时的配置使用官方 Helm chartargo-helm 的argo-workflowschart时在values.yaml中追加controller: extraEnv: - name: ARGO_EXECUTOR_PLUGINS value: true - name: ARGO_WORKFLOW_LEVEL_EXECUTOR_PLUGINS value: true源码中的实现对应从源码看这两个开关在控制器侧有着清晰的落点命令行入口 cmd/workflow-controller/main.go 定义了两个布尔 flag--executor-plugins对应ARGO_EXECUTOR_PLUGINS与--workflow-level-executor-plugins对应ARGO_WORKFLOW_LEVEL_EXECUTOR_PLUGINS二者均默认false。workflow/controller/controller.go 的NewWorkflowController构造函数接收executorPlugins与workflowLevelExecutorPlugins两个布尔参数前者非空时初始化wfc.executorPlugins映射namespace → name → plugin后者保存在控制器的enableWorkflowLevelExecutorPlugins字段中controller.go。当工作流声明了executorPlugins而控制器未开启对应开关时会在 workflow/controller/agent.go 直接报错提示设置ARGO_WORKFLOW_LEVEL_EXECUTOR_PLUGINStrue。spec.executorPlugins字段结构与校验规则工作流级 Executor Plugin 通过WorkflowSpec.ExecutorPlugins字段声明其 API 注释pkg/apis/workflow/v1alpha1/workflow_types.go明确了三条核心语义该字段仅在ARGO_WORKFLOW_LEVEL_EXECUTOR_PLUGINS特性开关开启时生效如果该字段包含一个或多个 Executor Plugin控制器 ConfigMap 中的 Executor Plugin 配置将被忽略对本工作流而言如果该字段为空或未设置控制器回退到 ConfigMap 配置。字段对应的 Go 类型定义位于 workflow_types.gotype ExecutorPlugin struct { metav1.ObjectMeta json:metadata protobuf:bytes,2,opt,namemetadata Spec ExecutorPluginSpec json:spec protobuf:bytes,1,opt,namespec } type ExecutorPluginSpec struct { Sidecar ExecutorPluginSidecar json:sidecar protobuf:bytes,1,opt,namesidecar } type ExecutorPluginSidecar struct { // AutomountServiceAccountToken 启用 service account token 挂载 // service account 必须命名为 plugin-name-executor-plugin。 AutomountServiceAccountToken bool json:automountServiceAccountToken,omitempty // Container 定义 sidecar 的 Kubernetes 容器规范。 Container apiv1.Container json:container }可见工作流级插件的结构与全局ExecutorPluginConfigMap 中的spec.sidecar结构一致一个metadata名称 一个spec.sidecar.container完整的 Kubernetes 容器定义。也就是说全局插件能表达的容器能力镜像、命令、参数、端口、环境变量、资源、安全上下文等在工作流级全部可用。校验逻辑从 spec 到运行时插件的转换WorkflowSpec.AsExecutorPluginSpec()workflow_types.go负责把 spec 中的插件声明转换为控制器内部的插件模型并执行校验插件名称metadata.name为必填若为空返回executor plugin metadata name is mandatory错误每个插件的sidecar会调用sidecar.Validate()进行结构校验校验通过后Plugin.Spec.Sidecar含AutomountServiceAccountToken与Container被逐个收集成插件列表返回。之后 agent.go 的 getExecutorPlugins 将转换后的插件逐一展开为 Agent Pod 的 sidecar 容器与卷每个插件容器会挂载只读的/var/run/argo卷SubPath使用容器名保证只挂载该插件自己的 token并仅在AutomountServiceAccountToken为 true 时额外挂载{plugin-name}-executor-plugin的 service account token 卷。完整示例在 Workflow Spec 内声明一个 Python 插件官方仓库在 examples/workflow-level-executor-plugin.yaml 提供了一个完整、可直接运行的示例插件以 Python 内联脚本形式内嵌在工作流清单中监听4356端口收到workflowLevelHello的 plugin 请求时返回 Hello from a workflow-level executor plugin!。示例解析# workflow-controller 必须以 ARGO_WORKFLOW_LEVEL_EXECUTOR_PLUGINStrue 启动 apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: generateName: workflow-level-executor-plugin- labels: workflows.argoproj.io/no-test: environment spec: entrypoint: main executorPlugins: - metadata: name: workflow-level-hello-executor-plugin spec: sidecar: container: name: workflow-level-hello-executor-plugin image: python:alpine3.23 command: - python - -c args: - | import json from http.server import BaseHTTPRequestHandler, HTTPServer class Plugin(BaseHTTPRequestHandler): def args(self): return json.loads(self.rfile.read(int(self.headers.get(Content-Length)))) def reply(self, reply): self.send_response(200) self.end_headers() self.wfile.write(json.dumps(reply).encode(UTF-8)) def unsupported(self): self.send_response(404) self.end_headers() def do_POST(self): if self.path /api/v1/template.execute: args self.args() if workflowLevelHello in args[template].get(plugin, {}): self.reply({ node: { phase: Succeeded, message: Hello from a workflow-level executor plugin! } }) else: self.reply({}) else: self.unsupported() if __name__ __main__: httpd HTTPServer((, 4356), Plugin) httpd.serve_forever() ports: - containerPort: 4356 resources: limits: cpu: 200m memory: 64Mi requests: cpu: 100m memory: 32Mi securityContext: allowPrivilegeEscalation: false capabilities: drop: - ALL readOnlyRootFilesystem: true runAsNonRoot: true templates: - name: main plugin: workflowLevelHello: {}运行后main模板中的plugin: {workflowLevelHello: {}}会触发 executor 向该 sidecar 发送template.executeRPC插件返回Succeeded工作流顺利完成。与全局插件方式的对比对照 docs/executor_plugins.md 中全局插件的工作流argo executor-plugin build .生成 ConfigMap →kubectl apply→ 控制器日志出现Executor plugin added工作流级方式有两点显著不同无需构建与安装步骤插件直接以工作流清单内嵌的容器定义存在省去了argo executor-plugin build和 ConfigMap 下发流程作用域为本工作流插件声明不会注册到控制器日志中不会出现Executor plugin added也不会影响其他工作流。当然全局方式仍然适用于组织级共享插件的场景两种方式可按需混用同时开启两个开关。优先级与回退工作流级覆盖全局根据 docs/executor_plugins.md 与类型注释二者的解析逻辑可以总结为if spec.executorPlugins 非空: 使用工作流级插件忽略 ConfigMap 中的全局插件 若控制器未开启 ARGO_WORKFLOW_LEVEL_EXECUTOR_PLUGINS - 报错 else: 回退到 ConfigMap 中的全局插件需 ARGO_EXECUTOR_PLUGINStrue该逻辑在 agent.go 的 getExecutorPlugins 中有清晰实现先调用AsExecutorPluginSpec()得到wFPluginslen(wFPlugins) 0即为从工作流取插件分支——此时若enableWorkflowLevelExecutorPlugins为 false 直接报错否则展开工作流级插件为 sidecar。反之工作流未声明插件才遍历controller.executorPlugins即控制器从 ConfigMap 发现并缓存的全局插件加载逻辑见 controller.go。需要注意一个容易误解的点覆盖发生在插件来源层面而非同名插件合并。只要工作流声明了至少一个插件该工作流就不会再加载任何 ConfigMap 中的全局插件。全局插件名称冲突的处理规则仅工作流所在命名空间的插件被加载参见 docs/executor_plugins.md 的 Discovery 小节。插件运行时行为认证、失败与 Re-Queue工作流级插件与全局插件共享同一套运行时契约executor_swagger.md 描述了 RPC HTTP API因此以下行为对两种插件一致编写工作流级插件时同样需要遵循认证与路径约定插件只需实现需要的方法如template.execute路径即 RPC 方法名请求的Authorization头必须与/var/run/argo/token中的值一致否则应返回403插件会因 token 挂载方式不同而被注入相应 token见上文getExecutorPluginComponents请求体包含模板的输入参数响应体可包含节点的结果phase、message、outputs等响应{}表示该插件无法执行此 Plugin 模板例如 Slack 插件遇到 Tekton 模板。端口选择建议端口可任意但不能与其他 Executor Plugin 冲突避免使用 80、443、8080、8081、8443 等常见端口。若计划发布插件请选择 10000 以下的随机端口并提交 PR 加入插件目录否则使用大于 10000 的端口。失败语义与重试docs/executor_plugins.md 明确定义了失败分类错误类型语义连接/socket 错误瞬态transient重试超时瞬态重试404方法不受支持同一工作流内不再调用该方法503瞬态重试其他 4xx/5xx致命fatal导致步骤失败Re-Queue长任务场景若插件启动了一个长任务、无法立即完成可返回Running/Pending状态并给出重新入队时间{ node: { phase: Running, message: Long-running task started }, requeue: 2m }上述示例中任务将在 2 分钟后被重新入队template.execute再次被调用。资源与安全工作流级插件的强制约束全局 Executor Plugin 在 docs/executor_plugins.md 中强调resources与securityContext是强制的避免插件滥用内存或默认以 root 运行工作流级插件同样建议遵循这一约束。示例中的安全基线securityContext: allowPrivilegeEscalation: false capabilities: drop: - ALL readOnlyRootFilesystem: true runAsNonRoot: true resources: requests: cpu: 100m memory: 32Mi limits: cpu: 200m memory: 64Mi此外若插件需要与第三方系统交互密钥不应硬编码在清单中应通过secretKeyRef注入环境变量见 docs/executor_plugins.md 的 Secrets 小节例如env: - name: URL valueFrom: secretKeyRef: name: slack-executor-plugin key: URL排查与调试查看插件日志Executor Plugin 运行在 Agent Pod 的 sidecar 中日志位于kubectl -n argo logs ${agentPodName} -c hello-executor-plugin查看控制器是否加载了全局插件控制器日志中出现Executor plugin added表示全局插件注册成功工作流级插件不会产生该日志。工作流级插件被忽略或报错请检查控制器环境变量ARGO_WORKFLOW_LEVEL_EXECUTOR_PLUGINS是否设置为true以及spec.executorPlugins中每个插件的metadata.name是否非空且spec.sidecar.container结构合法——这两项分别在 agent.go 与 workflow_types.go 中校验。参考特性宣告.features/released/v4.1.0/15234-argo-workflow-level-executor-plugin-configuration.md官方配置文档docs/executor_plugins.md官方示例examples/workflow-level-executor-plugin.yaml类型定义与校验pkg/apis/workflow/v1alpha1/workflow_types.goexecutorPlugins字段、workflow_types.go类型结构、workflow_types.goAsExecutorPluginSpec控制器实现workflow/controller/controller.go构造参数、workflow/controller/agent.go插件解析与 sidecar 展开命令行开关cmd/workflow-controller/main.goRPC API 契约docs/executor_swagger.md插件目录docs/plugin-directory.md【免费下载链接】argo-workflowsWorkflow Engine for Kubernetes项目地址: https://gitcode.com/gh_mirrors/ar/argo-workflows创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/21 15:07:32 · 阅读 1.2k Argo Workflows 工作流级 Executor Plugin 配置：在 Workflow Spec 内声明插件并覆盖全局配置
Argo Workflows 工作流级 Executor Plugin 配置在 Workflow Spec 内声明插件并覆盖全局配置【免费下载链接】argo-workflowsWorkflow Engine for Kubernetes项目地址: https://gitcode.com/gh_mirrors/ar/argo-workflows导读本文聚焦 Argo Workflows v4.1.0 引入的工作流级workflow-levelExecutor Plugin 配置能力对应 issue #15234。该功能允许直接在Workflow的 spec 中声明 Executor Plugin 及其 sidecar 容器并通过ARGO_WORKFLOW_LEVEL_EXECUTOR_PLUGINStrue控制器环境变量开启一旦工作流级插件被声明它们将优先于Workflow Controller ConfigMap 中的全局插件配置。读完本文你将掌握功能开关的启用方式、spec.executorPlugins字段的完整结构与校验规则、工作流级与全局插件的优先级/回退逻辑、一个可运行的 Python 插件端到端示例以及插件失败重试、Re-Queue 等运行时行为。功能背景为什么需要工作流级 Executor Plugin 配置Argo Workflows 的 Executor Plugin 机制允许用户以自定义 HTTP 服务以 sidecar 容器形式运行在 Agent Pod 中扩展工作流的模板执行能力——例如接入 Slack 通知、第三方 CI 系统或内部任务平台。在 v4.1.0 之前Executor Plugin 只能全局配置在 Workflow Controller 的 ConfigMap 中通过ExecutorPlugin类型的 ConfigMap 声明所有工作流共享同一组插件。这种全局模式存在明显的局限性插件属于集群/命名空间级共享资源不同工作流无法按需选择不同的插件集合插件的启用需要修改控制器 ConfigMap 并依赖控制器重新发现变更影响面大无法在 CI/CD 流水线中以工作流清单manifest的形式将插件与工作流一起版本化、一起分发。工作流级 Executor Plugin 配置正是为了解决这些问题而设计插件定义可以直接内嵌在Workflow的spec.executorPlugins字段中随工作流一起提交、一起演进。该特性在 v4.1.0 的发布特性文档.features/released/v4.1.0/15234-argo-workflow-level-executor-plugin-configuration.md中正式宣告官方主文档 docs/executor_plugins.md 也同步更新了对应配置说明。功能开关两个独立的环境变量Executor Plugins 默认是禁用的disabled by default需要显式开启。官方文档docs/executor_plugins.md给出了两个相互独立、可单独或同时开启的开关环境变量作用ARGO_EXECUTOR_PLUGINStrue启用配置在控制器 ConfigMap 中的全局Executor PluginsARGO_WORKFLOW_LEVEL_EXECUTOR_PLUGINStrue允许使用直接写在Workflow spec中的 Executor Plugin 配置且优先级高于全局配置这两个选项相互独立可以只开全局插件、只开工作流级插件或者两者同时开启。在 Deployment 中启用在 Workflow Controller 的 Deployment 中为容器添加环境变量apiVersion: apps/v1 kind: Deployment metadata: name: workflow-controller spec: template: spec: containers: - name: workflow-controller env: - name: ARGO_EXECUTOR_PLUGINS value: true - name: ARGO_WORKFLOW_LEVEL_EXECUTOR_PLUGINS value: true使用 Helm Chart 时的配置使用官方 Helm chartargo-helm 的argo-workflowschart时在values.yaml中追加controller: extraEnv: - name: ARGO_EXECUTOR_PLUGINS value: true - name: ARGO_WORKFLOW_LEVEL_EXECUTOR_PLUGINS value: true源码中的实现对应从源码看这两个开关在控制器侧有着清晰的落点命令行入口 cmd/workflow-controller/main.go 定义了两个布尔 flag--executor-plugins对应ARGO_EXECUTOR_PLUGINS与--workflow-level-executor-plugins对应ARGO_WORKFLOW_LEVEL_EXECUTOR_PLUGINS二者均默认false。workflow/controller/controller.go 的NewWorkflowController构造函数接收executorPlugins与workflowLevelExecutorPlugins两个布尔参数前者非空时初始化wfc.executorPlugins映射namespace → name → plugin后者保存在控制器的enableWorkflowLevelExecutorPlugins字段中controller.go。当工作流声明了executorPlugins而控制器未开启对应开关时会在 workflow/controller/agent.go 直接报错提示设置ARGO_WORKFLOW_LEVEL_EXECUTOR_PLUGINStrue。spec.executorPlugins字段结构与校验规则工作流级 Executor Plugin 通过WorkflowSpec.ExecutorPlugins字段声明其 API 注释pkg/apis/workflow/v1alpha1/workflow_types.go明确了三条核心语义该字段仅在ARGO_WORKFLOW_LEVEL_EXECUTOR_PLUGINS特性开关开启时生效如果该字段包含一个或多个 Executor Plugin控制器 ConfigMap 中的 Executor Plugin 配置将被忽略对本工作流而言如果该字段为空或未设置控制器回退到 ConfigMap 配置。字段对应的 Go 类型定义位于 workflow_types.gotype ExecutorPlugin struct { metav1.ObjectMeta json:metadata protobuf:bytes,2,opt,namemetadata Spec ExecutorPluginSpec json:spec protobuf:bytes,1,opt,namespec } type ExecutorPluginSpec struct { Sidecar ExecutorPluginSidecar json:sidecar protobuf:bytes,1,opt,namesidecar } type ExecutorPluginSidecar struct { // AutomountServiceAccountToken 启用 service account token 挂载 // service account 必须命名为 plugin-name-executor-plugin。 AutomountServiceAccountToken bool json:automountServiceAccountToken,omitempty // Container 定义 sidecar 的 Kubernetes 容器规范。 Container apiv1.Container json:container }可见工作流级插件的结构与全局ExecutorPluginConfigMap 中的spec.sidecar结构一致一个metadata名称 一个spec.sidecar.container完整的 Kubernetes 容器定义。也就是说全局插件能表达的容器能力镜像、命令、参数、端口、环境变量、资源、安全上下文等在工作流级全部可用。校验逻辑从 spec 到运行时插件的转换WorkflowSpec.AsExecutorPluginSpec()workflow_types.go负责把 spec 中的插件声明转换为控制器内部的插件模型并执行校验插件名称metadata.name为必填若为空返回executor plugin metadata name is mandatory错误每个插件的sidecar会调用sidecar.Validate()进行结构校验校验通过后Plugin.Spec.Sidecar含AutomountServiceAccountToken与Container被逐个收集成插件列表返回。之后 agent.go 的 getExecutorPlugins 将转换后的插件逐一展开为 Agent Pod 的 sidecar 容器与卷每个插件容器会挂载只读的/var/run/argo卷SubPath使用容器名保证只挂载该插件自己的 token并仅在AutomountServiceAccountToken为 true 时额外挂载{plugin-name}-executor-plugin的 service account token 卷。完整示例在 Workflow Spec 内声明一个 Python 插件官方仓库在 examples/workflow-level-executor-plugin.yaml 提供了一个完整、可直接运行的示例插件以 Python 内联脚本形式内嵌在工作流清单中监听4356端口收到workflowLevelHello的 plugin 请求时返回 Hello from a workflow-level executor plugin!。示例解析# workflow-controller 必须以 ARGO_WORKFLOW_LEVEL_EXECUTOR_PLUGINStrue 启动 apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: generateName: workflow-level-executor-plugin- labels: workflows.argoproj.io/no-test: environment spec: entrypoint: main executorPlugins: - metadata: name: workflow-level-hello-executor-plugin spec: sidecar: container: name: workflow-level-hello-executor-plugin image: python:alpine3.23 command: - python - -c args: - | import json from http.server import BaseHTTPRequestHandler, HTTPServer class Plugin(BaseHTTPRequestHandler): def args(self): return json.loads(self.rfile.read(int(self.headers.get(Content-Length)))) def reply(self, reply): self.send_response(200) self.end_headers() self.wfile.write(json.dumps(reply).encode(UTF-8)) def unsupported(self): self.send_response(404) self.end_headers() def do_POST(self): if self.path /api/v1/template.execute: args self.args() if workflowLevelHello in args[template].get(plugin, {}): self.reply({ node: { phase: Succeeded, message: Hello from a workflow-level executor plugin! } }) else: self.reply({}) else: self.unsupported() if __name__ __main__: httpd HTTPServer((, 4356), Plugin) httpd.serve_forever() ports: - containerPort: 4356 resources: limits: cpu: 200m memory: 64Mi requests: cpu: 100m memory: 32Mi securityContext: allowPrivilegeEscalation: false capabilities: drop: - ALL readOnlyRootFilesystem: true runAsNonRoot: true templates: - name: main plugin: workflowLevelHello: {}运行后main模板中的plugin: {workflowLevelHello: {}}会触发 executor 向该 sidecar 发送template.executeRPC插件返回Succeeded工作流顺利完成。与全局插件方式的对比对照 docs/executor_plugins.md 中全局插件的工作流argo executor-plugin build .生成 ConfigMap →kubectl apply→ 控制器日志出现Executor plugin added工作流级方式有两点显著不同无需构建与安装步骤插件直接以工作流清单内嵌的容器定义存在省去了argo executor-plugin build和 ConfigMap 下发流程作用域为本工作流插件声明不会注册到控制器日志中不会出现Executor plugin added也不会影响其他工作流。当然全局方式仍然适用于组织级共享插件的场景两种方式可按需混用同时开启两个开关。优先级与回退工作流级覆盖全局根据 docs/executor_plugins.md 与类型注释二者的解析逻辑可以总结为if spec.executorPlugins 非空: 使用工作流级插件忽略 ConfigMap 中的全局插件 若控制器未开启 ARGO_WORKFLOW_LEVEL_EXECUTOR_PLUGINS - 报错 else: 回退到 ConfigMap 中的全局插件需 ARGO_EXECUTOR_PLUGINStrue该逻辑在 agent.go 的 getExecutorPlugins 中有清晰实现先调用AsExecutorPluginSpec()得到wFPluginslen(wFPlugins) 0即为从工作流取插件分支——此时若enableWorkflowLevelExecutorPlugins为 false 直接报错否则展开工作流级插件为 sidecar。反之工作流未声明插件才遍历controller.executorPlugins即控制器从 ConfigMap 发现并缓存的全局插件加载逻辑见 controller.go。需要注意一个容易误解的点覆盖发生在插件来源层面而非同名插件合并。只要工作流声明了至少一个插件该工作流就不会再加载任何 ConfigMap 中的全局插件。全局插件名称冲突的处理规则仅工作流所在命名空间的插件被加载参见 docs/executor_plugins.md 的 Discovery 小节。插件运行时行为认证、失败与 Re-Queue工作流级插件与全局插件共享同一套运行时契约executor_swagger.md 描述了 RPC HTTP API因此以下行为对两种插件一致编写工作流级插件时同样需要遵循认证与路径约定插件只需实现需要的方法如template.execute路径即 RPC 方法名请求的Authorization头必须与/var/run/argo/token中的值一致否则应返回403插件会因 token 挂载方式不同而被注入相应 token见上文getExecutorPluginComponents请求体包含模板的输入参数响应体可包含节点的结果phase、message、outputs等响应{}表示该插件无法执行此 Plugin 模板例如 Slack 插件遇到 Tekton 模板。端口选择建议端口可任意但不能与其他 Executor Plugin 冲突避免使用 80、443、8080、8081、8443 等常见端口。若计划发布插件请选择 10000 以下的随机端口并提交 PR 加入插件目录否则使用大于 10000 的端口。失败语义与重试docs/executor_plugins.md 明确定义了失败分类错误类型语义连接/socket 错误瞬态transient重试超时瞬态重试404方法不受支持同一工作流内不再调用该方法503瞬态重试其他 4xx/5xx致命fatal导致步骤失败Re-Queue长任务场景若插件启动了一个长任务、无法立即完成可返回Running/Pending状态并给出重新入队时间{ node: { phase: Running, message: Long-running task started }, requeue: 2m }上述示例中任务将在 2 分钟后被重新入队template.execute再次被调用。资源与安全工作流级插件的强制约束全局 Executor Plugin 在 docs/executor_plugins.md 中强调resources与securityContext是强制的避免插件滥用内存或默认以 root 运行工作流级插件同样建议遵循这一约束。示例中的安全基线securityContext: allowPrivilegeEscalation: false capabilities: drop: - ALL readOnlyRootFilesystem: true runAsNonRoot: true resources: requests: cpu: 100m memory: 32Mi limits: cpu: 200m memory: 64Mi此外若插件需要与第三方系统交互密钥不应硬编码在清单中应通过secretKeyRef注入环境变量见 docs/executor_plugins.md 的 Secrets 小节例如env: - name: URL valueFrom: secretKeyRef: name: slack-executor-plugin key: URL排查与调试查看插件日志Executor Plugin 运行在 Agent Pod 的 sidecar 中日志位于kubectl -n argo logs ${agentPodName} -c hello-executor-plugin查看控制器是否加载了全局插件控制器日志中出现Executor plugin added表示全局插件注册成功工作流级插件不会产生该日志。工作流级插件被忽略或报错请检查控制器环境变量ARGO_WORKFLOW_LEVEL_EXECUTOR_PLUGINS是否设置为true以及spec.executorPlugins中每个插件的metadata.name是否非空且spec.sidecar.container结构合法——这两项分别在 agent.go 与 workflow_types.go 中校验。参考特性宣告.features/released/v4.1.0/15234-argo-workflow-level-executor-plugin-configuration.md官方配置文档docs/executor_plugins.md官方示例examples/workflow-level-executor-plugin.yaml类型定义与校验pkg/apis/workflow/v1alpha1/workflow_types.goexecutorPlugins字段、workflow_types.go类型结构、workflow_types.goAsExecutorPluginSpec控制器实现workflow/controller/controller.go构造参数、workflow/controller/agent.go插件解析与 sidecar 展开命令行开关cmd/workflow-controller/main.goRPC API 契约docs/executor_swagger.md插件目录docs/plugin-directory.md【免费下载链接】argo-workflowsWorkflow Engine for Kubernetes项目地址: https://gitcode.com/gh_mirrors/ar/argo-workflows创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考