KubeVela篇06：Kubevela Addon插件安装原理

addon支持从本地、git仓库、helm chart仓库安装，最终原理都相同，因此我们以本地安装为例。

完整流程如下： kubevela addon安装原理

从指定目录读取一个完整的addon安装包。
根据metadata.yaml配置文件，校验插件要求的kubevela、k8s的版本，不满足版本要求则终止安装。
根据metadata.yaml配置文件，如果需要依赖其它插件，且有依赖的插件没安装，则终止安装，并提示需要先安装其它依赖插件。
生成Application，通过Application安装插件：
1. 如果提供template.cur或者template.yaml，则通过模版生成Application，没有则直接创建一个Application。不管模版配置的namespace、name是什么，都会被覆盖为vela-system和addon-\${addon的名称}。
2. 如果metadata.yaml声明了needNamespace，则为每个needNamespace生成一个类型为raw的组件，用于在管控集群下当namespace不存在时创建namespace。
3. resources目录下的组件渲染。
4. 如果metadata.yaml声明了deployTo，runtime-cluster配置为true，自动为Application生成topology策略：
  1. 如果支持vela addon enable命令指定了安装的集群，则生成部署到指定的子集群的topoogy策略。
  2. 否则生成部署到所有子集群的topoogy策略。
5. 将Application apply到管控集群，由application controller接管完成安装。
另外，如果插件有模块定义，则将模块定义渲染（cue，yaml不用渲染）成ComponentDefinition/TraitDefinitions /WorkflowStepDefinitions资源对象，apply到管控集群，然后由对应的controller完成安装逻辑。
如果插件有声明配置模版（config-template），为每个配置模版生成ConfigMap apply到管控集群，提供给vela config create命令使用。
如果需要为VelaUX提供schema，渲染成ConfigMap apply到管控集群。
用一个Secret资源对象存储本次命令附加的参数。
最后等待Application安装完成。

terraform插件的安装过程

一个terraform provider插件也是一个addon插件，但terraform provider插件的安装比较简单，主要是模块定义的apply。

这里举一个比较复杂一点Addon插件，说明其Application的生成和安装过程，以terraform插件为例。

terraform插件的resources目录的terraform-controller.cue描述了一个helm类型的组件。

terraform addon插件

    output: {
            type: "helm"
            properties: {
                    repoType: "helm"
                    url:      "https://charts.kubevela.net/addons"
                    chart:    "terraform-controller"
                    version:  "0.7.10"
                    if parameter.values != _|_ {
                            values: parameter.values
                    }
            }
    }

parameter.cue可以配置helm的values：

    parameter: {
            values: #values
    }
    
    #values: {
            terraformImage: *"oamdev/docker-terraform:1.1.4" | string 
    }

这里通过修改parameter.cue，将terraformImage指定为默认使用1.1.4版本，当然也可以在执行插件安装命令的时候指定，例如：

    veal addon enable terraform terraformImage=oamdev/docker-terraform:1.1.4

最终渲染成的Application是这样的：

    apiVersion: core.oam.dev/v1beta1
    kind: Application
    metadata:
      name: addon-terraform
      namespace: vela-system
    spec:
      components:
        - name: terraform-controller
          properties:
            chart: terraform-controller
            repoType: helm
            url: https://charts.kubevela.net/addons
            values:
              terraformImage: oamdev/docker-terraform:1.1.4
            version: 0.7.10
          type: helm

kubevela会为terraform-controller组件生成一个apply-component类型的工作流步骤，然后执行工作流步骤会安装terraform-controller组件，helm类型的组件安装过程这里不展开。

terraform provider插件的安装过程

terraform provider插件的安装过程重点关注的是模块定义的安装。terraform provider插件的definitions目录主要是我们根据云资源terraform modules生成的一个个ComponentDefinition。

定义terraform类型的组件可以配置以下字段：（来源ComponentDefinition这个CRD）

    terraform:
      description: >-
        Terraform is the struct to describe cloud resources managed by Hashicorp
        Terraform
      properties:
        configuration:
          description: Configuration is Terraform Configuration
          type: string
        customRegion:
          description: >-
            Region is cloud provider's region. It will override the region in the
            region field of ProviderReference
          type: string
        deleteResource:
          default: true
          description: >-
            DeleteResource will determine whether provisioned cloud resources will
            be deleted when CR is deleted
          type: boolean
        gitCredentialsSecretReference:
          description: >-
            GitCredentialsSecretReference specifies the reference to the secret
            containing the git credentials
          properties:
            name:
              description: name is unique within a namespace to reference a secret resource.
              type: string
            namespace:
              description: >-
                namespace defines the space within which the secret name must be
                unique.
              type: string
          type: object
          x-kubernetes-map-type: atomic
        path:
          description: >-
            Path is the sub-directory of remote git repository. It's valid when
            remote is set
          type: string
        providerRef:
          description: ProviderReference specifies the reference to Provider
          properties:
            name:
              description: Name of the referenced object.
              type: string
            namespace:
              default: default
              description: Namespace of the referenced object.
              type: string
          required:
            - name
          type: object
        type:
          default: hcl
          description: 'Type specifies which Terraform configuration it is, HCL or JSON syntax'
          enum:
            - hcl
            - json
            - remote
          type: string
        writeConnectionSecretToRef:
          description: >-
            WriteConnectionSecretToReference specifies the namespace and name of a
            Secret to which any connection details for this managed resource should
            be written. Connection details frequently include the endpoint,
            username, and password required to connect to the managed resource.
          properties:
            name:
              description: Name of the secret.
              type: string
            namespace:
              description: Namespace of the secret.
              type: string
          required:
            - name
          type: object
      required:
        - configuration
      type: object

其中configuration字段即可以直接配置terraform代码，也可以配置成一个git仓库地址。当type为remote时，configuration必须是配置一个远程代码仓库地址；而当type为hcl时，configuration配置为terraform代码。

当type为remote时用到的几个属性：

path：从远程代码仓库拉取代码下来后，读取哪个目录下的terraform代码。
gitCredentialsSecretReference：引用存储了ssh拉取代码所需的私钥和known_hosts的Secret资源对象，我们需要自己创建出这个Secret资源对象。

例如前面我们编写terraform-mycloud插件生成的mycloud-vpc组件，就使用了hcl，现在我们将其换成remote方式。

先要创建一个git仓库:terraform-mycloud-modules

    -- terraform-mycloud-modules
       -- vpc
          -- main.tf

修改terraform-mycloud-vpc.yaml，type改为remote，configuration配置成git仓库地址，因为是引用main.tf，所以路径配置为vpc，然后私有仓库要求配置gitCredentialsSecretReference。

    apiVersion: core.oam.dev/v1beta1
    kind: ComponentDefinition
    metadata:
      annotations:
        definition.oam.dev/description: Terraform configuration for Mycloud VPC
      creationTimestamp: null
      labels:
        type: terraform
      name: mycloud-vpc
      namespace: vela-system
    spec:
      schematic:
        terraform:
          configuration: [email protected]:wujiuye/terraform-mycloud-modules.git
          path: vpc
          type: remote
          gitCredentialsSecretReference: 
            name: gitlab-ssh-key-secret
            namespace: default
      workload:
        definition:
          apiVersion: terraform.core.oam.dev/v1beta2
          kind: Configuration
    status: {}

在插件安装过程中，mycloud-vpc组件会apply到管控集群，之后会由一个*componentdefinition_ controller处理组件安装逻辑*。componentdefinition_controller主要是将组件渲染成指定的工作负载类型的资源对象。mycloud-vpc会被渲染成Configuration资源对象，apply到管控集群。

如果terraform.type是remote，kubevela会拉取代码，否则如果是hcl，不需要从远程拉取代码。正常kubevela不需要关心terraform属性配置了什么，只管渲染结果就好，但为什么kubevela还要去拉取代码下来。这是因为kubevela需要解析ComponentDefinition，解析出组件需要输入哪些参数，以及会输出哪些参数，用于生成文档，能够通过vela show 命令查看到，也就是便于使用，另外也能达到检验的目的。

例如vela show mycloud-vpc --web（–web：通过渲染成html查看）

插件描述

vela show mycloud-vpc 命令显示的结果来源于component-schema-mycloud-vpc这个ConfigMap而来，这个ConfigMap由*componentdefinition_controller创建。

KubeVela篇06：Kubevela Addon插件安装原理

terraform插件的安装过程

terraform provider插件的安装过程

文章推荐