KubeVela KEP-2.20 设计解析：模块命名空间、多租户与 `vela-system` 共存机制

云原生DevOps运维微服务【免费下载链接】kubevelaThe Modern Application Platform.项目地址https://gitcode.com/gh_mirrors/ku/kubevela点击查看免费下载导读本文基于 KubeVela 仓库中 KEP-2.20 模块与 API Line 版本化设计 的 Design 02模块命名空间与租户隔离设计 展开。该文档是模块化能力分层设计的枢纽hub文档它定义了每个模块一个命名空间namespace-per-module的模型回答模块命名空间是什么、装什么、如何创建与回收、如何作为租户/RBAC 边界以及它与现有vela-system定义命名空间在迁移期间和迁移之后如何共存。读完本文你将掌握 KubeVela 模块化版本化能力底层的命名空间模型、确定性解析原理、租户隔离机制以及新旧引用形式并行不悖的非回归约束。背景分层生命周期设计中的枢纽文档在 KEP-2.20 模块与 API Line 版本化 的分层设计中存在多份互为依赖的设计文档Design 01模块 CRD 与模块所属 Application—— 描述CR controller路线的模块模型一个模块是独立可安装、可发布、带版本的平台能力单元仅包含定义其 API 的 X-Definitions 与支撑它们的辅助资源模块由一个模块所属的 Application 作为部署引擎。Design 02命名空间与租户本文主体—— 拥有命名空间模型本身模块命名空间是什么、包含什么、如何创建与回收、如何充当租户/RBAC 边界以及如何与现有vela-system定义命名空间在迁移期间及之后共存。Design 03API Line 调查—— 调查 API Line 是封装在 Module 内还是拥有独立持久身份。Design 04集群上下文—— 向 CUE 上下文注入集群元数据。Design 02 的状态为 In Progress被 Design 01 以及尚未撰写的身份/解析设计所引用。其中一项关键前置条件是本地 hub 在基于标签的上下文生效于所有场景之前需要一条集群元数据条目详见 Design 04。设计文档明确指出凡是依赖本文决策的文档都应引用本文而非重新推导。核心事实X-Definitions 本身就是命名空间级资源整个命名空间模型建立在一个容易被忽略的事实之上四类 X-DefinitionComponentDefinition、TraitDefinition、WorkflowStepDefinition、PolicyDefinition全部是 Namespaced命名空间级而非集群级cluster-scoped资源。仓库中的证据来自两个层面CRD 清单声明在 charts/vela-core/crds/core.oam.dev_componentdefinitions.yaml 等 CRD 文件中可见scope: Namespaced。Go 类型标记在 apis/core.oam.dev/v1beta1 下四类定义均声明了// kubebuilder:resource:scopeNamespacedcomponentdefinition_types.gocore_types.goWorkloadDefinitioncore_types.goTraitDefinitionpolicy_definition.goPolicyDefinitionworkflow_step_definition.goWorkflowStepDefinition这些定义之所以看起来集群范围内可见只是因为约定系统定义全部位于vela-system命名空间并在那里被解析。这意味着把某模块的定义放入专用命名空间并不是新增能力或改变定义模型而只是把既有的命名空间机制从共享的vela-system换成了 per-module 命名空间。现状的两步命名空间查找当前解析路径是两步命名空间搜索。核心实现在 pkg/oam/util/helper.go 的GetDefinition先尝试 Application 自身命名空间GetDefinitionNamespaceWithCtx未找到时回退到vela-system通过GetXDefinitionNamespaceWithCtx与 pkg/oam/var.go 中的oam.SystemDefinitionNamespace vela-system。因此应用本地命名空间中的定义会覆盖系统定义这个回退本质上是一个优先级机制而不只是搜索行为。这一点从 validation.go 等 webhook 校验路径以及 helper_test.go 的测试中都能得到印证。命名空间-per-模块Namespace-per-Module每个模块拥有自己的命名空间按约定命名为vela-module-module例如vela-module-aws-s3。它容纳ModuleCR模块所属的Application模块的命名空间级 X-Definitions其他命名空间级、模块作用域的支撑资源例如命名空间级的 ConfigTemplate 或 Schema。关键边界必须在 spoke工作负载实际运行的子集群上运行的运行时资源能力所需的 workload 与实现资源由模块所属 Application 的 workflow 放置在 spoke 上见 KEP-2.13 的 Design 01/02它们不受限于hub 上的模块命名空间。模块命名空间是模块控制面与元数据资源在 hub 侧的家。命名空间隔离带来的三大优势原生所有权Native ownership模块所属 Application 与模块的定义共享同一命名空间因此 Application 通过普通 Kubernetes owner reference 即可拥有这些定义不存在跨作用域的所有权问题。ResourceTracker 仍然跟踪 Application 部署的一切包括 spoke 资源定义不再需要任何特殊的所有权路径。确定性解析、无回退搜索模块化引用aws-s3/v1/bucket精确指明了模块因此也指明了命名空间vela-module-aws-s3和定义v1-bucket由于命名空间已承载模块名定义名不带模块前缀。解析是一次确定性的 GET完全不consult local-then-vela-system回退。显式引用减少了一个既有查找步骤而非增加一个。真正的租户边界所有权、RBAC 与发现机制都获得了 Kubernetes 原生边界。与已发布 KEP-2.20 命名约定的有意分歧KEP-2.20 将模块定义命名为{module}-{apiVersion}-{definition-name}例如aws-s3-v1-bucket。这个前缀原本用于区分全部挤在vela-system命名空间里的定义。Namespace-per-module 消除了这一需求命名空间承载模块名因此定义名去掉模块前缀v1-bucket。这是有意的分歧需要在合并回 KEP 时协调统一。租户与 RBAC模块命名空间即访问控制单元模块命名空间是一个能力的最小访问控制单元负责aws-s3的团队可以被授予仅限vela-module-aws-s3的权限该命名空间内的 Role RoleBinding而不会获得其他模块或vela-system的任何权限。这是标准的 Kubernetes 命名空间 RBAC无需自研授权层。创建ModuleCR 会导致其 controller 安装定义从而集群范围地改变 Application 作者可用的能力。与 Addon CR 的安全考量一致创建/修改 Module CR 及其命名空间的能力应仅限平台团队的服务账号。发现机制是命名空间列举回答aws-s3装了些什么只需列举vela-module-aws-s3而非按标签过滤vela-system。命名空间生命周期引导与回收模块命名空间的生命周期与模块绑定。创建当ModuleCR 被安装无论是独立安装还是经由 Addon 内联安装时其命名空间必须先于模块所属 Application 与定义存在。文档列出两个候选方案待决策方案 AModule controller 在首次 reconcile 时确保命名空间存在不存在则创建并打上模块所属标签方案 B命名空间作为父级资源内联模块场景下的 Addon Application的一个渲染资源由现有 Application 机制创建与回收。方案 B 的吸引力在于把命名空间生命周期留在一切皆 Application模型内但对独立模块很别扭没有父 Application。文档倾向的解法是Module controller 直接确保命名空间使用众所周知的标签使归属关系无歧义尚需验证。无论选择哪种方案顺序一致命名空间必须先创建并 Ready然后才能向其中部署任何模块资源。模块所属 Application 自己的 workflow 强制执行这一顺序因此该约束在 CR 模型与 component 模型下都成立actor在 CR 模型下是 Module controller在 component 模型下是module组件的 CueX 渲染 workflow。回收模块被移除时其命名空间与内容应被清理但必须在模块资源安全回收之后定义可能仍被引用见 Design 01 的删除策略与废弃生命周期。过早删除命名空间会使被引用的定义成为孤儿或被强制删除。安全顺序是先执行 finalizer 门控的模块所属 Application 及其资源回收再删除命名空间。命名空间是否最终被删除还是留空仍是未决项空的模块命名空间成本低廉且能避免竞态。碰撞在vela-module-module约定下两个模块不可能共享命名空间因为模块名唯一。超长模块名的长度与 DNS 标签约束需要与 KEP-2.20 定义名约定一致的截断/哈希规则该事项被标记给身份设计。与vela-system共存及迁移非回归不变量现有定义全部位于vela-system并以非限定名type: webservice被引用。引入模块命名空间不得破坏它们。共存规则如下传统非限定引用type: bucket继续使用现有的两步查找本地命名空间然后vela-system解析到非模块定义行为完全不变。模块化引用type: aws-s3/v1/bucket在模块命名空间内确定性解析永不回退。两种引用形式不竞争同一次查找因此新增模块命名空间不可能静默改变现有type: name引用的解析结果。这是命名空间模型必须保持的不变量精确的优先级规则、歧义处理以及迁移边界情况例如传统定义与模块定义共享裸名由身份设计负责。本文只陈述约束模块命名空间不得改变传统解析。传统路径左侧正是今天的两步查找原封不动模块路径右侧直接从引用推导出命名空间与名称并执行一次 GET既不用也不受vela-system回退影响。内置vela模块KubeVela 自身的第一方定义未来有资格迁入内置vela模块vela/v1/webservice。vela模块是使用专用命名空间还是为兼容性保留在vela-system属于身份设计的迁移决策命名空间模型对两者都支持因为vela模块的引用将是显式的vela/v1/...无论底层由哪个命名空间支撑都是确定性的。与 API Line 层的交互三层层级就此止步API Line 不拥有自己的命名空间。某模块的全部 API Line 共享唯一的模块命名空间vela-module-aws-s3无论 API Line 未来是否成为独立资源Module/API Line 设计中的未决调查。API Line 是模块内的一个身份段不是独立的租户单元给它一个命名空间会把概念上属于一个整体的能力碎片化。这同时保持了层级的可理解性Addon → Module → API Line是清晰的三层层级若每个 Line 一个命名空间层级将变成四层且命名空间布局混乱而无收益。命名空间层级止步于模块。实现层面的印证从 KEP-2.20 到模块模型将本文与 KEP-2.20 主文档 对照可以更完整地理解设计意图KEP-2.20 基线中type引用有三种形式Form 1 非限定bucket、Form 2 版本限定v1/bucket、Form 3 全限定aws-s3/v1/bucket。Design 01/02 提出更简化的两形式模型仅保留传统非限定与全限定两种Form 2 的模块发现被移除因为 namespace-per-module 下全限定引用直接映射到命名空间与定义名单次确定性 GET 即可完成。模块引用在 Admission 时被解析为规范三元组(module, apiVersion, definitionName)并锁入ApplicationRevision模块与名称一旦绑定即不可变只有apiVersion可通过显式修改type迁移例如aws-s3/v1/bucket→aws-s3/v2/bucket。模块命名空间是交付与命名空间边界不是契约边界两个模块可以发布同名同版本的独立v1Line 而互不碰撞——这正是 namespace-per-module 在租户/发现层面要解决的场景。未决讨论与 Spike 清单Design 02 明确列出的开放问题引导机制controller 确保命名空间 vs 父 Application 渲染命名空间见生命周期一节。回收策略模块移除时命名空间是删除还是留空与定义引用安全性的顺序。命名空间命名约束超长模块名的截断/哈希规则与定义名约定对齐身份设计负责。命名空间标签/配额/网络姿态模块命名空间是否携带标准标签及任何配额/网络策略。优先级规则传统 vs 模块解析的完整优先级由身份设计负责本文只固定非回归不变量。vela模块命名空间内置模块用专用命名空间还是留在vela-system。KEP 措辞修正KEP-2.13/2.20 部分地方把定义描述为 cluster-scoped按 CRD 实际是 Namespaced合并回时需修正。小结为什么 namespace-per-module 是分层模型的地基从 Design 01 的模块身份契约模块名即身份、定义名apiLine-definition、引用形式module/apiLine/definition到 KEP-2.20 的版本化解析一切最终都落在命名空间模型上X-Definitions 本就是 Namespaced 这一事实使 per-module 命名空间成为零成本的自然形态——原生所有权、确定性单 GET 解析、真实租户边界随之而来而模块路径与传统路径永不竞争的不变量则保证了向模块化迁移时既有 Application 一个都不会被静默破坏。扩展阅读KEP-2.20 主文档模块身份模型、API Line 命名约定、类型引用解析与废弃生命周期Design 01模块 CRD 与模块所属 Application模块定义、所有权链与注册表发布Design 03API Line 调查Design 04集群上下文解析实现GetDefinition、SystemDefinitionNamespace、四类定义的 Namespaced 声明赞分享云原生DevOps运维微服务【免费下载链接】kubevelaThe Modern Application Platform.项目地址https://gitcode.com/gh_mirrors/ku/kubevela点击查看免费下载相关推荐Apache Pulsar 多租户架构深入解析租户、命名空间与命名空间变更事件机制Apache Pulsar 多租户架构深入解析租户、命名空间与命名空间变更事件机制 导读 本文基于 Apache Pulsar 官方多租户概念文档展开系统讲消息队列后端流处理KubeVela vNext 多租户设计解析KEP-2.14 中的 TenantDefinition 与 Tenant 平台原语KubeVela vNext 多租户设计解析KEP 2.14 中的 TenantDefinition 与 Tenant 平台原语 KEP 2.14 是 Kub云原生DevOps运维微服务RapidOCR Docker 部署避坑指南9003 端口上稳定跑通 OCR 服务的完整路径RapidOCR Docker 部署避坑指南9003 端口上稳定跑通 OCR 服务的完整路径 容器刚起就报缺依赖跑十分钟内存还在往上爬——RapidOCR人工智能计算机视觉OCR上一篇百度网盘秒传链接终极指南3分钟掌握文件极速传输下一篇mirrors/ali-vilab/text-to-video-ms-1.7b震撼发布1.7B参数开启文本转视频新纪元创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考