企业官网建设流程全解析

• 云原生
• DevOps
• 运维
• 微服务

depends-on-app是 KubeVela 工作流（Workflow）内置的"应用交付"类步骤（WorkflowStepDefinition），用于在一个 Application 的工作流中声明对另一个 Application 的依赖：目标应用已存在时等待其进入running状态，不存在时则回退读取同名 ConfigMap 中的应用清单并代为部署，从而打通"应用编排应用"的交付链路。读完本文，你将掌握depends-on-app的完整用法、参数语义、底层 CUE 实现原理，以及它在真实仓库中的落地示例。

一、核心能力：等待依赖应用就绪

depends-on-app步骤解决的核心问题是：KubeVela 中一个应用的工作流需要依赖另一个应用的运行结果（例如先部署 FluxCD，再基于它安装 Kruise）。该步骤的行为可以概括为两条分支：

1. 目标 Application 已存在：步骤持续阻塞，直到该 Application 的status.status变为running，然后才放行后续步骤；
2. 目标 Application 不存在：KubeVela 会改去读取与 properties 中name、namespace同名的 ConfigMap，从中解析出 Application 配置并直接应用到集群，同样等待其进入running状态。

这种"先探测、再兜底"的双路径设计，使得上层应用既可以等待集群中已存在的应用完成交付，也可以在目标应用尚未创建时，通过 ConfigMap 把应用清单"注入"给工作流，实现应用的按需拉取与编排。

参数一览

depends-on-app步骤只接受两个参数（定义于 depends-on-app.cue 的parameter段）：

二、基本用法示例

原文档给出的最简示例（见 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 YAML，KubeVela 会将其解析后直接应用，并复用同一条"等待 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）在同一个模板内完成两种状态的处理：

1. 探测阶段：通过kube.#Read读取core.oam.dev/v1beta1的 Application 对象（kind: Application），名称与命名空间直接取自parameter.name/parameter.namespace；
2. 回退分支（dependsOn.$returns.err != _|_，即读取失败、应用不存在）：再用kube.#Read读取同名的v1ConfigMap，取出data["application"]，借助encoding/yaml的yaml.Unmarshal将其解析为对象，通过kube.#Apply应用到集群；
3. 等待分支：两条路径最终都汇入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
• 运维
• 微服务