新闻详情

新闻详情

首页 / 资讯中心 / 详情

KubeVela 多集群云资源共享实战:用 share-cloud-resource 工作流步骤把 RDS 连接凭证同步到任意集群

发布时间:2026/9/29 2:54:40来源:尧图网络
KubeVela 多集群云资源共享实战:用 share-cloud-resource 工作流步骤把 RDS 连接凭证同步到任意集群
云原生DevOps运维微服务【免费下载链接】kubevelaThe Modern Application Platform.项目地址https://gitcode.com/gh_mirrors/ku/kubevela点击查看免费下载KubeVela 的share-cloud-resource是一个内置工作流步骤WorkflowStepDefinition专门解决跨集群/跨项目共享云资源的问题当你在 A 集群通过 Terraform 组件创建了阿里云 RDS 等云资源后可以把它生成的连接凭证Secret同步到 B 集群、甚至同一集群下的其他命名空间让多个业务项目共用同一份云资源。读完本文你将掌握share-cloud-resource的完整参数语义、与env-binding策略及deploy-cloud-resource步骤的配合方式并能直接复制一份可运行的多集群 Application 配置。为什么需要共享云资源在多集群/多环境交付场景中云资源数据库、消息队列、对象存储等通常价格昂贵且创建耗时。一个合理的做法是只在少数几个环境中真正创建云资源其余环境通过读取连接凭证直接复用。KubeVela 用env-binding策略来表达环境用deploy-cloud-resource步骤在指定环境所属集群中部署云资源用share-cloud-resource步骤把该环境已生成资源的连接凭证同步到其他集群或命名空间。三者组合后一个 Application 就能表达出完整的多集群共享链路。官方仓库在 references/docgen/def-doc/workflowstep/share-cloud-resource.eg.md 中提供了该步骤的标准示例下文将以此为主线展开。完整示例杭州/香港建库北京共享、香港多项目共享下面的 Application 完整演示了share-cloud-resource的两种典型用法本示例同时存在于 references/docgen/def-doc/workflowstep/share-cloud-resource.eg.md 与 docs/examples/envbinding/deploy-and-share-cloud-resource.yamlapiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: rds-app namespace: project-1 spec: components: - name: db type: alibaba-rds properties: instance_name: db account_name: kubevela password: my-password writeConnectionSecretToRef: name: project-1-rds-conn-credential policies: - name: env-policy type: env-binding properties: envs: # 部署 RDS 给杭州集群 - name: hangzhou placement: clusterSelector: name: cluster-hangzhou patch: components: - name: db type: alibaba-rds properties: # region: hangzhou instance_name: hangzhou_db # 部署 RDS 给香港集群 - name: hongkong placement: clusterSelector: name: cluster-hongkong namespaceSelector: name: hk-project-1 patch: components: - name: db type: alibaba-rds properties: # region: hongkong instance_name: hongkong_db writeConnectionSecretToRef: name: hk-project-rds-credential workflow: steps: # 部署 RDS 给杭州区用 - name: deploy-hangzhou-rds type: deploy-cloud-resource properties: env: hangzhou # 将给杭州区用的 RDS 共享给北京区 - name: share-hangzhou-rds-to-beijing type: share-cloud-resource properties: env: hangzhou placements: - cluster: cluster-beijing # 部署 RDS 给香港区用 - name: deploy-hongkong-rds type: deploy-cloud-resource properties: env: hongkong # 将给香港区用的 RDS 共享给香港区其他项目用 - name: share-hongkong-rds-to-other-namespace type: share-cloud-resource properties: env: hongkong placements: - cluster: cluster-hongkong namespace: hk-project-2 - cluster: cluster-hongkong namespace: hk-project-3这段配置对应四条工作流步骤先分别在杭州集群cluster-hangzhou和香港集群cluster-hongkong的hk-project-1命名空间中部署各自的 RDS再用两个share-cloud-resource步骤完成共享share-hangzhou-rds-to-beijing把杭州环境的 RDS 连接凭证同步到北京集群cluster-beijing命名空间未指定默认跟随 Application 所在命名空间project-1。share-hongkong-rds-to-other-namespace把香港环境的 RDS 连接凭证同步到同一个集群cluster-hongkong下的hk-project-2与hk-project-3两个命名空间供其他项目复用。参数详解placements / policy / envshare-cloud-resource的定义位于 vela-templates/definitions/internal/workflowstep/share-cloud-resource.cue内置定义在安装 Vela Core 时通过 charts/vela-core/templates/defwithtemplate/share-cloud-resource.yaml 下发到集群。其官方描述为Sync secrets created by terraform component to runtime clusters so that runtime clusters can share the created cloud resource.把 Terraform 组件创建的 Secret 同步到运行时集群使这些集群能共享已创建的云资源。它只接收三个参数语义如下参数类型必填默认值说明placements对象数组是无声明共享的目标位置集群 命名空间见下方子字段policy字符串否指定要使用的env-binding策略名为空时自动使用 Application 中第一个env-binding策略env字符串是无声明读取哪个环境env-binding 策略中的 env 名称中的云资源连接凭证placements数组中的每个元素支持两个可选子字段都省略时无意义至少指定其一子字段类型说明namespace字符串凭证 Secret 在目标集群中的目标命名空间省略时默认沿用 Application 自身的命名空间cluster字符串目标集群名称省略时默认视为本地集群localpolicy 参数的内部语义从 share-cloud-resource.cue 可以看出placements是[...{namespace?: string, cluster?: string}]两个字段都可选policy: * \| string使用 CUE 的默认值语法*即不传时为空字符串模板内部会回落为取第一个 env-binding 策略env为必填字符串指向策略中的环境名。源码级原理share-cloud-resource 到底做了什么share-cloud-resource的模板只做了一件事把用户参数装配进op.#ShareCloudResource操作见 share-cloud-resource.cue并把 Application 的命名空间、名称分别作为namespace与name传入——这一步说明共享动作始终以当前 Application 的元数据为上下文。真正的实现位于 Terraform 操作集合 pkg/workflow/providers/legacy/terraform/terraform.cue 的#ShareCloudResource块约 L228-L277其核心链路为解析目标位置L245-L257遍历placements把每个 placement 归一化为namespace省略则取 Application 命名空间cluster省略则取local的决策结构。加载环境组件L238-L243通过#PrepareTerraformEnvBinding按env/policy从 Application 中筛选出属于该环境、且类型为 Terraform 的组件该操作同时依赖#PrepareEnvBinding与#LoadTerraformComponents。读取凭证 Secret#loadSecretInfoL53-L74解析组件的writeConnectionSecretToRef得出源 Secret 的name/namespace并构造name-env格式的 envName随后#bindTerraformComponentToCluster中的#Read从源集群读取该 Secret 内容。同步下发L103-L126对每个决策目标执行#Apply把读到的 Secretdata以type: Opaque的形式写入目标clusternamespace命名空间缺省时与源一致从而实现凭证共享。值得一提的是#bindTerraformComponentToCluster还会用#ConditionalWait等待资源健康status.outputs.healthy后再读取 Secret确保同步的凭证是就绪状态的。这也是为什么deploy-cloud-resource与share-cloud-resource必须按示例中的先后顺序编排。与 deploy-cloud-resource 的配对使用share-cloud-resource通常紧跟deploy-cloud-resource步骤示例见 references/docgen/def-doc/workflowstep/deploy-cloud-resource.eg.md- name: deploy-hangzhou-rds type: deploy-cloud-resource properties: env: hangzhou - name: share-hangzhou-rds-to-beijing type: share-cloud-resource properties: env: hangzhou placements: - cluster: cluster-beijing原因在于deploy-cloud-resource负责把组件改名为component-env并真正下发到该 env 对应的集群同时把连接凭证写入源 Secretshare-cloud-resource负责把同一 env 的源 Secret只读复制到额外目标位置。两者都通过#PrepareTerraformEnvBinding定位组件因此引用同一策略、同一 env 时天然对齐。若共享目标与源集群相同、但命名空间不同如香港场景甚至可以不依赖额外集群实现一库多项目的复用。使用注意事项Application 级 scope该步骤定义带有scope: Application标签见 charts/vela-core/templates/defwithtemplate/share-cloud-resource.yaml属于应用交付Application Delivery类别只能在 Application 的spec.workflow中使用。凭证以 Secret 为单位共享共享的是云资源的连接凭证Secret而不是重新创建云资源目标集群中不会出现新的 RDS 实例。命名空间缺省语义placements中不写namespace时目标 Secret 落在 Application 所在命名空间不写cluster时目标默认为本地集群local。多策略显式指定如果 Application 中定义了多个env-binding策略建议通过policy显式指定策略名避免依赖取第一个的默认行为。顺序敏感share-cloud-resource必须在对应环境的deploy-cloud-resource之后执行否则源 Secret 尚未创建、无法读取。以上示例整体可直接保存为 YAML 并通过vela up -f file应用到具备对应集群环境cluster-hangzhou、cluster-hongkong、cluster-beijing的控制集群中若需在本地测试可将placements的cluster收敛为local或省略仅验证命名空间级共享能力。赞分享云原生DevOps运维微服务【免费下载链接】kubevelaThe Modern Application Platform.项目地址https://gitcode.com/gh_mirrors/ku/kubevela点击查看免费下载相关推荐WebdriverIO API 全解析协议绑定、便捷命令与核心对象实战指南WebdriverIO API 全解析协议绑定、便捷命令与核心对象实战指南 导读 WebdriverIO 的 API 体系由两层构成直接下发到底层驱动后端的云原生DevOps运维微服务Flink CDC 部署模式全指南Standalone、YARN 与 Kubernetes 的安装、配置与作业提交Flink CDC 部署模式全指南Standalone、YARN 与 Kubernetes 的安装、配置与作业提交 本文是 Flink CDC 部署模块 d云原生DevOps运维微服务KubeVela 多集群部署实战指南Topology / Override 策略、deploy 工作流步骤与 ref-objects 组件详解KubeVela 多集群部署实战指南Topology / Override 策略、deploy 工作流步骤与 ref objects 组件详解 本文以 Kub云原生DevOps运维微服务上一篇XXMI-Launcher多游戏模型管理的跨环境整合方法探索下一篇QQ空间数据备份新方案GetQzonehistory让数字记忆永久留存创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
网站建设高端定制企业官网
RELATED

相关资讯

更多精彩内容,欢迎继续阅读

较早相关资讯

最新相关资讯

MAS完整指南:Windows与Office一次永久激活,不再反复折腾 2026/9/29 7:40:48

MAS完整指南:Windows与Office一次永久激活,不再反复折腾

MAS完整指南:Windows与Office一次永久激活,不再反复折腾 【免费下载链接】Microsoft-Activation-Scripts Open-source Windows and Office activator featuring HWID, Ohook, TSforge, and Online KMS activation methods, along with advanced troubles…

阅读更多 →
2026长沙电气检测机构排名 TOP5 CMA 资质机构提供防爆设备检测+防爆安全检测 联系方式推荐 2026/9/29 7:40:48

2026长沙电气检测机构排名 TOP5 CMA 资质机构提供防爆设备检测+防爆安全检测 联系方式推荐

长沙的电气防爆检测机构可谓鳞次栉比、鱼龙混杂,化工园区、油库加油站、矿山厂区、制药企业、危化品仓储场所开展防爆电气安全排查与生产验收时,大量无资质机构出具的报告往往无法通过应急管理部门核查。小编实地走访、层层筛选,精心整理出本…

阅读更多 →
Codex Skills 实战:用 TaoToken 统一 Key 把提示词沉淀成可复用 AI 工作流 2026/9/29 7:40:48

Codex Skills 实战:用 TaoToken 统一 Key 把提示词沉淀成可复用 AI 工作流

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

阅读更多 →
2026长春电气检测机构排名 TOP5 CMA 资质机构提供防爆设备检测+防爆安全检测 联系方式推荐 2026/9/29 7:40:48

2026长春电气检测机构排名 TOP5 CMA 资质机构提供防爆设备检测+防爆安全检测 联系方式推荐

长春的电气防爆检测市场可谓百家争鸣,各类机构鳞次栉比,但其中也不乏鱼龙混杂之辈。化工园区、油库加油站、矿山厂区、制药企业以及危化品仓储场所,在开展防爆电气安全排查与生产验收时,若误选了无资质机构,其出具的报…

阅读更多 →
读书笔记:软件架构设计原则 - 组件原则(Principles of Component)(中英文对照) 2026/9/29 7:40:41

读书笔记:软件架构设计原则 - 组件原则(Principles of Component)(中英文对照)

读【美】Robert C. Martin(罗伯特 C. 马丁)的《架构整洁之道》(Clean Architecture)有感,做个整理。本文不是逐字翻译向,算是个人见解的注释。 组件内聚原则 组件内聚原则主要讨论拿些类应该聚合在一个组件…

阅读更多 →
从手动调参到AutoML:用TPOT自动构造机器学习pipeline的完整实践 2026/9/29 7:40:41

从手动调参到AutoML:用TPOT自动构造机器学习pipeline的完整实践

1. 从手动调参到AutoML:我为什么最终留下了TPOT先交代一下背景。我大部分时间在做表格类机器学习项目,客户那边的数据基本在几万到几十万行量级,变量几十到几百个。这类项目最花时间的不是写模型代码,而是把数据预处理、特征选择、…

阅读更多 →

今日资讯

本周资讯

本月资讯

看完文章仍有疑问?

联系尧图顾问,获取一对一建站咨询

立即免费咨询 📞 400-888-8888
📞 ✉