开发者学堂课程【云原生应用插件开源贡献课程 ：如何为 KubeVela 社区贡献自己制作的插件】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1211/detail/18199
如何为 KubeVela 社区贡献自己制作的插件
如何制作自己的插件，首先我们需要了解一下 kubevela 本身的一个插件体系，它的一个 definition 模块定义的体系，以及我们模块定义底层使用的这样一个 q 语言的基础入门。
q 的一个基础入门，首先我们为什么要使用 q 和 definition 来做 Kubevela 这样一层抽象，有很多原因。最直观的就是当我们有了这样一层抽象之后，我们就可以在开箱即用以及自定义之间达到一个比较好的平衡。比如对一些基本的能力，可以提供一些内置的系统开箱即用的这样一些定义。比如比较常用的 web service，它就是一个可以让你直接部署一个 deployment 这样一个组件的定义。比如又或者是像一个 HTTP 请求的工作流步骤，这些也是内置提供的。所以如果的外部的一些server，你可以直接使用 HTP 请求的这样一个步骤来直接去调用。但是在某一些业务场景当中，是需要去深度可定制化的一些工作流，组件。大家都是有自己的一些业务场景的，这个时候如果有 q 这样一层抽象，在我们的整一个 application 模板之下，有另外一层抽象层来帮我们像胶水一样去粘合大家各个系统不一样的组件的时候，我们就可以以一种非常便捷的方式去来完成我们定制化的一些交付。
先来简单的展示一下，如果有了这样一层抽象之后，能够答道一种怎样的效果。比如像大家在部署完 application 当之后，其实只是完成了部署第一步，第二步，其实还需要一个可持续化的运维，这时候可能就需要一些可观测性的体系，kubevela也是提供了这样可观测性的一些插件，可以来简单看一下它的效果。而这样一层配置使用到的就是我们的 definition 以及 q 的一些体系。
这里有一个 Grafana 的一个插件。大家如果对可观测性体系是有一定了解，就知道 Grafana 其实是一个可视化的可观测性的一个页面。可以来直接 enable 这样一个 add on。当我们打开插件之后，我们能够看到什么样的一个效果。
进入到 Grafana 之后，输入一下它内置的一个动力密码是 admin，登录完成之后。
左边这里的 browser 里面可以看到是有一些内置的大盘。
打开之后可以看到这里有许许多多的一些表盘，比如它的一些 QPS，一些 latency 之类的。所以如果你对你的应用有包括一些系统级的和应用级的一些监视，可观自性有一些需求，完全可以使用科威朗社区目前提供的这种可观测性的一个插件来满足你的需求。而且可以看到这些东西相当等于是开箱即用的。
在有了这样一层 definition 当中之后，我们会在开箱即用以及深度可定制化中达到一个平衡。首先在这里我们看到的是一个开箱体即用的体验。本次的训练营还是希望能让大家参与到 Adon 贡献来，接下来展示一下我们这样一个 Graphena 的这样一个插件到底是怎么完成的。
在这里的 add on 目录下，我们有看到 Grafana 和 Grafana definitions 。我们可以看到 Grafana 里面除了它的 Meta data，是 add on 的一个基本信息，它会有叫做 resources 的这样一个文件夹，里面放的就是刚刚我们看到的这些表盘里面所需要的这样一些dashboard，其实它这里的定义就是把我们刚刚所看到 dashboard 转换成 JSON 赋给了一个变量。然后在启动 add on 的时候，直接将这些 add on 来部署到这些 resources。 这些 JSON 转换成一个 CRD，我们会将 CRD 直接去通过我们后底层会有一个 Vela prism 的这样一个API，去把它部署到集群里面。
有了这些 JSON 之后，我们会直接通过一些配置将这些写好的 JSON 直接向 Grafana 的一个 endpoint发起一个创建的请求。在 enable 中 Grafana 的插件的时候，就可以直接在Grafana 的一个页面上看到这些已经配置好的表盘。当然也可以选择自定义。这里是展示了 Grafana 一个内置的这样一些定义。但它还有一个叫做 Grafana definitions 的这样一个 add on 里面，它可能有其他的 definition。在这些 definition 里面，比如我们以 Grafana dashboard 为例，其实在这里面可以使用一些，比如你可以给他发一些data，或者传一些 JSON，或者从 URL 里面直接去读取到你 JSON 内容。如果使用了这样一个 definition，你也可以很快地完成一个自定义 dashboard 搭建。这也意味着，只要不论你从 graph 的一些官方库或者是第三方库里面，只要能够拿到 dashboard 的一个 JSON，就可以使用这种方式来完成。实际上页面上 dashboard 的一个注入，并且可观测性是跟我们的应用体系是结合得非常好的。
definition 体系的一个比较小的体现。通过这样一种方式，大家也可以感受到 kubevela 其实在利用这一层抽象的时候，完成了很多内置功能的同时，也留给了用户这样一层非高度可扩展的这样一层抽象层。我们这一层 q 到底是一门什么样的语言？因为我们的 definition，它本质上都是由 q 语言来完成的。
因为首先这个 q 它本身就是一个配置语言，所以完全可以用写 JSON 的逻辑来写这些变量。在写这些变量的基础上，我们还可以写一些 if 的条件判断。比如我们是设置了一个resource，如果你给这样一个 resource 给它赋有一个默认值，这里星号开头的它会是一个默认值。比如它这里写的是一个 price number。如果 price 它大于100，它会把 feel 置为变量，会置为 bad。如果它默认，它就是一个 good 变量。通过这种 IF 的一些条件判断，包括它还会有一些内置的 function，比如 JSON，on Marshall 等等。通过这样一种函数和数据模板的一种结合，我们就可以使用 q 这样一种语言来完成我们实际想要部署的一些资源的渲染。
如果大家之前已经试用过 kubevela，大家可能会对 web service 这样一个 definition 比较熟悉，因为这是 kubevela里面用的比较多的一个 definition，实际上 definition 在 q 文件里面，它主要分这样几块。首先是 template， template 它里面会有一些固定的变量，比如 output。如果这是 component 的 definition，我们会默认将它 output 里面的这些资源直接通直接 apply 到集群当中。outputs 就会将它视为一个附属资源，同样的也会 apply 到集群当中。web service 这样一个 definition 就会比较清晰。首先 output 里面就是一个 deployment。所以我们如果在这样一个 web service 的定义当中，如果我们指明了一些镜像，我们就会直接把镜像渲染成这样一个 deployment，并且 apply 到集群当中。我们还有非常重要的一个部分就是 parameter。在 parameter 里面，我们定义的真正向使用我们 definition 用户暴露的一些参数。在这里我们其实就可以做一些定制化。如果你真正的需要手写这样一个deployment，你要写的参数是非常多的，包括这些 name，image，一些 image， pool policy。这些有一些值是默认，但其实大部分的值，其实我们大家都是有一些大家都已经定义完的一些定义我们也可以使用。所以在这里其实我们也加了一些自定义的默认值。比如我们可以给 deployment 去加一些 service 的 expose type，默认，我们就直接使用 cluster IP。其他的其实大部分的参数都是可选，比如你 deployment 的需不需要 ENV，它都是一些可选的参数通。对于可选的参数，在这里就可以通过一个问号表明这样一个参数是一个可选的值。目前我们为这样一个 definition 去加一些新的参数来做一个例子。比如对于我们 deployment 来说， deployment 它有一些滚动更新的策略，当然默认就是 Rolling update，当然也可以把它设置为recreate。如果向用户去暴露这个参数，因为之前在web service 的定义里面，其实并没有去向用户暴露滚动更新的参数，我们可以将这个参数定义为 a update strategy。首先，第一个是 type ， 我们希望它默认的值还是 Rolling update，所以在这里填写一个星号，这个星号代表它是一个默认值。并且由于它这里 tab 的可选项有限，所以在这里使用一个或并且把第二个选项可以填的一个选项写在这里。
有了这样一个参数之后， Rolling update 的这样一个类型，它对于 QPS deployment 来说，它还可以设置 Rolling update 的一些 Mac search 这样一些参数，所以在这里再加一个参数，就叫 Rolling update。这样一个参数， type 类型为 recreate，不需要参数。所以我们可以在将参数设置为一个可选项。在这里加一个问号。再在里面去设置一下热量 day 的一个参数，他应该是 Max search。对于 Mac surge，其实 QPS deployment 它的默认的 Mac surge 就是25%，所以在这里可以直接把这个值也作为一个默认值。
除了默认值之外，用户其实可以自定义它的一个 maxsir。声明一下它的类型是 string。除了 Mac search 之外，还有一个是 Mac，unavailable，同样我们用默认的25%。
把参数和我们的需要渲染的一些资源联合在一。在需要渲染的资源里面去加上这样一个参数，它本身这样一个 stack 的参数，它是放在 strategy 上的，参数是放在 stack 下面的，所以在这里加上一个 strategy，直接通过这种 parameter 的方式去来找到用户输入的一个参数。可以看到这样一种参数引用的方式其实是跟 Jason 或者是 struct 其实是完全一致的。
这一个字段叫做 Rolling update，但是这个字段它是有一个要求的。我们先将逻辑写上 Rolling update 等于 parameter date update strategy then slowly update。update strategy 的 type 等于 rolling update，因为这里的 Rolling update 的一个配置，它是一个可选的配置。所以我们还需要在这里加上一个判断配置不等于空， q 里面的不等于空的一个判断，下划线一个分隔符一个下划线，这个是 q 里面相当等于是 on defined GS 棉 on defined 这样一个 bottom 的定义，可以简单理解为 go 里面的new，表示这个字段不等于空。
我们来看一下 deployment，目前它的一个副本数是 5 杠5。我们也可以来看一下 deployment 它目前里面的这样一个 rolling update 的参数，因为目前其实没有配。 用的 update strategy 其实就是 K8S deployment 默认使用的这样一个 strategy。它的 type 是 Rolling update，它的 master next unavailable 都是25%。这个时候我们可以来修改一下我们的这样一个 plication。首先我们把镜像修改掉，我们同时来设置一下它的 a Rolling update 一个参数，我们把这镜像切换成 n g x，我们在这里 type 还是使用 update 把 Max search 改成50%。我们来重新 apply 一下这样一个 application。
可以看到它这里其实也是在不断地去更新 deployment 底下的一些port。使用 Rolling update 方式我们可以来看一下目前我们底层的 deployment。可以看到现在我参数其实已经被我们做了一个修改了，因为它 Max search 被我们改成了50%。
其实通过简单演示就教会了大家怎么样一种简单的方式，我们现有的 definition 体系去新增一些参数。其实大家可以也可以通过这样一个类似的体验去完成自己编写这一个 definition，或者直接去写构写我们 add on 体系里面的一些definition。现这一部分其实就是来教大家如何使用。我来玩转我们的 q 和 definition 体系。接下来我会再来介绍一下我们基于 q 和 definition 体系上面来做的一个插件生态。
这里我们会有一个在我们的博客里面，我们最近新发了一篇如何使用插件指南来轻松扩展你的平台专属能力。
这也是我们社区里的一个贡献的小伙伴新写的一篇博客，他这里面其实是一个非常详细的过程，来教你如何从 0 到 1 去完成你插件的一些构建。
首先其实这里有个图，我们可以看到左最左侧是我们的一个插件仓库，每一个插件它其实都由这几部分来组件。首先 main data 到 YAML，它里面其实就是我们的插件的一些原属性，它会有一些 a resources 或者是 template，这些作用其实的去渲染出一个 application。除了这些之外，因为这些部分它主要是为了去渲染 add on 的这样一个application。它还会有一些 definition 以及 UI schema 的一些额外的资源，这些资源也是会被一起随着 add on 部署。写了这样一个template，点 YAML 去帮你安装你想要的资源，其实虽然 add on 里面其实可以去集成非常多的一些资源，比如 Ham install 或者 Cooper Ctrl apply 也是一样可以完成的。一个是手动和一个自动的区别，加上definition， add down 体系就能够非常完美的去融合库菲拉本身的一个体系。 Adon 里面的一些资源完全的和社区里面内置的一些资源去进行一个编排和融合，以及部署。渲染完 add on 的一个 application 之后，在Meta data 的一个设置里面，是可以选择 add on 是要部署到多个集群，还是只部署到一个管控集群，这也是 i Dont 。
目前其实你可以支持你们用两种方式来去编写，第一种是 YAML 的形式，第二种是 q 的形式。确实 YAML 的一个形式，它看起来会比较简单，但是同时它也会丧失一些定制化能力。 q 的这样一种形式，其实在定制化方面做得比较好。我们接下来实际看一下我们的。我们以两个 Adon 为例，第一个YAML，第一个Adon，我们会以一个用 YAML 写的方式写的一个 Adon 来举例。第二个则是用 q 的方式来写的一个 add on。还是这样一个 catalog 的仓库。简单的介绍过的一个 cruise 的一个 add on，就是这个 add on，它就是一个压墨的方式去进行一个部署。 hand down 其实就比较简单，它的 Meta data 里面就声明了它的一些最基础的一个信息，以及它的依赖项。因为它 truth 的一个安装，它其实就是依赖于 helm 的一个安装，所以它 dependency 写的 Fox CD 可以看到它实际上它没有这样一个 resources 的文件夹。
如果是文件夹，其实它会最终把 resource 里面资源一起渲染成一个 application，它这里是直接写到 template 里面，它这个 application 是直接写死的。他第一步其实就是把这样一个 cruise 的 add on 通过 cruise 的这样一个resource，它的一个 controller 通过 helm 的方式去拉取起来。第二步是为他同时也给他创建一个资源拓扑的关系。除了安装，这里其实主要是负责安装，因为他其实就是把 cruise 的一个 controller 在集群里面去部署起来了。第二，除了安装之外，它这里还有个 definition 文件夹。首先它是这样一个 clone set 这样一个定义。可以看到它的一个类型是一个组件定义，这代表着你可以在组件里面使用 clone set 这样一个类型。我们也可以看到它的output，刚刚也解释了 output 在 component 里面是会被实际部署渲染完并且部署的一个资源。它这里 output 其实对应我们刚刚的所讲的 web service 来说，它这里其实就是把类型从 web serve 从 deployment 改成 clone set，这个 clone set 也是 cruise 里面特有的一个 CRD。
这些参数，比如这里 context 是酷威内置会预留的一个字段，你 context 点name，其实会去引用到 component 一个name。除了 con 用 context 去引用的一些特定参数之外，其他的一些参数都是来源于 parameter，只要是定义在 parameter 里面的一些，只要是 d 在 parameter 里面的一些参数，用户其实就可以在他所写的 application 点 YAML 里面通过 properties 来进行一个传输。除了 close set 之外，这里还有一个 image pool job 这样一个 workflow step definition。 workflow step definition 它就跟，controller， component 以及 trade definition 有略微的一个不同，因为在是我们会在我们的工作流当中使用这。 The step definition。并且我们其实内置了一些 o p 的方法，比如我们其实在这里就可以执行一些过程式的渲染。比如在这里第一步第一个字段就 parameter 这一个字段跟 component 和 tree 里面都是一样的。用户的一些输入。
第 2 步话，它这里使用了这样一个 OP 点 fly。 OP 点 fly 其实是 value 里面内置的一些 workflow 的操作符，通过操作符你就可以直接去将资源 apply 到集群当中。对于操作符其实也是有非常详细的文档，具体可以参考如何编写 workflow step definition 的一些文档。
除了 play 之外，其实你也可以在这里使用 OP ，HT， DP post 之类的来发送请求，又或者是 opinion a read 来从集群当中去读取一些资源，比如secret，之类的。甚至你也可以在这里去使用 OP 点 log 去打印一些日志，或者是进行一些状态的检查，或者是直接通过一些条件判断，让当前步骤进入失败的一个状态。这个就是 cruise 的这样一个 add on。
所以对于基础的插件训练来说，希望比较欢迎大家来通过这种 operator 的方式，直接将直接去贡献一些类似于这种 operator 的一些插件。比如可以参考 operate hub 点 Io。在这里其实你可以看到很多，多一些默认的operator，它其实跟 cruise 的一个形式都比较类似。如果它底层有 CRD，你可以给它写一些 definition 来完成这些资源的渲染，或者他直接去将这些 operator 去拉取起来，并且你还可以给他写一些 overflow step，或者完成一些纯安装。这些 operator 也是有简单的，也有比较难的。比如这里有一个 trivial operator。我们接下来看一下 trivia operator 的一个例子。 training 实际上是一个用来做镜像检查的这样一个工具。我们可以看一下。可以看到这里的文件其实都是一些 q 的文件，它是用一个纯 q 的形式来完成的这样一个 add on。它这个是用一个纯 q 的形式来完成的这样一个 add on。除了基本的 Meta data 之外，它这里会 depend 除了一个 flag CD，还会去 depend 一个 prometheus 的server。这是因为 tribute operator。它的功能其实是首先将车友 free 的部署到集群当中，他会不断地去采集集群里面的一些镜像信息，做一些分析，看一下，检测一下有没有一些风险。如果有风险，它会把风险的信息直接上传到普罗米修斯的 metrics 里面。所以它这里会将 dependency 设置一个普罗米修斯 server。我们可以来看一下它这里的 template 点。 q 首先它会有需要有一个 package main。这个 package main 意味着如果你加了这样一个包名，我们会将所有带有包名的一些 q 文件一起渲染，这样你就可以分文件去管理，同时它最终会将资源渲染到一起。
可以看到它这里的 output 实际上也是一个application，跟刚刚看到 YAML 方式其实是比较类似的，但是有一点不同，这里可以直接通过参数的一个方式，比如在这里这样一个纯 v n s 的一个 name space，它其实它的名字是可以通过参数化来进行渲染的。在 private 点 q 里面其实是将可定式的化的一个参数去暴露给用户。像比如去完成 Availa add on enable Graphena 的时候，其实也是用了一个参数，叫做 service type，等于 node port。可以来看一下 Grafana 这一边，它这里其实是使用了将 service type 这样一个参数直接暴露出来，它默认是一个 class i p 的形式。
在 enable 的时候可以通过参数的传入直接修改 Graphena 里面的一个 service 的类型，比如修改为 node pull，就可以直接访问了，不需要再 pull forward 原本 task IP。在趣味这样一个 add on 体系当中，我们首先是做了一些 reporter tag 这样一些参数的渲染，然后在这里实际上是把这同样还是把 application 去进行一个资源渲染。它。这里引用了一个变量，叫 tribute helm。 tribuhelm 是定义在哪一些？是定义在 resources 里面，我们会将所有 resources 里面的文件和外面的这些 q 文件一并进行一个渲染。当然首先你需要有 package map。我们可以看到在这里其实就是一个 Travi helm 的定义，它实际上也是一个 component 一个类型，它的 type 就是helm。这 properties 里面其实使用的就是，就是 helm 组件，它需要的一些参数，比如， Repo type URL，包括它 help 底下对应的一些values。 从 resources 到 template 再到 parameter，主要是为了去做 add on 的一个资源的一些安装。除了本身资源安装之外，其实这里还有个definitions。 definition 可能看起来都比较复杂，首先它是一个 overflow step 的definition，我们在制作这样一个 trivey 的一个 operator 的 add on 的时候，我们希望做希望它能达成一个什么样的效果。对于一个做镜像检查的插件来说，我们当然是希望我们在前面部署完一个组件。比如它底层用的是一个 n g x on privilege 这样一个带有风险的镜像的时候，我们下一个步骤可以去首先去检查这样一个镜像它有没有风险，如果有风险，我们就可以将它这样一个结果直接通过消息，通过 slack 消息或者钉钉消息直接发送到我们的一个消息群组里面。这样我们就可以实时地去查看到这样一个镜像它有没有风险。他在这里就需要做一些操作。首先这还是在我们的 template 里面。首先我们需要去进行一个请求，这个请求其实是一个 trivies trivia 它本身所在 service 的一个地址，其实用户一般来说也是不知道这个地址的，所以我们可以看一下 privater 点 URL。其实前面我们其实是使用 Kubernetes 的一个 class to service 的方式，直接去帮用户去找到这样一个车位的地址。如果这个地址用户是希望使用外部的一个垂类地址，其实也在这里使用一个 option 来分隔开来。用户也可以进行一个自定义。当然默认用户可以不用填直接。会使用 add on 它部署的 trivy。它的一个 service 地址。有一点 HTV guide，这是刚刚所说的。可以在 workflow step 里面使用我们酷威拉提供的一些内置的 action。在这里其实就会对这样一个地址去发送一个请求，并且可以拿到请求的一个 deep 的 response。在这里把 response 直接付给了 data。
接下来，因为其实是需要去实地实际地从它一堆的 metrics 里面去查到我们这样一个镜像到底有没有风险。所以在这里可其实是可以用一个正则匹配的。这里我们是用了一个 radics，直接是使用 q 本身的这样一个 regix 包。去查一下有没有信息，还没查到。也有可能是因为我们现在这个区域他正在做一个镜像校验，他还没有做完。这个时候我们也不能直接返回。所以在这里可以加一个 conditional weight，并且 continued in false OP 点。 conditional weight 会让当前 step 处于一个等待的状态，所以它会一直在执行，直到它 continue 等于true，或者是它没有走到这个位的，在这里它就会不断地去执行。然后，不。这里其实是走了 2 个判断，第一个判断是没有找到这样一个结果，他可能还没执行完。如果找到了这样一个结果，这里的 q 看起来很复杂，但实际上其实做了一些语句的转换。
因为我们最终希望我们拿能够拿到一个 message。 message 里面其实就会涵盖比如你这一次镜像检查的一个结果，包括这样一次，这样一次有没有发现哪些 CBE。
其实在这里通过一个数组的方式，并且直接把这些数组转换成 string 放到 message 里面。这就是一个较为复杂的这样一个 trivy 的 definition 的制作的过程。也可以直接参考这里的 operator hub 到 i o网页，里面其实有很多比较官方的一些 KMS operator 的方式。 operator 的一些组件在这里，而且这里面大部分的组件，比如 chaos blade operator，他基本上都会提供一个 helm 安装的模式。首先将 pre operator 进行安装，你完全可以像我刚刚使用的 cruise 的例子来一样，直接在我们的 add on 的一个仓库里面去新增这样一个 chaos blade operator，并且使用 helm 的方式来完成一个安装。如果它底层还有一些 CRD 资源，或者你对他插件资源本身有比较深入的一个了解，你知道他使用这样一个插件的场景是什么。你也可以来使用 component definition， trade definition 或者是 overflow step 来进行一个高度抽象可定制化。这样，如果你只是完成了前面所说这些安装这样一些 helm charge 的一些操作 add on。它可能基本上就是处于一个测试的用的一个状况状态。因为实际上当我们 enable 这样一种 add on 的时候，我们只是像完成 helm install 一样去把插件给安装起来。它底层所有的所拥有的一些实践，包括可定制化的一些实现，我们其实都没有在这挨档里面体系体现。如果 add on，它制作得十分完整，比如带了这些definition，并且有些 example with me 等等。
你 add on 就可以从 experimental 这样一个实验性的状态来晋升到我们官方的这样一个插件库当中。也期待大家能够给这个社区来贡献更多的一个 i down。来贡献 i down 其实也是一个非常好的机会去来帮助大家来实际接触这样一个开源社区的玩法。所有的文档其实都可以在我们 KUbeVela的一个官方文档里面去查看，包括你想要，大家可能关心比较是开发者手册。首先插件系统，这里面其实有非常详细的如何制作自己插件的这样一个规范。当你想要贡献的时候，这里的贡献指南也会有些 code contribution guide 等等。
