亲眼看工作流真的在跑
本实验运行在真实的 Argo Workflows 上
VM 内实际运行着工作流控制器、argo-server 和 artifact 存储(minio)。 提交 workflow 后,控制器会启动 Pod、推进步骤、在失败时重试并留下日志。
前一个模块的 workflow 实验运行在假集群中。它能接收对象,但由于**没有控制器, 什么也不会发生。**你只能练习编写 YAML,却无法确认它是否真的能运行。
首次启动大约需要 4 分钟。
已准备的内容
네임스페이스 argo 권한도 붙어 있어 바로 낼 수 있습니다
CLI argo argo submit / list / get / logs
아티팩트 저장소 minio 단계 사이에 파일을 주고받습니다
미리 받은 이미지 busybox:1.36 · alpine:3.20
目标
从 workflow 骨架到失败处理位置,全部通过真实运行来确认。
步骤
- 运行一个 workflow,并把结果保存到
/root/capa/run.txt。 - 用 DAG 创建依赖关系,并把并行运行的证据保存到
/root/capa/dag.txt。 - 传入参数、接收结果,并保存到
/root/capa/params.txt。 - 把 artifact 传给下一步,并保存到
/root/capa/artifacts.txt。 - 使用
retryStrategy实际触发重试,并保存到/root/capa/retry.txt。 - 确认
onExit在失败时也会运行,并保存到/root/capa/exit.txt。 - 创建可复用的
WorkflowTemplate,并保存到/root/capa/template.txt。 - 在
/root/capa/report.md中写入workflows_run=、retry_attempts=、exit_ran=yes三行及说明。
参考
- 使用
argo submit -n argo <파일> --wait提交并等待结束。 - 使用
argo get -n argo @latest查看各步骤状态,使用argo logs -n argo @latest查看日志。 - 每一步有 90 秒。请把
sleep设置得足够短,使每个 workflow 都能在时限内结束。 - 常见错误:
entrypoint指向的名称不在templates中,此时 workflow 根本无法启动。 - 常见错误:给 DAG 的起始 node 设置
dependencies,它永远无法满足依赖,会一直等待。
让它真实运行
运行一个 workflow,并把结果保存到 /root/capa/run.txt。
用 argo submit --wait 提交,结束后通过 argo get 和 kubectl get pod 确认。
依赖关系决定顺序
用 DAG 创建依赖关系,并把并行运行的证据保存到 /root/capa/dag.txt。
没有 dependencies 的 task 会同时开始。请比较它们的启动时间。
传递并接收值
传入参数、接收结果,并保存到 /root/capa/params.txt。
可通过 outputs.parameters 的 valueFrom.path 读取文件,或把 script template 的标准输出作为 result 接收。
把文件传给下一步
把 artifact 传给下一步,并保存到 /root/capa/artifacts.txt。
用 outputs.artifacts 输出,再通过 inputs.artifacts 的 from 接收。文件会经过存储服务。
失败后再次尝试
使用 retryStrategy 实际触发重试,并保存到 /root/capa/retry.txt。
retryStrategy.limit 表示重试次数,不包含第一次尝试。
失败时也会运行的位置
确认 onExit 在失败时也会运行,并保存到 /root/capa/exit.txt。
onExit 即使在 workflow 失败时也会运行。可通过 {{workflow.status}} 获取结果。
复用定义
创建可复用的 WorkflowTemplate,并保存到 /root/capa/template.txt。
创建 WorkflowTemplate,再用 templateRef 引用它。
总结学到的内容
在 /root/capa/report.md 中写入 workflows_run=、retry_attempts=、exit_ran=yes 三行及说明。
写入 workflows_run=、retry_attempts=、exit_ran=yes 三行及说明。