1.kubelet组件功能
原标题：KubeVela 插件指南：轻松扩展你的平台专属能力简介： 本文将会全方位介绍 KubeVela 插件的核心机制，教你如何编写一个自定义插件在最后，我们将展示最终用户使用插件的体验，以及插件将如何融入到 KubeVela 平台，为用户提供一致的体验。
2.kubernetes 网络插件
KubeVela 插件（addon）可以方便地扩展 KubeVela 的能力正如我们所知，KubeVela 是一个微内核高度可扩展的平台，用户可以通过模块定义（Definition）[1]扩展 KubeVela 的系统能力，而 KubeVela 插件正是方便将这些自定义扩展及其依赖打包并分发的核心功能。
3.kubelet安装
不仅如此，KubeVela 社区的插件中心也在逐渐壮大，如今已经有超过 50 款插件，涵盖可观测性、微服务、FinOps、云资源、安全等大量场景功能本文将会全方位介绍 KubeVela 插件的核心机制，教你如何编写一个自。
4.kubevela官网
定义插件在最后，我们将展示最终用户使用插件的体验，以及插件将如何融入到 KubeVela 平台，为用户提供一致的体验为什么要使用 KubeVela 插件用户使用插件的一个典型方法是通过 KubeVela 团队维护的插件中心（addon catalog）[2] ，它包含了 KubeVela 团队与社区开发者精心编写的系统扩展功能，并以插件的形式发布于插件中心，这样你可以一键下载并安装这些插件。
5.KubeVela
例如安装 FluxCD 可以快速给你的 KubeVela Application 提供部署 Helm Chart 的能力相较于使用 KubeVela 的插件功能，如果你自己的内部平台想要集成一个云原生的功能，你大概会这么做：
通过 Helm Chart 或者下载 yaml 文件手动安装 FluxCD 或类似的 CRD Operator 编写系统集成的代码，让用户界面可以通过统一的方式使用 FluxCD 等 CRD 的功能，在 KubeVela 系统中就是通过编写模块定义（OAM Definition）完成。
实际上，在 KubeVela 1.1 版本之前，我们也是通过类似的方式完成的这会带来如下问题：操作繁琐：用户需要手动查阅文档如何安装 FluxCD 并处理可能发生的错误 资源分散：用户需要下载不同的文件，既需要安装 Helm 安装 FluxCD 还需要下载模块定义等系统。
扩展的集成配置 难以分发复用：用户需要手动下载模块定义就注定了这些资源难以以一个统一的方式分发给用户，也无法形成社区生态让不同的用户可以享受社区便利 缺少多集群支持：KubeVela 将多集群交付作为一等公民，而这样的手动安装系统扩展的方式显然难以维护多集群的环境 无版本管理：用户需要手动管理模块定义和 Controller 之间的版本
而 KubeVela 插件就是为了逐一解决这些问题而诞生的KubeVela 插件是如何工作的KubeVela 的插件主要包含两部分：一部分是安装能力的提供者，通常是一个 CRD Operator/Controller。
这个安装过程实质上就是运行一个 OAM 应用，addon 交付中所使用的功能与普通应用能力完全等价 另一部分就是扩展能力跟 KubeVela 体系的粘合层，也就是模块定义和其他的一些集成配置OAM 模块定义。
为用户提供了插件扩展出的组件、运维特征以及工作流步骤等功能，也帮助 CRD Operator 提供用户友好的抽象，使得最终用户无需理解复杂的 CRD 参数，只需要根据最佳实践提供必要的参数。
插件的工作机制如上图所示，KubeVela 的应用具备多集群交付的能力，所以也能帮助插件中的 CRD Operator 部署到这些集群中模块定义文件仅需要在控制面被 KubeVela 使用，所以无需部署到被管。
控的集群中提示一旦插件被安装，就会创建一个 KubeVela 应用，包含所有的相关资源和配置，这些配置都会设置 KubeVela 应用对外作为 OwnerReference（父节点）当我们想要卸载一个插件时，只需要删除这个应用，Kubernetes 提供的资源回收机制会自动将标记了 OwnerReference 的资源一并删除。
例如一个 Redis 插件，它能让用户在自己的应用中使用 Redi所有整个插件的安装过程会将 Redis Operator 放在一个 KubeVela 应用中下发到多集群，而组件定义和 UI 扩展等配置文件则只部署到控制面集群并设置应用对象为 OwnerReference。
创建自己的插件提示为保证以下内容功能全部可用，请确保你的 KubeVela 版本 为 v1.5+我们将以 Redis 插件为例，讲解如何从头创建一个 KubeVela 插件的实际过程本次完整的 Redis 插件代码见文末参考[3]。
提示在这里我们会尽可能全面的介绍制作插件中涉及的核心知识，但是作为一个介绍性博客，我们会尽量避免讨论过深的细节以免篇幅过于膨胀，了解完整的功能及细节可以参考自定义插件文档[4]首先我们需要思考我们要创建的插件有什么作用？例如我们假设 Red。
s 集群，我们可以使用 Redis Operator[5]那至此我们的大目标就明确了：编写插件的应用描述文件（OAM Application），这将会用于安装 Redis Operator （完整代码可以到。
efinitions/目录[9]）不过在开始编写之前，我们首先需要了解一个 KubeVela 插件的目录结构后续我们会在编写的过程中详细说明每个文件的作用，在这里只需大致了解有哪些文件即可提示命令行工具 vela addon init 可以帮助你创建目录结构的初始化脚手架。
redis-operator/ ├── definitions │ └── redis-failover.cue ├── resources│ ├── crd.yaml │ ├── redis-operator.cue
│ └── topology.cue ├── metadata.yaml ├── parameter.cue ├── README.md让我们逐一来解释它们：1. redis-operator/ 是目录名，同时也是插件名称，请保持一致。
2. definitions/ 用于存放模块定义,3. redis-failover.cue 定义我们编写的 redis-failover 组件类型，包含了用户如何使用这个组件的参数以及这个组件与底层资源交互的细节。
5. crd.yaml 是 Redis Operator 的 Kubernetes 自定义资源定义，在 resources/ 文件夹中的 YAML 文件会被直接部署到集群中6. redis-operator。
7. topology.cue 是可选的，帮助 KubeVela 建立应用所纳管资源的拓扑关系8. metadata.yaml 是插件的元数据，包含插件名称、版本、维护人等，为插件中心提供了概览信息9. parameter.cue 插件参数定义，用户可以利用这些参数在插件安装时做轻量级
自定义10. README.md 提供给最终用户阅读，包含插件使用指南等提示在插件中制作中我们会广泛使用 CUE 语言来编排配置，如果对 CUE 不熟悉，可以花 10 分钟快速查阅入门指南有一个基本了解。
parameter.cueparameter: {//+usage=Redis Operator image.image: *"quay.io/spotahome/redis-operator:v1.1.0" | string
// 其余省略}在 parameter.cue参数在我们的例子中，用户可以自定义 image ，这样后续我们创建 Redis Operator (redis-operator.cue) 的时候可以通过 parameter.image 使用用户指。
定的容器镜像部署用于安装 Helm Chart 的组件能力，而其他控制器就可以不安装如果你对于实现细节感兴趣，可以参考fluxcd 插件的部分配置[11]在设计提供什么参数供用户自定义插件安装时，我们也应该遵。
循一下这些最佳实践来为用户提供更好的使用体验最佳实践不要在 parameter.cue 中提供大量的细节参数，将大量细节抽象出少量参数供用户调节是一个更好的做法 为参数提供默认值（如样例中的 image 参数）或将参数标记为可选（如样例的 clusters 参数），确保用户仅使用默认值可以得到一个可用的配置 为参数提供使用说明（通过注释标记实现，见样例） 尽量保持插件不同
版本间的参数一致，防止因为升级导致不兼容这是存放我们应用描述文件的地方，即一个 OAM Application 这描述了实际的插件安装过程我们主要会在这里包含 Redis Operator ，给集群提供管理 Redis 集群的能力。
成部分，且都是在同一个 package 下的 CUE 文件块中的注释// package 名称需要与 resources 目录中 cue 的 package 一致，方便引用 resources 目录中的内容。
package mainoutput: {// 这是一个经典的 OAM ApplicationapiVersion: "core.oam.dev/v1beta1"kind: "Application"// 不需要 metadata
spec: {// 创建 Redis OperatorredisOperator // 定义于 resources/redis-operator.cue 中]policies: [// 这里会指定安装插件的 namespace ，是否安装至子集
群等// 多为固定写法，无需记忆，可查阅本次样例的完整代码]}}// 定义资源关联规则，用于将资源粘合在一起后续会着重介绍outputs: topology: resourceTopology // 定义于 resources/topology.cue 中。
在插件安装时，系统主要关注两个关键字：一是 output 字段，定义了插件ation 对象不是严格的 Kubernetes 对象，其中 metadata 里的内容（主要是插件名称）会被插件安装的过程自动注入。
另一个是 outputs 字段，定义了除了常规应用之外的配置，任何你想要跟插件一同部署的额外 Kubernetes 对象都可以定义在这里请注意 outputs 中的这些对象必须遵循 Kubernetes API。
resources/ 资源文件ela 内置的 webservice 类型，而不是 helm// resources/redis-operator.cueplate.cue 中引用以下的 redisOperator。
package mainredisOperator: {个 Redis Operatorname: "redis-operator"type: "webservice"properties: {// Redis Operator 镜像名称，parameter.image 即在 parameter.cue 中用户可自定义的参数
image: parameter.imageimagePullPolicy: "IfNotPresent"}traits: [// 略]}你可以阅读代码块中的注释了解字段的具体作用KubeVela 提供的。
资源粘合能力值得注意的一个功能是资源关联规则 (Resource Topology)[12]虽然它不是必须的，但是它能帮助 KubeVela 建立应用所纳管资源的拓扑关系这就是 KubeVela 如何将各种各样的资源粘合成 Application 的。
这在我们使用 Kubernetes 自定义资源（CR）的时候特别有用// resources/topology.cuepackage mainresourceTopology: {apiVersion: "v1"
kind: "ConfigMap"metadata: {name: "redis-operator-topology"namespace: "vela-system"labels: {"rules.oam.dev/resources": "true"
"rules.oam.dev/resource-format": "json"}}data: rules: json.Marshal([{parentResourceType: {group: "databases.spotahome.
com"kind: "RedisFailover"}// RedisFailover CR 会创建以下三类资源childrenResourceType: [{apiVersion: "apps/v1"kind: "StatefulSet"
},// KubeVela 内置 Deployment 等资源的拓扑，因此无需继续向下编写{apiVersion: "apps/v1"kind: "Deployment"},{apiVersion: "v1"
kind: "Service"},]}])}lover 但是在没有资源关联规则的情况下，假设在你的 Application 中使用了 RedisFailover ，虽然我们知道 RedisFailover 管控了数个 Redis Deploy。
ment ，但是 KubeVela 并不知道 RedisFailover 之下有 Deployment 这时我们可以通过 资源关联规则 将我们对于 RedisFailover 的了解告诉 KubeVela，这样 KubeVela 可以帮助我们建立起整个应用下面纳管资源的拓扑层级关系。
此时你将获得 KubeVela 提供的许多有用功能，效果见运行插件[13]提示资源的拓扑关联功能给我们带来了许多有用的功能，最重要的是为 KubeVela 最终用户使用扩展能力提供了统一体验：VelaUX 资源拓扑视图，从应用到底层资源 Pod 的关联关系一应俱全，包括多集群 统一的 vela exec
g 查看不同类型应用组件关联的底层容器日志，包括多集群 统一的 vela status --pod/--endpoint 查看不同类型应用组件关联的底层容器日志，获得可供访问的地址等，包括多集群
definitions/ 目录tDefinition）等这是插件中最重要的部分，因为它包含了最终用户安装这个插件以后可以获得哪些功能有了这里定义的组件、运维特征、工作流等类型，最终用户就可以在应用中使用他们了。
在插件中编写模块定义跟常规的编写流程一致，这是一个很大的话题，在这里我们就不详细展开了你可以通过阅读模块定义对应的文档了解其中的细节：特征 Trait Definition[16] 自定义策略 Policy Definition[17] 自定义工作流步骤 Workflow Step Definition。
[18]在本例中，我们编写 Redis 组件类型主要参照自定义组件[19]与 Redis Operator 使用文档[20]，我们将组件类型命名为 redis-failover，它会创建一个 RedisFailo
ver 的 CR ，这样刚刚添加的 Redis Operator 就可以帮助创建 Redis 集群，见文末完整代码[21]metadata.yaml这里包含了插件的元数据，即插件的名称、版本、系统要求等，可以参考文末文档[22]。
需要注意的是，本次介绍的为 KubeVela v1.5 之后的新写法，因此需要避免使用某些不兼容的元数据字段，以下样例中包含了所有的可用元数据提示例如传统的 depl# 插件名称，与目录名一致name: redis-operator
# 插件描述description: Redis Operator creates/configures/manages high availability redis with sentinel automatic failover atop Kubernetes.
# 展示用标签tags:- redis# 插件版本version: 0.0.1# 展示用图标# 插件所包含项目的官网地址# 可能依赖的其他插件，例如 fluxcddependencies: []# 系统版本要求
system:vela: ">=v1.5.0"kubernetes: ">=1.19"运行插件至此我们已经将插件的主要部分编写完成，下载文末完整代码[24]补全部分细节后，即可尝试运行下载得到 redis-operator 目录后，我们可以通过 vela addon enable redis-operator 安装本地的 r。
edis-operator 插件，这种本地安装插件的方式也可以方便你再制作时做一些调试安装完成后就可以参考插件的 README[25]试用我们的 Redis 插件了！提示这里也体现出插件的 README 的重要性，其中需要包括插件的作用、详细使用指南等，确保用户可以快速上手。
在用户使用你编写的插件时，只需如下 4 行 yaml 即可在 Application 中创建包含 3 个 Node 的高可用 Redis 集群！相比于手动安装 Redis Operator 并创建 CR ，甚至逐一手动配置 Redis 集群，插件的方式极大地方便了用户。
apiVersion: core.oam.dev/v1beta1kind: Applicationmetadata:spec:ded by redis-operator addon.# will be cre
ated.- type: redis-failovername: ha-redisproperties:# You can increase/decrease this later to add/remove instances.
replicas: 3只需 apply 仅仅数行的 yaml 文件，我们就轻松创建了如下图所示的整个复杂的资源并且由于我们编写了资源关联规则 (Resource Top 级别的可观测性如图我们能直接观测到整个 Application 的拓扑，直至每个 Redis Pod ，可见图中部分 Pod 仍在准备中：。
在执行 vela exec/log/port-forward 等命令时也可以精确地看到 Application 底层包含的资源（即支撑 Redis 集群的 3 个 Redis Pod 和 3 个 Sentinel Pod）。
如果你在使用单集群，乍一看你可能不会觉得 exec 进一个 Pod 是很特殊的功能但是一旦考虑到多集群，能够在横跨多个集群的资源中跟单集群一样以统一的方式进行选择查看能够极大的节省时间使用 vela status 命令能获取这个 。
Application 的运行状态，有了资源关联规则后可以更进一步，直接通过 vela 寻找出 Redis Sentinel 的 Endpoint 来访问 Redis 集群：结语通过本文，相信你已经了解插件的作用及制作插件的要点。
通过插件体系，我们将获得如下优势：将平台的能力打包成一个易于安装、便于分发复用、且可以形成社区生态的插件市场 充分复用 CUE 和 KubeVela 应用通过的强大能力，将基础设施资源灵活定义并进行多集群分发。
无论扩展的资源类型是什么，均可以接入应用体系，为最终用户提供一致的体验最后，如果你成功制作了属于自己的插件，KubeVela 社区非常欢迎开发者贡献插件至插件中心[26]，这样你的插件还能够被其他 KubeVela 社区用户发现并使用！
您可以通过如下材料了解更多关于 KubeVela 以及 OAM 项目的细节：项目代码库：github.com/oam-dev/kubevela 欢迎 Star/Watch/Fork！ 项目官方主页与文档：kubevela.io ，从 1.1 版本开始，已提供中文、英文文档，更多语言文档欢迎开发
户群：戳此处：查看 KubeVela 项目官网！！相关链接[1] 模块定义（Definition）/x-definition[2] 插件中心（addon catalog）[3] catalog/redis-operator
htt[4] 自定义插件文档bevela.net/zh/docs/platform-engineers/addon/intro[5] Redis Operators-operator[7] resources/
ns/redis-operator/resources[9] definitions/目录tal/addons/redis-operator/definitions/master/addons/fluxcd/parameter.cue
[11] fluxcd 插件部分配置[12] 资源关联规则 (Resource Topology)/topology-rule[13] 运行插件E8%A1%8C%E6%8F%92%E4%BB%B6[14] 模块定义（Definition）
[1[16] 自定义运维特征 Trait Definition[17] 自定义策略 Policy Definition[18] 自定义工作流步骤 Workflow Step Definition[19] 自定义组件
http[20] Redis Operator 使用文档https[21] 完整代码alog/blob/master/experimental/addons/redis-operator/definitions/redis-failover.cue
[22] 文档evela.net/zh/docs/platform-engineers/addon/intro#%E6%8F%92%E4%BB%B6%E7%9A%84%E5%9F%BA%E6%9C%AC%E4%BF
%A1%E6%81%AF%E6%96%87%E4%BB%B6[24] 完整代码[25] README/kubevela/catalog/tree/master/experimental/addons/redis-operator/README.md
[26] 插件中心m/kubevela/catalog11 月 5 日杭州云栖小镇-云原生峰会阿里云将联手识货、传音、禾连健康、新东方、心动网络、小红书等实战企业技术负责人向你发出邀请
