企业官网建设流程全解析

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

本指南以 KubeVela 仓库中的设计文档 design/vela-core/environment.md 为核心，系统讲解如何使用 KubeVela 的 Application、Workflow 与 Policy 完成"环境"这一逻辑概念的初始化、共享资源编排，以及跨 dev/prod 多环境的应用滚动发布。读完本文，你将掌握环境资源分类模型、depends-on-app与apply-application的依赖编排用法、env-binding策略与deploy2env工作流步骤的组合实战，以及基于 Terraform 自动创建并注册 Kubernetes 集群的完整流程。

一、背景：环境到底是什么

在应用开发团队中，通常需要预先初始化若干供开发者部署应用的共享环境。例如一个团队会初始化两个环境：用于测试应用的dev环境，以及用于承载线上流量的prod环境。

环境是一个逻辑概念，它将多个应用共同依赖的通用资源聚合成一个整体。按文档划分，环境中共享的资源至少包含以下四类：

• Kubernetes 集群：不仅包括已存在的集群，也包括在环境初始化过程中需要新建的集群。
• 管理策略（Admin Policies）：生产环境通常会为所有应用部署设置全局策略，例如混沌测试（chaos testing）、SLO 要求、安全扫描、配置错误检测等。
• 系统组件（System Components）：包括安装系统级 Operator 与 CRD，如 FluxCD、KEDA、OpenKruise、共享 Namespace、可观测性组件（Prometheus、Grafana、Loki）、Terraform Controller、KubeFlow Controller 等。
• 共享服务（Shared Services）：环境中包含各类被应用共享的系统服务，例如数据库、缓存、负载均衡器、API 网关等。

从当前仓库的源码结构看，这四类资源恰好与 KubeVela 生态中的组件类型一一对应：Operator/CRD 可通过 helm 或 raw 类型组件安装（见 docs/examples/workflow/depends-on-app/app.yaml 中的 helm 组件示例），共享服务可通过 terraform 类型组件创建，集群本身则通过alibaba-ack等基础设施组件创建（见下文附录）。

环境初始化有一个额外的硬性需求——能够描述环境模块之间的依赖关系。例如dev和prod环境都会依赖一个公共模块，该模块负责安装两个环境都要用到的 Operator。这意味着编排工具必须具备"等待上游初始化完成后再继续"的能力。

二、使用 KubeVela 初始化环境

2.1 核心思想：Application + Workflow 两步编排

要搭建共享资源并描述依赖关系，KubeVela 的设计方案是使用一个 Application，配合两个内置 Workflow 步骤来完成：

• depends-on-app：等待指定 Application 的状态变为 Running 后，当前工作流才继续，用于实现环境模块之间的依赖。
• apply-application：将当前 Application 中声明的所有组件全部应用出去，完成本环境的资源初始化。

一个环境初始化 Application 的骨架如下：

apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: setup-dev-env spec: # 使用 Application 部署构成一个环境的资源 components: - name: <env-component-name> type: <env-component-type> properties: <env-component-props> policies: - name: <env-policy-name> type: <env-policy-type> properties: <env-policy-props> workflow: - name: wait-dependencies # depends-on-app 步骤会等待被依赖应用的状态变为 Running 后再继续 type: depends-on-app properties: name: <application name> namespace: <application namespace> - name: apply-self # apply-application 会应用当前 Application 的所有组件 type: apply-application

工作流执行逻辑：先执行wait-dependencies步骤，等待被依赖的 Application（例如公共 Operator 安装应用）进入 Running 状态；随后执行apply-self步骤，将当前环境的全部组件（集群、策略、系统组件、共享服务）部署出去。这样一个环境就可以"搭积木"式地依赖其他环境模块，形成有向依赖图。

2.2 源码视角：depends-on-app 是如何"等待"的

depends-on-app的内置定义位于 vela-templates/definitions/internal/workflowstep/depends-on-app.cue，其实现逻辑清晰可读：

• 先通过kube.#Read读取指定 namespace 下名为parameter.name的 Application 对象；
• 若读取成功，则通过builtin.#ConditionalWait轮询等待该应用status.status == "running"；
• 若读取失败（应用尚未创建），则尝试读取同名 ConfigMap 中的application键，先kube.#Apply应用其中的模板，再等待其状态变为running。

其参数仅有两个：name（被依赖 Application 的名称）与namespace（被依赖 Application 的命名空间）。一个真实的链式依赖示例见 docs/examples/workflow/depends-on-app/app.yaml：该示例先安装 FluxCD，再通过depends-on-app等待 FluxCD 就绪后安装 OpenKruise：

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

这正是文档所描述的典型场景：dev、prod环境都依赖的公共 Operator 模块（如 FluxCD、KEDA、OpenKruise），可以先作为独立 Application 安装，再由各个环境通过depends-on-app等待其就绪。

三、使用 KubeVela 编排多环境应用发布

3.1 三种定义组合

环境初始化完成后，就可以跨环境部署应用。典型流程是：先把应用部署到 dev 环境，验证工作正常后，最后提升（promote）到 prod 环境。这需要三类定义协同工作：

3.2 完整示例：multi-env-demo

apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: multi-env-demo spec: components: - name: myimage-server type: webservice properties: image: myimage:v1.1 port: 80 policies: - name: my-binding-policy type: env-binding properties: envs: - name: test patch: # 对上述组件做 overlay 补丁 components: - name: myimage-server type: webservice properties: image: myimage:v1.2 port: 80 placement: # 选择部署到哪个集群 clusterSelector: labels: purpose: test - name: prod placement: clusterSelector: labels: purpose: prod workflow: steps: - name: deploy-test-env type: deploy2env properties: policy: my-binding-policy env: test - name: manual-approval type: suspend - name: deploy-prod-env type: deploy2env properties: policy: my-binding-policy env: prod

该示例的关键设计：

1. 设置一个env-binding策略，其中定义了两个环境。每个环境内分别定义了本环境专属的配置补丁（patch）与放置策略（placement）。
2. 应用运行时触发如下工作流：
   • 第一步：选择my-binding-policy策略，并选择策略内部定义的test环境。
   • 第二步：deploy2env步骤加载策略数据，取出test环境的专属配置段；用补丁数据渲染出最终的 Application；依据放置策略选定目标集群；最后将 Application 部署到该集群。
   • 第三步：执行suspend步骤，作为审批闸门（approval gate），工作流在此暂停直到用户完成验证。
   • 第四步：再次执行deploy2env步骤，这次选择prod环境，同样完成补丁渲染、集群选择与最终部署。

注意：test环境通过 patch 将镜像从myimage:v1.1覆盖为myimage:v1.2，而prod环境未定义 patch，因此将使用组件原始定义myimage:v1.1。这展示了 patch 与 placement 在环境维度上的解耦——同一份组件定义，按环境差异化渲染、差异化放置。

3.3 源码视角：env-binding 策略的 API 结构

env-binding策略的类型定义位于 apis/core.oam.dev/v1alpha1/envbinding_types.go，其核心结构如下：

• EnvBindingSpec.Envs：环境列表，每个环境由EnvConfig描述；
• EnvConfig.Name：环境名称；
• EnvConfig.Placement（EnvPlacement）：放置规则，包含ClusterSelector（按集群标签选择集群）与NamespaceSelector（按名称或标签选择 Namespace）；
• EnvConfig.Patch（EnvPatch）：环境级补丁，其Components字段可对指定组件进行属性覆盖；EnvComponentPatch还支持Traits字段，并可通过Disable: true在特定环境禁用某个 trait；
• EnvConfig.Selector：可选，用于限定该环境包含哪些组件。

在文档示例中，placement.clusterSelector.labels的purpose: test/purpose: prod正是 KubeVela 多集群放置的标准用法——通过集群标签而非集群名来声明式选择目标集群。

3.4 源码视角：deploy2env 步骤的自动生成

当用户在 Application 的workflow.steps中显式声明deploy2env步骤时，该步骤会按属性执行；若用户未显式声明任何步骤，KubeVela 的控制器会通过Deploy2EnvWorkflowStepGenerator自动为每个 env-binding 策略中的每个环境生成对应的deploy2env步骤。该生成器实现位于 pkg/workflow/step/generator.go：

// Deploy2EnvWorkflowStepGenerator generate deploy2env workflow steps for all envs in the application type Deploy2EnvWorkflowStepGenerator struct{} func (g *Deploy2EnvWorkflowStepGenerator) Generate(app *v1beta1.Application, existingSteps []wfTypesv1alpha1.WorkflowStep) (steps []wfTypesv1alpha1.WorkflowStep, err error) { if len(existingSteps) > 0 { return existingSteps, nil } for _, policy := range app.Spec.Policies { if policy.Type == v1alpha1.EnvBindingPolicyType && policy.Properties != nil { spec := &v1alpha1.EnvBindingSpec{} if err = json.Unmarshal(policy.Properties.Raw, spec); err != nil { return } for _, env := range spec.Envs { steps = append(steps, wfTypesv1alpha1.WorkflowStep{ WorkflowStepBase: wfTypesv1alpha1.WorkflowStepBase{ Name: "deploy-" + policy.Name + "-" + env.Name, Type: "deploy2env", Properties: util.Object2RawExtension(map[string]string{ "policy": policy.Name, "env": env.Name, }), }, }) } } } return }

可以看到：只要显式声明了步骤（len(existingSteps) > 0），生成器就会跳过；否则自动为策略下每个环境生成形如deploy-<policy>-<env>的步骤，逐一部署到对应环境。

deploy2env步骤本身的内置定义位于 vela-templates/definitions/deprecated/deploy2env.cue，其底层通过op.#ApplyEnvBindApp完成"读取策略 → 计算放置决策 → 渲染补丁后组件 → 应用至目标集群"的完整流程（对应实现见 pkg/workflow/providers/legacy/multicluster/multicluster.cue）。它支持三个参数：

• policy：env-binding 策略名称，默认为空（将使用第一个 env-binding 策略）；
• env：策略中声明的环境名称（必填）；
• parallel：组件是否并行应用，默认为false（串行并等待健康）。

仓库现状说明：从当前仓库源码看，env-binding策略与deploy2env步骤在类型定义（见 envbinding_types.go 中EnvBindingSpec的 "Deprecated" 注释）与 CUE 定义（deploy2env.cue 中"deprecated": "true"标签）中均已被标记为废弃，官方推荐以topology/override策略配合deploy步骤实现同等的多环境放置与差异化配置能力（对应生成逻辑同样位于 pkg/workflow/step/generator.go 的DeployWorkflowStepGenerator）。本文基于设计文档讲解的env-binding+deploy2env方案仍完整保留在文档与历史实现中，是理解 KubeVela 多环境模型演进的最佳入口。

四、附录：使用 Terraform 创建 Kubernetes 集群

环境初始化中最重的一类资源是 Kubernetes 集群本身。文档给出了在阿里云上使用 Terraform 自动创建集群，并注册进 KubeVela 的完整方案。整个过程分为两步。

4.1 第一步：配置 Terraform Alibaba Provider

首先通过 Application 部署一个 raw 类型的Provider组件，配置阿里云凭据（凭据来源为vela-system命名空间下的 Secretalibaba-account-creds）：

apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: terraform-alibaba namespace: vela-system spec: components: - name: default type: raw properties: apiVersion: terraform.core.oam.dev/v1beta1 kind: Provider metadata: namespace: default spec: provider: alibaba region: cn-hongkong credentials: source: Secret secretRef: namespace: vela-system name: alibaba-account-creds key: credentials workflow: - name: wait-dependencies type: depends-on-app properties: name: terraform namespace: vela-system - name: apply-self type: apply-application

注意该应用自身也使用了depends-on-app等待名为terraform的系统组件（即 Terraform Controller）先安装完成，再执行apply-application应用 Provider——这正是本文第二节所讲"环境模块依赖编排"的直接复用。

4.2 第二步：创建并注册 ACK 集群

接着创建一个alibaba-ack类型组件（ACK 即阿里云容器服务 Kubernetes 版），通过writeConnectionSecretToRef将集群连接信息写入ack-connSecret，然后依次执行：

1. depends-on-app等待 Provider 应用terraform-alibaba就绪；
2. depends-on-app等待集群管理组件ocm-cluster-manager就绪；
3. create-ack步骤根据ack-worker组件创建集群，并将连接信息connInfo输出到outputs；
4. register-cluster步骤消费connInfo，把新集群注册进 KubeVela 的 K8s API，同时打上环境标签。

apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: managed-cluster namespace: vela-system spec: components: - name: ack-worker type: alibaba-ack properties: writeConnectionSecretToRef: name: ack-conn namespace: vela-system workflow: steps: - name: wait-dependencies type: depends-on-app properties: name: terraform-alibaba namespace: vela-system - name: wait-dependencies type: depends-on-app properties: name: ocm-cluster-manager namespace: vela-system - name: terraform-ack type: create-ack properties: component: ack-worker outputs: - name: connInfo valueFrom: connInfo - name: register-ack type: register-cluster inputs: - from: connInfo parameterKey: connInfo properties: # 用户应填写 APIServer 的公网地址 hubAPIServer: {{ public network address of APIServer }} env: prod initNameSpace: default patchLabels: purpose: test

整个流程的时序是：先等待依赖的系统组件安装完毕，再创建集群，最后将集群注册到 K8s API。注册时通过patchLabels给集群打上purpose: test之类的标签，使其能被上文第三节env-binding策略中的clusterSelector.labels精确匹配到，从而打通"建集群 → 打标签 → 按标签放置应用"的完整链路。

五、总结

KubeVela 将"环境"实现为一个可编程、可依赖、可复用的逻辑单元：

• 初始化：用 Application +depends-on-app+apply-application描述环境资源的依赖与安装顺序，Operator、CRD、共享服务均可作为环境模块独立初始化；
• 发布：用env-binding策略（或演进后的topology/override策略）按环境差异化渲染与放置，用deploy2env+suspend实现"dev 验证 → 人工审批 → prod 上线"的受控发布流；
• 基础设施：用 Terraform 类型组件自动创建云上集群，并通过register-cluster将其纳入多集群管理，配合标签选择器完成环境归属。

如需深入源码与更多示例，可继续阅读：环境设计文档、depends-on-app 内置定义、depends-on-app 使用示例、env-binding 类型定义、工作流步骤生成器 以及 多集群 provider 实现。

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