云原生DevOps运维微服务【免费下载链接】kubevelaThe Modern Application Platform.项目地址https://gitcode.com/gh_mirrors/ku/kubevela点击查看免费下载导读X-DefinitionComponentDefinition、TraitDefinition、PolicyDefinition 等是 KubeVela 应用交付能力的核心扩展机制其能力由 CUE 模板定义。本指南以 KubeVela 官方设计文档 design/vela-cli/def_zh.md 为骨架系统讲解vela def命令组的设计动机、CUE 单一描述文件格式以及init、vet、render、apply、get、list、edit、del等命令的完整用法。读完本文你将能够脱离复杂 YAML直接用 CUE 文件完成自定义 Definition 的创建、校验、渲染、部署与日常管理并理解这些命令背后的源码实现原理。背景为什么需要vela def在 KubeVela 中Definition 的核心能力由CUE 格式的 Template定义。CUE 是一种基于 JSON 的语言与 Kubernetes 原生 YAML 并不直接兼容因此将 CUE 模板嵌入 Kubernetes 资源时必须把 CUE 转成字符串。这导致 Definition 在原生kubectl中难以辨识与编辑。例如一个给已有 Component 打标签的 TraitDefinition可通过kubectl get trait labels -n vela-system -o yaml获取其内容如下apiVersion: core.oam.dev/v1beta1 kind: TraitDefinition metadata: annotations: definition.oam.dev/description: Add labels for your Workload. meta.helm.sh/release-name: kubevela meta.helm.sh/release-namespace: vela-system creationTimestamp: 2021-08-05T07:06:58Z generation: 1 labels: app.kubernetes.io/managed-by: Helm name: labels namespace: vela-system resourceVersion: 8423 uid: 51a7f8b1-f14d-4776-b538-02ac54a55661 spec: appliesToWorkloads: - deployments.apps podDisruptive: true schematic: cue: template: patch: spec: template: metadata: labels: {\n\tfor k, v in parameter {\n\t\t\\\(k)\: v\n\t}\n}\nparameter: [string]: string\n status: configMapRef: schema-labels latestRevision: name: labels-v1 revision: 1 revisionHash: fe7fa9da440dc9d3可以看到表达该 Definition 能力核心的spec.schematic.cue.template是一个被转义成字符串的 CUE 内容几乎无法直接阅读与修改。另一方面CUE 语言虽然表达能力强但对许多 Kubernetes 开发者而言仍较新直接上手编写有一定学习成本。为此KubeVela 团队在 CLI 中加入了vela def命令组帮助开发者便捷地设计与使用各类 Definition。从源码看该命令组在 references/cli/def.go 的DefinitionCommandGroup中统一注册覆盖定义的管理、生成与 Go 模块defkit三类操作按types.TagCommandType分组展示帮助信息。设计从YAML 包裹 CUE 字符串到单一 CUE 文件上文提到的CUE 与 YAML 混合风格的 Definition在 KubeVela v1.1 版本中转变为CUE 格式的单一描述文件更加清晰简练地表达 Definition 的内容与能力。上述labels定义可以用以下文件表达// labels.cue labels: { annotations: {} attributes: { appliesToWorkloads: [deployments.apps] podDisruptive: true } description: Add labels for your Workload. labels: {} type: trait } template: { patch: spec: template: metadata: labels: { for k, v in parameter { \(k): v } } parameter: [string]: string }文件分为两部分第一部分labels: {...}表达 Definition 的基本信息包括type类型、description描述、alias别名、labels、annotations注解以及attributes基本属性如appliesToWorkloads、podDisruptive。第二部分template: {...}表达 Definition 的具体能力即 CUE 模板本身。借助vela def命令组用户可以直接与 CUE 文件打交道无需面对复杂的 YAML。在源码中这一双向转换由 pkg/definition/definition.go 的Definition结构体封装unstructured.Unstructured实现ToCUEString()definition.go把集群中的 DefinitionYAML 对象转换为 CUE 字符串将spec中除schematic外的字段归入attributes并格式化spec.schematic.cue.templateFromCUEString()definition.go反向把 CUE 文件解析为 Definition 对象提取import、元数据段与template段经 CUE 编译器编译校验后写入spec.schematic.cue.templateDefinitionTypeToKinddefinition.go定义了component、trait、policy、workload、workflow-step、source六种类型到 Kubernetes Kind 的映射这也是-t参数合法取值的来源。仓库中内置的官方模板如 vela-templates/definitions/internal/trait/annotations.cue同样采用这一格式可作为编写自定义 Definition 的参考。详细文档init初始化新的 Definitionvela def init是一个帮助用户初始化新 Definition 的脚手架命令。基本用法如下vela def init my-trait -t trait --desc My trait description.生成的空白 TraitDefinition 为my-trait: { annotations: {} attributes: { appliesToWorkloads: [] conflictsWith: [] definitionRef: podDisruptive: false workloadRefPath: } description: My trait description. labels: {} type: trait } template: { patch: {} parameter: {} }也可以使用--interactive短参数-i交互式地创建$ vela def init my-comp --interactive Please choose one definition type from the following values: component, trait, policy, workload, scope, workflow-step Definition type: component Definition description: My component definition. Please enter the location the template YAML file to build definition. Leave it empty to generate default template. Definition template filename: Please enter the output location of the generated definition. Leave it empty to print definition to stdout. Definition output filename: my-component.cue Definition written to my-component.cue从 YAML 模板自动转换--template-yaml如果用户创建的 ComponentDefinition 针对的是一个已有 YAML 模板的 Kubernetes 对象如 Deployment可以通过--template-yaml短参数-f完成 YAML 到 CUE 的自动转换。例如下面的my-deployment.yamlapiVersion: apps/v1 kind: Deployment metadata: name: hello-world spec: replicas: 1 selector: matchLabels: app.kubernetes.io/name: hello-world template: metadata: labels: app.kubernetes.io/name: hello-world spec: containers: - name: hello-world image: somefive/hello-world ports: - name: http containerPort: 80 protocol: TCP --- apiVersion: v1 kind: Service metadata: name: hello-world-service spec: selector: app: hello-world ports: - name: http protocol: TCP port: 80 targetPort: 8080 type: LoadBalancer运行vela def init my-comp -t component --desc My component. --template-yaml ./my-deployment.yaml即可得到 CUE 格式的 ComponentDefinitionmy-comp: { annotations: {} attributes: workload: definition: { apiVersion: change me apps/v1 kind: change me Deployment } description: My component. labels: {} type: component } template: { output: { metadata: name: hello-world spec: { replicas: 1 selector: matchLabels: app.kubernetes.io/name: hello-world template: { metadata: labels: app.kubernetes.io/name: hello-world spec: containers: [{ name: hello-world image: somefive/hello-world ports: [{ name: http containerPort: 80 protocol: TCP }] }] } } apiVersion: apps/v1 kind: Deployment } outputs: hello-world-service: { metadata: name: hello-world-service spec: { ports: [{ name: http protocol: TCP port: 80 targetPort: 8080 }] selector: app: hello-world type: LoadBalancer } apiVersion: v1 kind: Service } parameter: {} }生成的模板遵循 KubeVela CUE 模板约定主资源放入output附加资源放入outputs用户参数放入parameter对应 pkg/cue/process 中定义的OutputFieldName、OutputsFieldName、ParameterFieldName。其转换逻辑位于 references/cli/def.go 的buildTemplateFromYAML按---切分多文档 YAML首个文档作为output其余文档按metadata.name归入outputs再通过gocodec解码为 CUE 并写入spec.schematic.cue.template。接下来用户就可以在该文件基础上继续修改例如去掉attributes.workload.definition中的change me占位符。常用参数速查vela def init的核心参数定义于 references/cli/def.go参数短参数说明-t, --type-tDefinition 类型合法值component, trait, policy, workload, workflow-step, source-d, --desc-dDefinition 描述-a, --alias-aDefinition 别名-f, --template-yaml-f用于构建模板的 YAML 文件为空则使用该类型的默认模板-o, --output-o输出路径为空则打印到 stdout-i, --interactive-i是否使用交互式流程-l, --lang-l定义语言合法值cue、goGo 定义基于 defkit 包-p, --provider-p云资源定义所属 Provider仅alibaba, aws, azure, gcp, baidu, tencent, elastic, ucloud, vsphere受支持--git无配置HCL所在的 Git 仓库需配合--provider使用--local无配置HCL的本地文件路径需配合--provider使用--path无配置在 Git 仓库中的路径需配合--git使用交互模式下各字段均有校验逻辑Definition 类型必须是合法值模板文件名必须真实存在可留空使用默认模板。测试用例 references/cli/def_test.go 覆盖了普通模式与交互模式两条路径。此外init还支持--provider生成 Terraform 类型的云资源 ComponentDefinition测试见 references/cli/def_test.go。vet校验 Definition 语法初始化 Definition 文件后可以运行vela def vet my-comp.cue校验其语法是否正确例如少写一个括号也能被识别出来$ vela def vet my-comp.cue Validation succeed.源码中vetNewDefinitionValidateCommand支持一次传入多个文件或目录内部通过validateCueFile调用Definition.FromCUEString完成解析与编译校验references/cli/def.go只有 CUE 语法与 Definition 结构元数据段、template 段缺一不可都合法时才返回Validation succeed.。对于.go文件则先经 goloader 生成 CUE 再校验。对应测试见 references/cli/def_test.go。render / apply渲染与部署 Definition确认 Definition 撰写无误后可用vela def apply将其应用到 Kubernetes 集群vela def apply my-comp.cue --namespace my-namespace如果想预先查看 CUE 文件会被渲染成什么样的 Kubernetes YAML可以使用vela def apply my-comp.cue --dry-run # 或 vela def render my-comp.cue -o my-comp.yamlrender支持.cue与.go两种输入也支持整个目录批量渲染输出格式可用--format在yaml默认与cue之间切换references/cli/def.go。上述my-comp.cue渲染出的 YAML 如下apiVersion: core.oam.dev/v1beta1 kind: ComponentDefinition metadata: annotations: definition.oam.dev/description: My component. labels: {} name: my-comp namespace: vela-system spec: schematic: cue: template: | output: { metadata: name: hello-world spec: { replicas: 1 selector: matchLabels: app.kubernetes.io/name: hello-world template: { metadata: labels: app.kubernetes.io/name: hello-world spec: containers: [{ name: hello-world image: somefive/hello-world ports: [{ name: http containerPort: 80 protocol: TCP }] }] } } apiVersion: apps/v1 kind: Deployment } outputs: hello-world-service: { metadata: name: hello-world-service spec: { ports: [{ name: http protocol: TCP port: 80 targetPort: 8080 }] selector: app: hello-world type: LoadBalancer } apiVersion: v1 kind: Service } parameter: {} workload: definition: apiVersion: apps/v1 kind: Deployment实际应用时的输出示例$ vela def apply my-comp.cue -n my-namespace ComponentDefinition my-comp created in namespace my-namespace.applydefApplyOne内部支持 CUE、YAML、Go 三种输入CUE 文件经FromCUEString解析后设置命名空间若 Definition 已存在则执行Update并提示 created/updated否则Create--dry-run只渲染不落库references/cli/def.go。若文件使用了旧版 CUE 语法在开启EnableCUEVersionCompatibility时还会给出兼容性警告并建议运行vela def upgrade重写文件。对应测试见 references/cli/def_test.go。get / list / edit / delDefinition 的日常管理apply之后虽然可以用原生kubectl确认结果但如前所述 YAML 格式较为复杂。vela def get可以自动把集群中的 Definition 转换回 CUE 格式$ vela def get my-comp -t componentget支持--revisions列出历史修订、--revision获取指定版本从 DefinitionRevision 还原以及--namespace/-n指定命名空间默认vela-system见 references/cli/def.go。vela def list可以查看系统中已安装的所有 Definition可指定命名空间与类型$ vela def list -n my-namespace -t component NAME TYPE NAMESPACE DESCRIPTION my-comp ComponentDefinition my-namespace My component.list在不指定--namespace时会同时搜索当前工作命名空间与系统命名空间并过滤掉当前命名空间不可用的 Definition如受 namespace selector 限制的定义还会在有 Addon 来源的定义时额外展示SOURCE-ADDON列references/cli/def.go。vela def edit同样让用户只面对 CUE 格式命令先将远程 Definition 转为 CUE 写入临时文件调用编辑器修改后再解析回写 Kubernetes$ EDITORvim vela def edit my-comp默认编辑器为vi可通过环境变量EDITOR覆盖若内容未变更会提示definition unchanged避免无谓更新references/cli/def.go。vela def del用于删除相应的 Definition删除前会交互确认$ vela def del my-comp -n my-namespace Are you sure to delete the following definition in namespace my-namespace? ComponentDefinition my-comp: My component. [yes|no] yes ComponentDefinition my-comp in namespace my-namespace deleted.确认输入支持yes/y与no/n非法输入会要求重新回答references/cli/def.go。相关测试覆盖见 references/cli/def_test.go。延伸完整的vela def命令族除上述命令外vela def还提供了更多能力注册于 references/cli/def.govela def upgrade把旧版 CUE 语法自动升级为与目标 KubeVela 版本兼容的写法支持--validate只检测、-o指定输出、--target-version指定目标版本vela def gen-api基于 openapi-generator 从 Definition 生成 Go SDK依赖本机 Dockervela def gen-cue从 Go 代码生成 CUE schema保持 Go 代码与 CUE schema 的一致性vela def gen-doc/doc-gen为 provider 等非标准 Definition 生成文档vela def init-module/apply-module/list-module/validate-module/gen-module面向使用 defkit 包编写 Go 语言 Definition 的模块化管理命令。小结vela def将 KubeVela 中 Definition 的编写—校验—渲染—部署—管理全流程统一到 CUE 单一描述文件之上从根本上规避了 YAML 中 CUE 字符串难以辨识的问题。其底层通过 pkg/definition/definition.go 中Definition结构体的ToCUEString/FromCUEString完成双向格式转换命令实现集中在 references/cli/def.go并有 references/cli/def_test.go 提供覆盖验证。仓库内置的官方模板目录 vela-templates/definitions/internal 是学习 CUE 模板书写规范的最佳参考。建议读者按init 创建 → vet 校验 → render 预览 → apply 部署 → get/edit 管理的顺序实际操作一遍即可掌握自定义扩展 KubeVela 能力的完整闭环。赞分享云原生DevOps运维微服务【免费下载链接】kubevelaThe Modern Application Platform.项目地址https://gitcode.com/gh_mirrors/ku/kubevela点击查看免费下载相关推荐FrankenPHP 高效服务大文件X-Sendfile / X-Accel-Redirect 配置与实战指南FrankenPHP 高效服务大文件X Sendfile / X Accel Redirect 配置与实战指南 在常规 Web 架构中静态文件可以直接交给后端DDD 领域模型中的异常与校验验证位置、守卫子句与错误处理模式全指南DDD 领域模型中的异常与校验验证位置、守卫子句与错误处理模式全指南 本文围绕 Awesome Software Architecture 仓库中 异常与校验云原生DevOps运维微服务Vector 项目文档编写与维护实战指南从 CUE 参考文档生成到 Changelog 与 Release HighlightsVector 项目文档编写与维护实战指南从 CUE 参考文档生成到 Changelog 与 Release Highlights 本指南以 Vector高性可观测性数据工程数据集成日志分析上一篇HTTPie CLI终极指南如何高效批量测试多个API端点下一篇EIP-8131 统一交易内容下限Unified Transaction Content Floor解读以每字节 64 gas 封顶最坏情况区块大小创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
KubeVela `vela def` 实战指南：用 CUE 文件高效编写与管理 X-Definitions
云原生DevOps运维微服务【免费下载链接】kubevelaThe Modern Application Platform.项目地址https://gitcode.com/gh_mirrors/ku/kubevela点击查看免费下载导读X-DefinitionComponentDefinition、TraitDefinition、PolicyDefinition 等是 KubeVela 应用交付能力的核心扩展机制其能力由 CUE 模板定义。本指南以 KubeVela 官方设计文档 design/vela-cli/def_zh.md 为骨架系统讲解vela def命令组的设计动机、CUE 单一描述文件格式以及init、vet、render、apply、get、list、edit、del等命令的完整用法。读完本文你将能够脱离复杂 YAML直接用 CUE 文件完成自定义 Definition 的创建、校验、渲染、部署与日常管理并理解这些命令背后的源码实现原理。背景为什么需要vela def在 KubeVela 中Definition 的核心能力由CUE 格式的 Template定义。CUE 是一种基于 JSON 的语言与 Kubernetes 原生 YAML 并不直接兼容因此将 CUE 模板嵌入 Kubernetes 资源时必须把 CUE 转成字符串。这导致 Definition 在原生kubectl中难以辨识与编辑。例如一个给已有 Component 打标签的 TraitDefinition可通过kubectl get trait labels -n vela-system -o yaml获取其内容如下apiVersion: core.oam.dev/v1beta1 kind: TraitDefinition metadata: annotations: definition.oam.dev/description: Add labels for your Workload. meta.helm.sh/release-name: kubevela meta.helm.sh/release-namespace: vela-system creationTimestamp: 2021-08-05T07:06:58Z generation: 1 labels: app.kubernetes.io/managed-by: Helm name: labels namespace: vela-system resourceVersion: 8423 uid: 51a7f8b1-f14d-4776-b538-02ac54a55661 spec: appliesToWorkloads: - deployments.apps podDisruptive: true schematic: cue: template: patch: spec: template: metadata: labels: {\n\tfor k, v in parameter {\n\t\t\\\(k)\: v\n\t}\n}\nparameter: [string]: string\n status: configMapRef: schema-labels latestRevision: name: labels-v1 revision: 1 revisionHash: fe7fa9da440dc9d3可以看到表达该 Definition 能力核心的spec.schematic.cue.template是一个被转义成字符串的 CUE 内容几乎无法直接阅读与修改。另一方面CUE 语言虽然表达能力强但对许多 Kubernetes 开发者而言仍较新直接上手编写有一定学习成本。为此KubeVela 团队在 CLI 中加入了vela def命令组帮助开发者便捷地设计与使用各类 Definition。从源码看该命令组在 references/cli/def.go 的DefinitionCommandGroup中统一注册覆盖定义的管理、生成与 Go 模块defkit三类操作按types.TagCommandType分组展示帮助信息。设计从YAML 包裹 CUE 字符串到单一 CUE 文件上文提到的CUE 与 YAML 混合风格的 Definition在 KubeVela v1.1 版本中转变为CUE 格式的单一描述文件更加清晰简练地表达 Definition 的内容与能力。上述labels定义可以用以下文件表达// labels.cue labels: { annotations: {} attributes: { appliesToWorkloads: [deployments.apps] podDisruptive: true } description: Add labels for your Workload. labels: {} type: trait } template: { patch: spec: template: metadata: labels: { for k, v in parameter { \(k): v } } parameter: [string]: string }文件分为两部分第一部分labels: {...}表达 Definition 的基本信息包括type类型、description描述、alias别名、labels、annotations注解以及attributes基本属性如appliesToWorkloads、podDisruptive。第二部分template: {...}表达 Definition 的具体能力即 CUE 模板本身。借助vela def命令组用户可以直接与 CUE 文件打交道无需面对复杂的 YAML。在源码中这一双向转换由 pkg/definition/definition.go 的Definition结构体封装unstructured.Unstructured实现ToCUEString()definition.go把集群中的 DefinitionYAML 对象转换为 CUE 字符串将spec中除schematic外的字段归入attributes并格式化spec.schematic.cue.templateFromCUEString()definition.go反向把 CUE 文件解析为 Definition 对象提取import、元数据段与template段经 CUE 编译器编译校验后写入spec.schematic.cue.templateDefinitionTypeToKinddefinition.go定义了component、trait、policy、workload、workflow-step、source六种类型到 Kubernetes Kind 的映射这也是-t参数合法取值的来源。仓库中内置的官方模板如 vela-templates/definitions/internal/trait/annotations.cue同样采用这一格式可作为编写自定义 Definition 的参考。详细文档init初始化新的 Definitionvela def init是一个帮助用户初始化新 Definition 的脚手架命令。基本用法如下vela def init my-trait -t trait --desc My trait description.生成的空白 TraitDefinition 为my-trait: { annotations: {} attributes: { appliesToWorkloads: [] conflictsWith: [] definitionRef: podDisruptive: false workloadRefPath: } description: My trait description. labels: {} type: trait } template: { patch: {} parameter: {} }也可以使用--interactive短参数-i交互式地创建$ vela def init my-comp --interactive Please choose one definition type from the following values: component, trait, policy, workload, scope, workflow-step Definition type: component Definition description: My component definition. Please enter the location the template YAML file to build definition. Leave it empty to generate default template. Definition template filename: Please enter the output location of the generated definition. Leave it empty to print definition to stdout. Definition output filename: my-component.cue Definition written to my-component.cue从 YAML 模板自动转换--template-yaml如果用户创建的 ComponentDefinition 针对的是一个已有 YAML 模板的 Kubernetes 对象如 Deployment可以通过--template-yaml短参数-f完成 YAML 到 CUE 的自动转换。例如下面的my-deployment.yamlapiVersion: apps/v1 kind: Deployment metadata: name: hello-world spec: replicas: 1 selector: matchLabels: app.kubernetes.io/name: hello-world template: metadata: labels: app.kubernetes.io/name: hello-world spec: containers: - name: hello-world image: somefive/hello-world ports: - name: http containerPort: 80 protocol: TCP --- apiVersion: v1 kind: Service metadata: name: hello-world-service spec: selector: app: hello-world ports: - name: http protocol: TCP port: 80 targetPort: 8080 type: LoadBalancer运行vela def init my-comp -t component --desc My component. --template-yaml ./my-deployment.yaml即可得到 CUE 格式的 ComponentDefinitionmy-comp: { annotations: {} attributes: workload: definition: { apiVersion: change me apps/v1 kind: change me Deployment } description: My component. labels: {} type: component } template: { output: { metadata: name: hello-world spec: { replicas: 1 selector: matchLabels: app.kubernetes.io/name: hello-world template: { metadata: labels: app.kubernetes.io/name: hello-world spec: containers: [{ name: hello-world image: somefive/hello-world ports: [{ name: http containerPort: 80 protocol: TCP }] }] } } apiVersion: apps/v1 kind: Deployment } outputs: hello-world-service: { metadata: name: hello-world-service spec: { ports: [{ name: http protocol: TCP port: 80 targetPort: 8080 }] selector: app: hello-world type: LoadBalancer } apiVersion: v1 kind: Service } parameter: {} }生成的模板遵循 KubeVela CUE 模板约定主资源放入output附加资源放入outputs用户参数放入parameter对应 pkg/cue/process 中定义的OutputFieldName、OutputsFieldName、ParameterFieldName。其转换逻辑位于 references/cli/def.go 的buildTemplateFromYAML按---切分多文档 YAML首个文档作为output其余文档按metadata.name归入outputs再通过gocodec解码为 CUE 并写入spec.schematic.cue.template。接下来用户就可以在该文件基础上继续修改例如去掉attributes.workload.definition中的change me占位符。常用参数速查vela def init的核心参数定义于 references/cli/def.go参数短参数说明-t, --type-tDefinition 类型合法值component, trait, policy, workload, workflow-step, source-d, --desc-dDefinition 描述-a, --alias-aDefinition 别名-f, --template-yaml-f用于构建模板的 YAML 文件为空则使用该类型的默认模板-o, --output-o输出路径为空则打印到 stdout-i, --interactive-i是否使用交互式流程-l, --lang-l定义语言合法值cue、goGo 定义基于 defkit 包-p, --provider-p云资源定义所属 Provider仅alibaba, aws, azure, gcp, baidu, tencent, elastic, ucloud, vsphere受支持--git无配置HCL所在的 Git 仓库需配合--provider使用--local无配置HCL的本地文件路径需配合--provider使用--path无配置在 Git 仓库中的路径需配合--git使用交互模式下各字段均有校验逻辑Definition 类型必须是合法值模板文件名必须真实存在可留空使用默认模板。测试用例 references/cli/def_test.go 覆盖了普通模式与交互模式两条路径。此外init还支持--provider生成 Terraform 类型的云资源 ComponentDefinition测试见 references/cli/def_test.go。vet校验 Definition 语法初始化 Definition 文件后可以运行vela def vet my-comp.cue校验其语法是否正确例如少写一个括号也能被识别出来$ vela def vet my-comp.cue Validation succeed.源码中vetNewDefinitionValidateCommand支持一次传入多个文件或目录内部通过validateCueFile调用Definition.FromCUEString完成解析与编译校验references/cli/def.go只有 CUE 语法与 Definition 结构元数据段、template 段缺一不可都合法时才返回Validation succeed.。对于.go文件则先经 goloader 生成 CUE 再校验。对应测试见 references/cli/def_test.go。render / apply渲染与部署 Definition确认 Definition 撰写无误后可用vela def apply将其应用到 Kubernetes 集群vela def apply my-comp.cue --namespace my-namespace如果想预先查看 CUE 文件会被渲染成什么样的 Kubernetes YAML可以使用vela def apply my-comp.cue --dry-run # 或 vela def render my-comp.cue -o my-comp.yamlrender支持.cue与.go两种输入也支持整个目录批量渲染输出格式可用--format在yaml默认与cue之间切换references/cli/def.go。上述my-comp.cue渲染出的 YAML 如下apiVersion: core.oam.dev/v1beta1 kind: ComponentDefinition metadata: annotations: definition.oam.dev/description: My component. labels: {} name: my-comp namespace: vela-system spec: schematic: cue: template: | output: { metadata: name: hello-world spec: { replicas: 1 selector: matchLabels: app.kubernetes.io/name: hello-world template: { metadata: labels: app.kubernetes.io/name: hello-world spec: containers: [{ name: hello-world image: somefive/hello-world ports: [{ name: http containerPort: 80 protocol: TCP }] }] } } apiVersion: apps/v1 kind: Deployment } outputs: hello-world-service: { metadata: name: hello-world-service spec: { ports: [{ name: http protocol: TCP port: 80 targetPort: 8080 }] selector: app: hello-world type: LoadBalancer } apiVersion: v1 kind: Service } parameter: {} workload: definition: apiVersion: apps/v1 kind: Deployment实际应用时的输出示例$ vela def apply my-comp.cue -n my-namespace ComponentDefinition my-comp created in namespace my-namespace.applydefApplyOne内部支持 CUE、YAML、Go 三种输入CUE 文件经FromCUEString解析后设置命名空间若 Definition 已存在则执行Update并提示 created/updated否则Create--dry-run只渲染不落库references/cli/def.go。若文件使用了旧版 CUE 语法在开启EnableCUEVersionCompatibility时还会给出兼容性警告并建议运行vela def upgrade重写文件。对应测试见 references/cli/def_test.go。get / list / edit / delDefinition 的日常管理apply之后虽然可以用原生kubectl确认结果但如前所述 YAML 格式较为复杂。vela def get可以自动把集群中的 Definition 转换回 CUE 格式$ vela def get my-comp -t componentget支持--revisions列出历史修订、--revision获取指定版本从 DefinitionRevision 还原以及--namespace/-n指定命名空间默认vela-system见 references/cli/def.go。vela def list可以查看系统中已安装的所有 Definition可指定命名空间与类型$ vela def list -n my-namespace -t component NAME TYPE NAMESPACE DESCRIPTION my-comp ComponentDefinition my-namespace My component.list在不指定--namespace时会同时搜索当前工作命名空间与系统命名空间并过滤掉当前命名空间不可用的 Definition如受 namespace selector 限制的定义还会在有 Addon 来源的定义时额外展示SOURCE-ADDON列references/cli/def.go。vela def edit同样让用户只面对 CUE 格式命令先将远程 Definition 转为 CUE 写入临时文件调用编辑器修改后再解析回写 Kubernetes$ EDITORvim vela def edit my-comp默认编辑器为vi可通过环境变量EDITOR覆盖若内容未变更会提示definition unchanged避免无谓更新references/cli/def.go。vela def del用于删除相应的 Definition删除前会交互确认$ vela def del my-comp -n my-namespace Are you sure to delete the following definition in namespace my-namespace? ComponentDefinition my-comp: My component. [yes|no] yes ComponentDefinition my-comp in namespace my-namespace deleted.确认输入支持yes/y与no/n非法输入会要求重新回答references/cli/def.go。相关测试覆盖见 references/cli/def_test.go。延伸完整的vela def命令族除上述命令外vela def还提供了更多能力注册于 references/cli/def.govela def upgrade把旧版 CUE 语法自动升级为与目标 KubeVela 版本兼容的写法支持--validate只检测、-o指定输出、--target-version指定目标版本vela def gen-api基于 openapi-generator 从 Definition 生成 Go SDK依赖本机 Dockervela def gen-cue从 Go 代码生成 CUE schema保持 Go 代码与 CUE schema 的一致性vela def gen-doc/doc-gen为 provider 等非标准 Definition 生成文档vela def init-module/apply-module/list-module/validate-module/gen-module面向使用 defkit 包编写 Go 语言 Definition 的模块化管理命令。小结vela def将 KubeVela 中 Definition 的编写—校验—渲染—部署—管理全流程统一到 CUE 单一描述文件之上从根本上规避了 YAML 中 CUE 字符串难以辨识的问题。其底层通过 pkg/definition/definition.go 中Definition结构体的ToCUEString/FromCUEString完成双向格式转换命令实现集中在 references/cli/def.go并有 references/cli/def_test.go 提供覆盖验证。仓库内置的官方模板目录 vela-templates/definitions/internal 是学习 CUE 模板书写规范的最佳参考。建议读者按init 创建 → vet 校验 → render 预览 → apply 部署 → get/edit 管理的顺序实际操作一遍即可掌握自定义扩展 KubeVela 能力的完整闭环。赞分享云原生DevOps运维微服务【免费下载链接】kubevelaThe Modern Application Platform.项目地址https://gitcode.com/gh_mirrors/ku/kubevela点击查看免费下载相关推荐FrankenPHP 高效服务大文件X-Sendfile / X-Accel-Redirect 配置与实战指南FrankenPHP 高效服务大文件X Sendfile / X Accel Redirect 配置与实战指南 在常规 Web 架构中静态文件可以直接交给后端DDD 领域模型中的异常与校验验证位置、守卫子句与错误处理模式全指南DDD 领域模型中的异常与校验验证位置、守卫子句与错误处理模式全指南 本文围绕 Awesome Software Architecture 仓库中 异常与校验云原生DevOps运维微服务Vector 项目文档编写与维护实战指南从 CUE 参考文档生成到 Changelog 与 Release HighlightsVector 项目文档编写与维护实战指南从 CUE 参考文档生成到 Changelog 与 Release Highlights 本指南以 Vector高性可观测性数据工程数据集成日志分析上一篇HTTPie CLI终极指南如何高效批量测试多个API端点下一篇EIP-8131 统一交易内容下限Unified Transaction Content Floor解读以每字节 64 gas 封顶最坏情况区块大小创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考