云原生DevOps运维微服务【免费下载链接】kubevelaThe Modern Application Platform.项目地址https://gitcode.com/gh_mirrors/ku/kubevela点击查看免费下载depends-on-app是 KubeVela 工作流Workflow内置的应用交付类步骤WorkflowStepDefinition用于在一个 Application 的工作流中声明对另一个 Application 的依赖目标应用已存在时等待其进入running状态不存在时则回退读取同名 ConfigMap 中的应用清单并代为部署从而打通应用编排应用的交付链路。读完本文你将掌握depends-on-app的完整用法、参数语义、底层 CUE 实现原理以及它在真实仓库中的落地示例。一、核心能力等待依赖应用就绪depends-on-app步骤解决的核心问题是KubeVela 中一个应用的工作流需要依赖另一个应用的运行结果例如先部署 FluxCD再基于它安装 Kruise。该步骤的行为可以概括为两条分支目标 Application 已存在步骤持续阻塞直到该 Application 的status.status变为running然后才放行后续步骤目标 Application 不存在KubeVela 会改去读取与 properties 中name、namespace同名的 ConfigMap从中解析出 Application 配置并直接应用到集群同样等待其进入running状态。这种先探测、再兜底的双路径设计使得上层应用既可以等待集群中已存在的应用完成交付也可以在目标应用尚未创建时通过 ConfigMap 把应用清单注入给工作流实现应用的按需拉取与编排。参数一览depends-on-app步骤只接受两个参数定义于 depends-on-app.cue 的parameter段参数类型必填说明namestring是被依赖的 Application 名称同时用于定位同名 ConfigMapnamespacestring是被依赖的 Application / ConfigMap 所在命名空间二、基本用法示例原文档给出的最简示例见 depends-on-app.eg.md如下工作流第一步express-server先等待名为another-app的应用就绪然后才会继续执行后续步骤。apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: first-vela-workflow namespace: default spec: components: - name: express-server type: webservice properties: image: oamdev/hello-world port: 8000 traits: - type: ingress properties: domain: testsvc.example.com http: /: 8000 workflow: steps: - name: express-server type: depends-on-app properties: name: another-app namespace: default行为要点如下步骤会检查集群中是否存在 properties 中name与namespace指定的 Application若应用存在则挂起下一步直到该应用运行完成status.status running若应用不存在KubeVela 将检查同名的 ConfigMap读取其中的 Application 配置并应用到集群随后同样等待其运行完成。仓库中的真实落地示例仓库在 docs/examples/workflow/depends-on-app/app.yaml 提供了一个完整的两步依赖示例先通过depends-on-app等待vela-system命名空间下的fluxcd应用就绪再使用apply-component应用kruise组件——这正是典型的基础组件先行、业务组件随后编排场景apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: kruise namespace: vela-system spec: components: - name: kruise type: helm properties: branch: master chart: ./charts/kruise/v0.9.0 version: * repoType: git url: https://github.com/openkruise/kruise workflow: steps: - name: check-flux type: depends-on-app properties: name: fluxcd namespace: vela-system - name: apply-kruise type: apply-component properties: component: kruise三、ConfigMap 回退机制以数据驱动应用创建当目标 Application 尚不存在时depends-on-app会回退到 ConfigMap。原文档明确了该回退通道的契约ConfigMap 的name和namespace必须与步骤 properties 中的name、namespace一致数据中必须存在键为application的条目其值为待部署 Application 的 YAML 清单。ConfigMap 形式如下apiVersion: v1 kind: ConfigMap metadata: name: myapp namespace: vela-system data: application: app yaml file需要注意这里的 ConfigMap 命名空间与原文档示例中的default可以不同示例中为vela-system只要与步骤 properties 中声明的namespace保持一致即可。application键的值是完整的 Application YAMLKubeVela 会将其解析后直接应用并复用同一条等待 running的判定逻辑保证后续步骤真正拿到的是已经就绪的应用。四、源码级原理CUE 模板如何实现双路径depends-on-app的本质是一个 CUE 编写的 WorkflowStepDefinition其实现位于 vela-templates/definitions/internal/workflowstep/depends-on-app.cue对应的 Helm 渲染产物安装时下发到集群的 CR为 charts/vela-core/templates/defwithtemplate/depends-on-app.yaml。从源码结构可以还原其完整执行逻辑dependsOn: kube.#Read { $params: value: { apiVersion: core.oam.dev/v1beta1 kind: Application metadata: { name: parameter.name namespace: parameter.namespace } } } load: { if dependsOn.$returns.err ! _|_ { configMap: kube.#Read { ... } template: configMap.$returns.value.data[application] apply: kube.#Apply { $params: value: yaml.Unmarshal(template) } wait: builtin.#ConditionalWait { $params: continue: apply.$returns.value.status.status running } } if dependsOn.$returns.err _|_ { wait: builtin.#ConditionalWait { $params: continue: dependsOn.$returns.value.status.status running } } }实现的关键在于利用 CUE 的条件分支if在同一个模板内完成两种状态的处理探测阶段通过kube.#Read读取core.oam.dev/v1beta1的 Application 对象kind: Application名称与命名空间直接取自parameter.name/parameter.namespace回退分支dependsOn.$returns.err ! _|_即读取失败、应用不存在再用kube.#Read读取同名的v1ConfigMap取出data[application]借助encoding/yaml的yaml.Unmarshal将其解析为对象通过kube.#Apply应用到集群等待分支两条路径最终都汇入builtin.#ConditionalWait以目标应用的status.status running作为继续条件——应用存在时直接检查它应用由 ConfigMap 兜底创建时则检查新应用的状态。这种读取失败即回退的模式意味着depends-on-app天然支持两种交付方式并存既能在集群中已有依赖应用时实现纯等待不重复创建也能在依赖缺失时基于 ConfigMap 中的数据自动完成创建是 KubeVela 工作流中应用编排应用能力的典型实现。类似地builtin.#ConditionalWait也被 apply-deployment.cue 等工作流步骤复用用于统一实现条件就绪后再继续的语义。五、使用建议与注意事项命名空间一致性depends-on-app的探测与 ConfigMap 回退都严格基于parameter.name与parameter.namespace请确保这两个值在步骤中与被依赖对象实际所处位置一致ConfigMap 数据键回退场景下 ConfigMap 的data中必须使用固定的application键且值为完整的 Application YAML否则data[application]取值为空无法完成解析与应用就绪判据步骤以status.status running作为放行条件这意味着依赖方最终拿到的依赖应用是已交付完成而非创建中的状态适合作为后续apply-component、apply-object等步骤的前置门槛适用范围本步骤属于Application Delivery类工作流步骤适用于跨应用的前后置依赖编排若你只是想在同一个应用内控制组件顺序应优先使用deploy-components等常规步骤而不是引入跨应用的等待语义。结合 depends-on-app.eg.md、depends-on-app.cue 与 app.yaml 示例 三份材料你可以在自己的 KubeVela 应用中直接复制上述 YAML 骨架将name/namespace替换为目标依赖应用即可快速搭建具备等待 回退创建能力的跨应用交付工作流。赞分享云原生DevOps运维微服务【免费下载链接】kubevelaThe Modern Application Platform.项目地址https://gitcode.com/gh_mirrors/ku/kubevela点击查看免费下载相关推荐gentle-ai 自托管遥测收集器实战指南wire 合约、SQLite 存储与 VictoriaMetrics 部署全解析gentle ai 自托管遥测收集器实战指南wire 合约、SQLite 存储与 VictoriaMetrics 部署全解析 本篇技术指南以 docs/telApache DolphinScheduler Dependent 依赖检查节点实战指南跨工作流、跨周期的依赖编排Apache DolphinScheduler Dependent 依赖检查节点实战指南跨工作流、跨周期的依赖编排 导读 Dependent依赖检查节点是任务调度大数据后端前端OHIF WorkflowStepService为 DICOM 影像应用编排多步骤临床工作流OHIF WorkflowStepService为 DICOM 影像应用编排多步骤临床工作流 在 OHIF 中复杂的多模态影像任务如预临床 4D PET/医疗健康前端音视频上一篇主题图片WebP格式转换everfu/hexo-theme-solitude兼容性与性能平衡策略下一篇如何为I.Ming字体贡献字形开发者参与指南与贡献流程 创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考