云原生容器编排工作流自动化任务调度后端【免费下载链接】argo-workflowsWorkflow Engine for Kubernetes项目地址https://gitcode.com/gh_mirrors/ar/argo-workflows点击查看免费下载导读在 Argo Workflows 中并非所有 workflow executors 都能从容器的镜像基础层base layer例如/tmp直接收集输出 artifacts 与 parameters一旦为 Workflow Pod 配置了 security context这一限制会更加明显。本指南将说明这一约束的成因并给出通过挂载emptyDir卷绕开限制的完整可运行配置同时结合源码解释输入/输出 artifacts 在底层是如何与 emptyDir 交互的帮助你在实战中正确设计 Workflow 的卷与输出路径。emptyDir 为什么是输出 artifacts 的必需品Argo Workflows 的 executor如 docker、kubelet、emissary 等负责在任务容器完成后收集输出 artifacts 和 parameters。问题的关键在于输出 artifacts/parameters 的读取位置executor 需要读取容器内用户指定的路径例如/tmp/result.txt或/mnt/out/hello_world.txt。当该路径位于容器的可写层基础层时不同 executor 的收集能力并不一致——部分 executor 无法从基础层提取文件。安全上下文的叠加影响当你按照 workflow-pod-security-context.md 为 Pod 配置runAsNonRoot、非 root 用户或受限的 Pod Security Standards 时executor 对基础层文件的访问权限进一步受限无法从基础层获取输出的可能性会明显升高。这也是该文档特别提醒如果你用 security context 运行 workflow pods很可能无法从基础层获取输出 artifacts/parameters的原因。绕开这一约束最直接、最轻量的办法就是把输出写入一个显式挂载的卷而不是镜像的基础层。emptyDir卷随 Pod 生命周期创建、无需预先申请 PVC、不依赖任何存储驱动因此是首选方案。注意这一约束仅针对输出 artifacts/parameters。输入 artifacts/parameters 如需中转系统会自动为其挂载一个 emptyDir详见下文源码解析无需用户手动处理。实战挂载 emptyDir 输出卷的完整配置原文档给出的示例展示了一个典型的输出场景任务把cowsay的输出同时写到标准输出和一个位于 emptyDir 卷中的文件再从该文件生成输出 parameterapiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: generateName: empty-dir- spec: entrypoint: main templates: - name: main container: image: argoproj/argosay:v2 command: [sh, -c] args: [cowsay hello world | tee /mnt/out/hello_world.txt] volumeMounts: - name: out mountPath: /mnt/out volumes: - name: out emptyDir: { } outputs: parameters: - name: message valueFrom: path: /mnt/out/hello_world.txt拆解这份配置的三个关键点声明卷在模板或 Workflow 顶层的volumes中声明名为out的卷emptyDir: {}即表示使用默认介质通常是节点的本地磁盘。Kubernetes 还支持通过emptyDir.medium: Memory使用内存文件系统、通过sizeLimit限制容量Argo Workflows 完全透传这些字段。挂载卷在容器的volumeMounts中将out挂载到/mnt/out。务必保证输出路径/mnt/out/hello_world.txt位于该挂载点之下而不是默认的/tmp。声明输出在outputs.parameters中通过valueFrom.path指向卷内的文件executor 即可从卷中读取内容并写入输出 parameter。你还可以参考仓库中的真实示例 examples/volumes-emptydir.yaml它使用alpine:3.23镜像验证 emptyDir 是否真正挂载成功。该示例特意检查/proc/mounts而不是mount命令因为 busybox 的mount读取/etc/mtab在存在镜像卷例如 init-less pod时会漏掉 kubelet 创建的挂载点而/proc/mounts是内核提供的挂载真相来源apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: generateName: volumes-emptydir- spec: entrypoint: volumes-emptydir-example volumes: - name: workdir emptyDir: {} templates: - name: volumes-emptydir-example container: image: alpine:3.23 command: [/bin/sh, -c] args: [ if grep -q /mnt/vol /proc/mounts; then echo \Volume mounted and found\; else echo \Not found\; exit 1; fi ] volumeMounts: - name: workdir mountPath: /mnt/vol这种写文件 → 检查挂载 → 声明输出的组合是排查 emptyDir 输出问题时的有效手段如果挂载失败容器会以非零退出码结束Workflow 会立即报错而不是等到收集阶段才发现路径不可读。输入 Artifacts 的自动 emptyDir 挂载源码级解析原文档强调输入 artifacts/parameters 如果需要会自动挂载到 empty-dir。这一行为在 workflow/controller/workflowpod.go 中有完整实现常量inputArtifactsVolumeName input-artifactsworkflowpod.go定义了系统内部使用的卷名函数addInputArtifactsVolumesworkflowpod.go在模板存在输入 artifacts 时会构造一个EmptyDir卷追加到 Pod 的volumes并把它挂载到 init 容器、wait/executor 容器以及主容器上。从源码结构看有两种挂载策略传统legacy模式对每个输入 artifact以SubPath: art.Name的方式把共享 emptyDir 挂载到art.Path指定的位置相当于为每个 artifact 建立独立的 bind mountinit-less 模式由于主容器与 supervisor 并发启动kubelet 会在 supervisor 写入文件前把每个 SubPath 预创建为空目录导致 SubPath 方案失效因此改为把整个input-artifacts卷挂载到common.ExecutorArtifactBaseDir即/argo/inputs/artifacts见 workflow/common/common.go再由 emissary executor 在容器就绪后通过符号链接把每个 artifact 放入用户指定路径。另外workflow/executor/executor.go 中 executor 还会检查 artifact 路径是否与共享的 input-artifact emptyDir 重叠避免把主容器内写回的数据与 emptyDir 中的原始输入混淆——这也说明输入/输出与 emptyDir 的交互在控制器与 executor 两侧都有对应的防御逻辑。输出 Artifacts 如何从 emptyDir 卷中收集源码级解析对于输出侧控制器同样有专门的处理逻辑函数addOutputArtifactsVolumesworkflowpod.go会把主容器的全部volumeMounts镜像到 wait sidecar 与 artifact-plugin sidecar镜像挂载点统一放在common.ExecutorMainFilesystemDir即/mainctrfs见 workflow/common/common.go之下并强制ReadOnly: false以兼容重叠挂载这样对于产生在 PVC、emptyDir 等挂载卷中的输出 artifactswait 容器可以直接从volumeMount读取文件并上传而不必依赖docker cp之类从基础层提取文件的手段——这正是把输出放进卷里就能可靠收集的底层原理。换句话说你手动挂载 emptyDir 并声明输出路径实际上是复用了控制器为 wait 容器准备的这一套卷镜像机制主容器写入卷的数据wait 容器在/mainctrfs下能看到完全一致的视图从而绕开了 executor 无法读取基础层的限制。使用 emptyDir 的注意事项输出路径必须落在挂载点之下valueFrom.path指向的文件必须位于volumeMounts.mountPath之内否则文件写入了基础层问题依旧存在。数据生命周期与 Pod 绑定emptyDir卷随 Pod 删除而清空只适合 Pod 内部的数据中转如任务输出、临时文件、容器间共享不适合跨 Pod 或跨 Workflow 持久化——需要持久化时应改用 PVC 或对象存储 artifact。路径重叠问题如果某个输入 artifact 的path恰好是某个已挂载卷路径的祖先或重叠控制器会检测到重叠并跳过 emptyDir 挂载见 workflowpod.go 的FindOverlappingVolume检查init-less 模式下若art.Path是某卷挂载点的祖先配置会直接报CodeBadRequest拒绝workflowpod.go。设计路径时应避免 artifact 路径与卷挂载路径互相包含。安全性不受影响emptyDir只是绕开从基础层读取的限制并不降低 Pod 的隔离性在配置了 security context 的非 root 场景下需要确保容器用户对挂载点有写权限例如通过securityContext.fsGroup或卷的权限设置。总结与延伸阅读emptyDir是 Argo Workflows 中解决输出 artifacts/parameters 无法从基础层收集这一约束的轻量级标准方案在volumes中声明emptyDir在容器中挂载它并把outputs的valueFrom.path指向卷内路径即可。配合 workflowpod.go 中addInputArtifactsVolumes与addOutputArtifactsVolumes的实现你可以确认输入侧已由系统自动处理 emptyDir而输出侧则依赖 wait 容器的卷镜像机制完成可靠收集。若需要进一步了解相关主题可继续阅读仓库中的以下资料examples/volumes-emptydir.yamlemptyDir 挂载与挂载验证的真实示例docs/workflow-executors.md不同 executor 的能力差异docs/workflow-pod-security-context.mdPod 安全上下文配置及其影响workflow/controller/workflowpod.goWorkflow Pod 构建与卷挂载的核心实现workflow/executor/executor.goexecutor 侧的 artifact 路径与 emptyDir 重叠检查。赞分享云原生容器编排工作流自动化任务调度后端【免费下载链接】argo-workflowsWorkflow Engine for Kubernetes项目地址https://gitcode.com/gh_mirrors/ar/argo-workflows点击查看免费下载相关推荐Argo Workflows 常见问题解决方案Argo Workflows 常见问题解决方案 1. 项目基础介绍与主要编程语言 Argo Workflows 是一个开源的容器原生工作流引擎用于在 Kube云原生容器编排工作流自动化任务调度后端FairSeq序列建模框架多模态Transformer架构与分布式训练技术深度解析FairSeq序列建模框架多模态Transformer架构与分布式训练技术深度解析 Facebook AI Research开发的FairSeq序列建模工具包云原生容器编排工作流自动化任务调度后端Zero to Emacs and Org-roam用Org-roam-ui把笔记变成知识图谱一眼看穿你的笔记关联Zero to Emacs and Org roam用Org roam ui把笔记变成知识图谱一眼看穿你的笔记关联 Zero to Emacs and Or云原生容器编排工作流自动化任务调度后端上一篇Terraforming用户手册从安装到部署的完整操作指南下一篇Hoodie.dev客户端API终极指南10个关键功能让前端开发更简单创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考