如何在 20 分钟内给你的 K8s PaaS 上线一个新功能？

时间  2020-12-24
标签 nginx git github web json api 数组 restful 架构 app 栏目 云服务 繁體版
原文   原文链接

头图.png 做者 | 孙健波（天元） 来源|阿里巴巴云原生公众号nginx

上个月，KubeVela 正式发布了， 做为一款简单易用且高度可扩展的应用管理平台与核心引擎，能够说是广大平台工程师用来构建本身的云原生 PaaS 的神兵利器。 那么本文就以一个实际的例子，讲解一下如何在 20 分钟内，为你基于 KubeVela 的 PaaS “上线“一个新能力。git

在正式开始本文档的教程以前，请确保你本地已经正确安装了 KubeVela 及其依赖的 K8s 环境。github

KubeVela 扩展的基本结构

KubeVela 的基本架构如图所示：web

1.png

简单来讲，KubeVela 经过添加 Workload Type 和 Trait 来为用户扩展能力，平台的服务提供方经过 Definition 文件注册和扩展，向上经过 Appfile 透出扩展的功能。官方文档中也分别给出了基本的编写流程，其中 2 个是 Workload 的扩展例子，一个是 Trait 的扩展例子：json

咱们以一个内置的 WorkloadDefinition 为例来介绍一下 Definition 文件的基本结构：api

apiVersion: core.oam.dev/v1alpha2
kind: WorkloadDefinition
metadata:
  name: webservice
  annotations:
    definition.oam.dev/description: "`Webservice` is a workload type to describe long-running, scalable, containerized services that have a stable network endpoint to receive external network traffic from customers.
    If workload type is skipped for any service defined in Appfile, it will be defaulted to `Web Service` type."
spec:
  definitionRef:
    name: deployments.apps
  extension:
    template: |
      output: {
          apiVersion: "apps/v1"
          kind:       "Deployment"
          spec: {
              selector: matchLabels: {
                  "app.oam.dev/component": context.name
              }
              template: {
                  metadata: labels: {
                      "app.oam.dev/component": context.name
                  }
                  spec: {
                      containers: [{
                          name:  context.name
                          image: parameter.image
                          if parameter["cmd"] != _|_ {
                              command: parameter.cmd
                          }
                          if parameter["env"] != _|_ {
                              env: parameter.env
                          }
                          if context["config"] != _|_ {
                              env: context.config
                          }
                          ports: [{
                              containerPort: parameter.port
                          }]
                          if parameter["cpu"] != _|_ {
                              resources: {
                                  limits:
                                      cpu: parameter.cpu
                                  requests:
                                      cpu: parameter.cpu
                              }}
                      }]
              }}}
      }
      parameter: {
          // +usage=Which image would you like to use for your service
          // +short=i
          image: string

          // +usage=Commands to run in the container
          cmd?: [...string]

          // +usage=Which port do you want customer traffic sent to
          // +short=p
          port: *80 | int
          // +usage=Define arguments by using environment variables
          env?: [...{
              // +usage=Environment variable name
              name: string
              // +usage=The value of the environment variable
              value?: string
              // +usage=Specifies a source the value of this var should come from
              valueFrom?: {
                  // +usage=Selects a key of a secret in the pod's namespace
                  secretKeyRef: {
                      // +usage=The name of the secret in the pod's namespace to select from
                      name: string
                      // +usage=The key of the secret to select from. Must be a valid secret key
                      key: string
                  }
              }
          }]
          // +usage=Number of CPU units for the service, like `0.5` (0.5 CPU core), `1` (1 CPU core)
          cpu?: string
      }

乍一看挺长的，好像很复杂，可是不要着急，其实细看之下它分为两部分：数组

  • 不含扩展字段的 Definition 注册部分
  • 供 Appfile 使用的扩展模板（CUE Template）部分

咱们拆开来慢慢介绍，其实学起来很简单。restful

不含扩展字段的 Definition 注册部分

apiVersion: core.oam.dev/v1alpha2
kind: WorkloadDefinition
metadata:
  name: webservice
  annotations:
    definition.oam.dev/description: "`Webservice` is a workload type to describe long-running, scalable, containerized services that have a stable network endpoint to receive external network traffic from customers.
    If workload type is skipped for any service defined in Appfile, it will be defaulted to `Web Service` type."
spec:
  definitionRef:
    name: deployments.apps

这一部分满打满算 11 行，其中有 3 行是在介绍 webservice 的功能，5行是固定的格式。只有 2 行是有特定信息：架构

definitionRef:
    name: deployments.apps

这两行的意思表明了这个 Definition 背后用的 CRD 名称是什么，其格式是 <resources>.<api-group>。了解 K8s 的同窗应该知道 K8s 中比较经常使用的是经过 api-group, version 和 kind 定位资源，而 kind 在 K8s restful API 中对应的是 resources。以你们熟悉 Deployment 和 ingress 为例，它的对应关系以下：app

image.png

这里补充一个小知识，为何有了 kind 还要加个 resources 的概念呢？ 由于一个 CRD 除了 kind 自己还有一些像 status，replica 这样的字段但愿跟 spec 自己解耦开来在 restful API 中单独更新， 因此 resources 除了 kind 对应的那一个，还会有一些额外的 resources，如 Deployment 的 status 表示为 deployments/status。

因此相信聪明的你已经明白了不含 extension 的状况下，Definition 应该怎么写了，最简单的就是根据 K8s 的资源组合方式拼接一下，只要填下面三个尖括号的空格就能够了。

apiVersion: core.oam.dev/v1alpha2
kind: WorkloadDefinition
metadata:
  name: <这里写名称>
spec:
  definitionRef:
    name: <这里写resources>.<这里写api-group>

针对运维特征注册（TraitDefinition）也是这样。

apiVersion: core.oam.dev/v1alpha2
kind: TraitDefinition
metadata:
  name: <这里写名称>
spec:
  definitionRef:
    name: <这里写resources>.<这里写api-group>

因此把 Ingress 做为 KubeVela 的扩展写进去就是：

apiVersion: core.oam.dev/v1alpha2
kind: TraitDefinition
metadata:
  name:  ingress
spec:
  definitionRef:
    name: ingresses.networking.k8s.io

除此以外，TraitDefinition 中还增长了一些其余功能模型层功能，如：

  • appliesToWorkloads: 表示这个 trait 能够做用于哪些 Workload 类型。
  • conflictWith： 表示这个 trait 和哪些其余类型的 trait 有冲突。
  • workloadRefPath： 表示这个 trait 包含的 workload 字段是哪一个，KubeVela 在生成 trait 对象时会自动填充。 ...

这些功能都是可选的，本文中不涉及使用，在后续的其余文章中咱们再给你们详细介绍。

因此到这里，相信你已经掌握了一个不含 extensions 的基本扩展模式，而剩下部分就是围绕 CUE 的抽象模板。

供 Appfile 使用的扩展模板（CUE Template）部分

对 CUE 自己有兴趣的同窗能够参考这篇 CUE 基础入门 多作一些了解，限于篇幅本文对 CUE 自己不详细展开。

你们知道 KubeVela 的 Appfile 写起来很简洁，可是 K8s 的对象是一个相对比较复杂的 YAML，而为了保持简洁的同时又不失可扩展性，KubeVela 提供了一个从复杂到简洁的桥梁。 这就是 Definition 中 CUE Template 的做用。

CUE 格式模板

让咱们先来看一个 Deployment 的 YAML 文件，以下所示，其中不少内容都是固定的框架（模板部分），真正须要用户填的内容其实就少许的几个字段（参数部分）。

apiVersion: apps/v1
kind: Deployment
meadata:
  name: mytest
spec:
  template:
    spec:
      containers:
      - name: mytest
        env:
        - name: a
          value: b
        image: nginx:v1
    metadata:
      labels:
        app.oam.dev/component: mytest
  selector:
    matchLabels:
      app.oam.dev/component: mytest

在 KubeVela 中，Definition 文件的固定格式就是分为 output 和 parameter 两部分。其中output中的内容就是“模板部分”，而 parameter 就是参数部分。

那咱们来把上面的 Deployment YAML 改写成 Definition 中模板的格式。

output: {
    apiVersion: "apps/v1"
    kind:       "Deployment"
    metadata: name: "mytest"
    spec: {
        selector: matchLabels: {
            "app.oam.dev/component": "mytest"
        }
        template: {
            metadata: labels: {
                "app.oam.dev/component": "mytest"
            }
            spec: {
                containers: [{
                    name:  "mytest"
                    image: "nginx:v1"
                    env: [{name:"a",value:"b"}]
                }]
            }}}
}

这个格式跟 json 很像，事实上这个是 CUE 的格式，而 CUE 自己就是一个 json 的超集。也就是说，CUE的格式在知足 JSON 规则的基础上，增长了一些简便规则， 使其更易读易用：

  • C 语言的注释风格。
  • 表示字段名称的双引号在没有特殊符号的状况下能够缺省。
  • 字段值结尾的逗号能够缺省，在字段最后的逗号写了也不会出错。
  • 最外层的大括号能够省略。

CUE 格式的模板参数--变量引用

编写好了模板部分，让咱们来构建参数部分，而这个参数其实就是变量的引用。

parameter: {
    name: string
    image: string
}
output: {
    apiVersion: "apps/v1"
    kind:       "Deployment"
    spec: {
        selector: matchLabels: {
            "app.oam.dev/component": parameter.name
        }
        template: {
            metadata: labels: {
                "app.oam.dev/component": parameter.name
            }
            spec: {
                containers: [{
                    name:  parameter.name
                    image: parameter.image
                }]
            }}}
}

如上面的这个例子所示，KubeVela 中的模板参数就是经过 parameter 这个部分来完成的，而 parameter 本质上就是做为引用，替换掉了 output 中的某些字段。

完整的 Definition 以及在 Appfile 使用

事实上，通过上面两部分的组合，咱们已经能够写出一个完整的 Definition 文件：

apiVersion: core.oam.dev/v1alpha2
kind: WorkloadDefinition
metadata:
  name: mydeploy
spec:
  definitionRef:
    name: deployments.apps
  extension:
    template: |
        parameter: {
            name: string
            image: string
        }
        output: {
            apiVersion: "apps/v1"
            kind:       "Deployment"
            spec: {
                selector: matchLabels: {
                    "app.oam.dev/component": parameter.name
                }
                template: {
                    metadata: labels: {
                        "app.oam.dev/component": parameter.name
                    }
                    spec: {
                        containers: [{
                            name:  parameter.name
                            image: parameter.image
                        }]
                    }}}
        }

为了方便调试，通常状况下能够预先分为两个文件，一部分放前面的 yaml 部分，假设命名为 def.yaml 如：

apiVersion: core.oam.dev/v1alpha2
kind: WorkloadDefinition
metadata:
  name: mydeploy
spec:
  definitionRef:
    name: deployments.apps
  extension:
    template: |

另外一个则放 cue 文件，假设命名为 def.cue ：

parameter: {
    name: string
    image: string
}
output: {
    apiVersion: "apps/v1"
    kind:       "Deployment"
    spec: {
        selector: matchLabels: {
            "app.oam.dev/component": parameter.name
        }
        template: {
            metadata: labels: {
                "app.oam.dev/component": parameter.name
            }
            spec: {
                containers: [{
                    name:  parameter.name
                    image: parameter.image
                }]
            }}}
}

先对 def.cue 作一个格式化，格式化的同时 cue 工具自己会作一些校验，也能够更深刻的经过 cue 命令作调试:

cue fmt def.cue

调试完成后，能够经过脚本把这个 yaml 组装：

./hack/vela-templates/mergedef.sh def.yaml def.cue > mydeploy.yaml

再把这个 yaml 文件 apply 到 K8s 集群中。

$ kubectl apply -f mydeploy.yaml
workloaddefinition.core.oam.dev/mydeploy created

一旦新能力 kubectl apply 到了 Kubernetes 中，不用重启，也不用更新，KubeVela 的用户能够马上看到一个新的能力出现而且可使用了：

$ vela worklaods
Automatically discover capabilities successfully ✅ Add(1) Update(0) Delete(0)

TYPE           CATEGORY    DESCRIPTION
+mydeploy      workload    description not defined

NAME        DESCRIPTION
mydeploy    description not defined

在 Appfile 中使用方式以下：

name: my-extend-app
services:
  mysvc:
    type: mydeploy
    image: crccheck/hello-world
    name: mysvc

执行 vela up 就能把这个运行起来了：

$ vela up -f docs/examples/blog-extension/my-extend-app.yaml
Parsing vela appfile ...
Loading templates ...

Rendering configs for service (mysvc)...
Writing deploy config to (.vela/deploy.yaml)

Applying deploy configs ...
Checking if app has been deployed...
App has not been deployed, creating a new deployment...
✅ App has been deployed 🚀🚀🚀
    Port forward: vela port-forward my-extend-app
             SSH: vela exec my-extend-app
         Logging: vela logs my-extend-app
      App status: vela status my-extend-app
  Service status: vela status my-extend-app --svc mysvc

咱们来查看一下应用的状态，已经正常运行起来了（HEALTHY Ready: 1/1）：

$ vela status my-extend-app
About:

  Name:          my-extend-app
  Namespace:     env-application
  Created at:    2020-12-15 16:32:25.08233 +0800 CST
  Updated at:    2020-12-15 16:32:25.08233 +0800 CST

Services:

  - Name: mysvc
    Type: mydeploy
    HEALTHY Ready: 1/1

Definition 模板中的高级用法

上面咱们已经经过模板替换这个最基本的功能体验了扩展 KubeVela 的全过程，除此以外，可能你还有一些比较复杂的需求，如条件判断，循环，复杂类型等，须要一些高级的用法。

结构体参数

若是模板中有一些参数类型比较复杂，包含结构体和嵌套的多个结构体，就可使用结构体定义。

  1. 定义一个结构体类型，包含 1 个字符串成员、1 个整型和 1 个结构体成员。
#Config: {
 name:  string
 value: int
 other: {
   key: string
   value: string
 }
}
  1. 在变量中使用这个结构体类型，并做为数组使用。
parameter: {
 name: string
 image: string
 config: [...#Config]
}
  1. 一样的目标中也是以变量引用的方式使用。
output: {
   ...
         spec: {
             containers: [{
                 name:  parameter.name
                 image: parameter.image
                 env: parameter.config
             }]
         }
    ...
}
  1. Appfile 中的写法就是按照 parameter 定义的结构编写。
name: my-extend-app
services:
mysvc:
 type: mydeploy
 image: crccheck/hello-world
 name: mysvc
 config:
 - name: a
   value: 1
   other:
     key: mykey
     value: myvalue

条件判断

有时候某些参数加仍是不加取决于某个条件：

parameter: {
    name:   string
    image:  string
    useENV: bool
}
output: {
    ...
    spec: {
        containers: [{
            name:  parameter.name
            image: parameter.image
            if parameter.useENV == true {
                env: [{name: "my-env", value: "my-value"}]
            }
        }]
    }
    ...
}

在 Appfile 就是写值。

name: my-extend-app
services:
  mysvc:
    type: mydeploy
    image: crccheck/hello-world
    name: mysvc
    useENV: true

可缺省参数

有些状况下参数可能存在也可能不存在，即非必填，这个时候通常要配合条件判断使用，对于某个字段不存在的状况，判断条件是是 _variable != _|_。

parameter: {
    name: string
    image: string
    config?: [...#Config]
}
output: {
    ...
    spec: {
        containers: [{
            name:  parameter.name
            image: parameter.image
            if parameter.config != _|_ {
                config: parameter.config
            }
        }]
    }
    ...
}

这种状况下 Appfile 的 config 就非必填了，填了就渲染，没填就不渲染。

默认值

对于某些参数若是但愿设置一个默认值，能够采用这个写法。

parameter: {
    name: string
    image: *"nginx:v1" | string
}
output: {
    ...
    spec: {
        containers: [{
            name:  parameter.name
            image: parameter.image
        }]
    }
    ...
}

这个时候 Appfile 就能够不写 image 这个参数，默认使用 "nginx:v1"：

name: my-extend-app
services:
  mysvc:
    type: mydeploy
    name: mysvc

循环

Map 类型的循环

parameter: {
    name:  string
    image: string
    env: [string]: string
}
output: {
    spec: {
        containers: [{
            name:  parameter.name
            image: parameter.image
            env: [
                for k, v in parameter.env {
                    name:  k
                    value: v
                },
            ]
        }]
    }
}

Appfile 中的写法：

name: my-extend-app
services:
  mysvc:
    type: mydeploy
    name:  "mysvc"
    image: "nginx"
    env:
      env1: value1
      env2: value2

数组类型的循环

parameter: {
    name:  string
    image: string
    env: [...{name:string,value:string}]
}
output: {
  ...
     spec: {
        containers: [{
            name:  parameter.name
            image: parameter.image
            env: [
                for _, v in parameter.env {
                    name:  v.name
                    value: v.value
                },
            ]
        }]
    }
}

Appfile 中的写法：

name: my-extend-app
services:
  mysvc:
    type: mydeploy
    name:  "mysvc"
    image: "nginx"
    env:
    - name: env1
      value: value1
    - name: env2
      value: value2

KubeVela 内置的 context 变量

你们可能也注意到了，咱们在 parameter 中定义的 name 每次在 Appfile中 实际上写了两次，一次是在 services 下面（每一个service都以名称区分）， 另外一次则是在具体的name参数里面。事实上这里重复的不该该由用户再写一遍，因此 KubeVela 中还定义了一个内置的 context，里面存放了一些通用的环境上下文信息，如应用名称、秘钥等。 直接在模板中使用 context 就不须要额外增长一个 name 参数了， KubeVela 在运行渲染模板的过程当中会自动传入。

parameter: {
    image: string
}
output: {
  ...
    spec: {
        containers: [{
            name:  context.name
            image: parameter.image
        }]
    }
  ...
}

KubeVela 中的注释加强

KubeVela 还对 cuelang 的注释作了一些扩展，方便自动生成文档以及被 CLI 使用。

parameter: {
          // +usage=Which image would you like to use for your service
          // +short=i
          image: string

          // +usage=Commands to run in the container
          cmd?: [...string]
       ...
      }

其中，+usgae 开头的注释会变成参数的说明，+short 开头的注释后面则是在 CLI 中使用的缩写。

总结

本文经过实际的案例和详细的讲述，为你介绍了在 KubeVela 中新增一个能力的详细过程与原理，以及能力模板的编写方法。

这里你可能还有个疑问，平台管理员这样添加了一个新能力后，平台的用户又该怎么能知道这个能力怎么使用呢？其实，在 KubeVela 中，它不只能方便的添加新能力，它还能自动为“能力”生成 Markdown 格式的使用文档！ 不信，你能够看下 KubeVela 自己的官方网站，全部在 References/Capabilities 目录下能力使用说明文档（好比这个），全都是根据每一个能力的模板自动生成的哦。 最后，欢迎你们写一些有趣的扩展功能，提交到 KubeVela 的社区仓库中来。

若是你有任何疑问，欢迎钉钉搜索群号：23310022 加入交流群。

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程