云原生DevOps运维微服务【免费下载链接】kubevelaThe Modern Application Platform.项目地址https://gitcode.com/gh_mirrors/ku/kubevela点击查看免费下载本指南以 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 就绪后安装 OpenKruiseapiVersion: 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 环境。这需要三类定义协同工作定义类型作用env-bindingPolicy策略定义每个环境的配置补丁config patch与放置策略placement strategydeploy2envWorkflowStep工作流步骤选择使用哪个策略、部署到哪个环境suspendWorkflowStep工作流步骤暂停工作流等待人工验证确认3.2 完整示例multi-env-demoapiVersion: 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该示例的关键设计设置一个env-binding策略其中定义了两个环境。每个环境内分别定义了本环境专属的配置补丁patch与放置策略placement。应用运行时触发如下工作流第一步选择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.PlacementEnvPlacement放置规则包含ClusterSelector按集群标签选择集群与NamespaceSelector按名称或标签选择 NamespaceEnvConfig.PatchEnvPatch环境级补丁其Components字段可对指定组件进行属性覆盖EnvComponentPatch还支持Traits字段并可通过Disable: true在特定环境禁用某个 traitEnvConfig.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。它支持三个参数policyenv-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-bindingdeploy2env方案仍完整保留在文档与历史实现中是理解 KubeVela 多环境模型演进的最佳入口。四、附录使用 Terraform 创建 Kubernetes 集群环境初始化中最重的一类资源是 Kubernetes 集群本身。文档给出了在阿里云上使用 Terraform 自动创建集群并注册进 KubeVela 的完整方案。整个过程分为两步。4.1 第一步配置 Terraform Alibaba Provider首先通过 Application 部署一个 raw 类型的Provider组件配置阿里云凭据凭据来源为vela-system命名空间下的 Secretalibaba-account-credsapiVersion: 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然后依次执行depends-on-app等待 Provider 应用terraform-alibaba就绪depends-on-app等待集群管理组件ocm-cluster-manager就绪create-ack步骤根据ack-worker组件创建集群并将连接信息connInfo输出到outputsregister-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-appapply-application描述环境资源的依赖与安装顺序Operator、CRD、共享服务均可作为环境模块独立初始化发布用env-binding策略或演进后的topology/override策略按环境差异化渲染与放置用deploy2envsuspend实现dev 验证 → 人工审批 → prod 上线的受控发布流基础设施用 Terraform 类型组件自动创建云上集群并通过register-cluster将其纳入多集群管理配合标签选择器完成环境归属。如需深入源码与更多示例可继续阅读环境设计文档、depends-on-app 内置定义、depends-on-app 使用示例、env-binding 类型定义、工作流步骤生成器 以及 多集群 provider 实现。赞分享云原生DevOps运维微服务【免费下载链接】kubevelaThe Modern Application Platform.项目地址https://gitcode.com/gh_mirrors/ku/kubevela点击查看免费下载相关推荐openUBMC本地环境初始化实战指南openUBMC本地环境初始化实战指南 本文详细介绍了在Ubuntu 24.04系统上搭建openUBMC开发环境的完整流程包括系统要求与准备、init.py构建工具嵌入式JHipster环境搭建与项目初始化实战指南JHipster环境搭建与项目初始化实战指南 本文是一份全面的JHipster全栈开发平台环境搭建与项目初始化实战指南。详细介绍了JHipster的系统环境要求代码生成开发工具后端前端React Native Windows开发环境搭建与项目初始化实战指南React Native Windows开发环境搭建与项目初始化实战指南 本文是一份详细的React Native Windows开发环境配置与项目创建实战指南跨平台前端创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考