关于云原生:KubeVela-17-版本解读接管你的已有工作负载

KubeVela 1.7 版本曾经正式公布一段时间，在此期间 KubeVela 正式升级成为了 CNCF 的孵化我的项目，开启了一个新的里程碑。而 KubeVela 1.7 自身也是一个转折点，因为 KubeVela 从一开始就专一于可扩大体系的设计，对于控制器外围性能的需要也开始逐渐收敛，咱们开始腾出手来更加专一于用户体验、易用性、以及性能。在本文中，咱们将重点筛选 1.7 版本中的工作负载接管、性能优化等亮点性能进行介绍。

接管你的工作负载

接管已有的工作负载始终是社区里呼声很高的需要，其场景也十分明确，即曾经存在的工作负载能够天然的迁徙到 OAM 标准化体系中，被 KubeVela 的利用交付管制面对立治理，复用 VelaUX 的 UI 控制台性能，包含社区的一系列运维特色、工作流步骤以及丰盛的插件生态。在 1.7 版本中，咱们正式公布了该性能，在理解具体怎么操作之前，让咱们先对其运行模式有个根本理解。

“只读”和“接管”两种模式

为了适应不同的应用场景，KubeVela 提供了两种模式来满足你对立治理的需要，一种是只读模式，实用于外部曾经有自建平台的零碎，这些零碎对于存量业务仍旧具备次要的控制能力，而新的基于 KubeVela 的平台零碎能够只读式的对立观测到这些利用。另一种是接管模式，实用于想间接做迁徙的用户，能够把已有的工作负载主动的接管到 KubeVela 体系中，并且齐全对立治理。

• “只读”（read-only）模式顾名思义，它不会对资源有任何“写”操作。应用只读模式纳管的工作负载，能够通过 KubeVela 的工具集（如 CLI、VelaUX）做可视化，满足对立查看、可观测方面的需要。与此同时，只读模式下生成的纳管利用被删除时，底下的工作负载资源也不会被回收。而底层工作负载被其余控制器会人为批改时，KubeVela 也能够察看到这些变动。
• “接管”（take-over）模式意味着底层的工作负载会被 KubeVela 齐全治理，跟其余间接通过 KubeVela 体系创立进去的工作负载一样，工作负载的更新、删除等生命周期将齐全由 KubeVela 利用体系管制。默认状况下，其余系统对工作负载的批改也就不再失效，会被 KubeVela 面向终态的管制循环改回来，除非你退出了其余的管理策略（如 apply-once）。

而申明接管模式的办法则应用 KubeVela 的策略（policy）体系，如下所示：

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: read-only
spec:
  components:
    - name: nginx
      type: webservice
      properties:
        image: nginx
  policies:
    - type: read-only
      name: read-only
      properties:
        rules:
          - selector:
              resourceTypes: ["Deployment"]

在“read-only”策略中，咱们定义了多种只读规定，如样例中只读选择器命中的资源是“Deployment”，那就意味着只有对 Deployment 的资源是只读的，咱们仍旧能够通过运维特色创立和批改“Ingress”、“Service”等资源，而应用“scaler”运维特色对 Deployment 的实例数做批改则不会失效。

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: take-over
spec:
  components:
    - name: nginx-take-over
      type: k8s-objects
      properties:
        objects:
          - apiVersion: apps/v1
            kind: Deployment
            metadata:
              name: nginx
      traits:
        - type: scaler
          properties:
            replicas: 3
  policies:
    - type: take-over
      name: take-over
      properties:
        rules:
          - selector:
              resourceTypes: ["Deployment"]

在“take-over”策略中，咱们也包含了一系列的选择器，能够保障接管的资源是可控的。而上述的例子在不加“take-over”策略时，如果零碎中曾经有名为“nginx”的 Deployment 资源，则会运行失败，因为资源曾经存在。一方面，接管策略保障了利用创立时能够将曾经存在的资源纳入治理；另一方面，也能够复用之前曾经存在的工作负载配置，只会将诸如 scaler 运维特色中对实例数的批改作为配置的一部分“patch”到原先的配置上。

应用命令行一键接管工作负载

在理解了接管模式当前，你必定会想是否有一种简便的形式，能够一键接管工作负载？没错，KubeVela 的命令行提供了这种简便形式，能够将诸如 K8s 常见的资源、“Helm”等工作负载一键接管，应用起来十分不便。具体而言，velaCLI 会主动去识别系统里的资源并将其组装成一个利用实现接管，咱们在设计这个性能的外围准则是“资源的接管不能触发底层工作负载的重启”。

如下所示，默认状况下，应用 vela adopt 会用“read-only”模式治理，只需指定要接管的原生资源类型、命名空间及其名称，就能够主动生成接管的 Application 对象。生成的利用 spec 跟集群中理论的字段严格统一。

$ vela adopt deployment/default/example configmap/default/example
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  labels:
    app.oam.dev/adopt: native
  name: example
  namespace: default
spec:
  components:
  - name: example.Deployment.example
    properties:
      objects:
      - apiVersion: apps/v1
        kind: Deployment
        metadata:
          name: example
          namespace: default
        spec:
          replicas: 1
          selector:
            matchLabels:
              app: example
          template:
            metadata:
              labels:
                app: example
            spec:
              containers:
              - image: nginx
                imagePullPolicy: Always
                name: nginx
              restartPolicy: Always
          ...
    type: k8s-objects
  - name: example.config
    properties:
      objects:
      - apiVersion: v1
        kind: ConfigMap
        metadata:
          name: example
          namespace: default
    type: k8s-objects
  policies:
  - name: read-only
    properties:
      rules:
      - selector:
          componentNames:
          - example.Deployment.example
          - example.config
    type: read-only

目前反对的默认接管类型其名称和资源 API 对应关系如下：

• crd: [“CustomResourceDefinition”]
• ns: [“Namespace”]
• workload: [“Deployment”, “StatefulSet”, “DaemonSet”, “CloneSet”]
• service: [“Service”, “Ingress”, “HTTPRoute”]
• config: [“ConfigMap”, “Secret”]
• sa: [“ServiceAccount”, “Role”, “RoleBinding”, “ClusterRole”, “ClusterRoleBinding”]
• operator: [“MutatingWebhookConfiguration”, “ValidatingWebhookConfiguration”, “APIService”]
• storage: [“PersistentVolume”, “PersistentVolumeClaim”]

如果想要把利用改成接管模式、并且间接部署到集群中，只需减少几个参数即可：

vela adopt deployment/default/example --mode take-over --apply

除了原生资源，vela 命令行也默认反对接管 Helm 利用创立的工作负载。

vela adopt mysql --type helm --mode take-over --apply --recycle -n default

如上述命令就会通过“接管”模式治理 “default” 命名空间下名为“mysql”的 helm release，指定 –recycle 能够在部署胜利后把原来的 helm release 元信息清理掉。

接管后的工作负载就曾经生成出了 KubeVela 的 Application，所以相干的操作就曾经跟 KubeVela 体系对接，你能够在 VelaUX 界面上看到接管的利用，也能够通过 vela 命令行的其余性能查看、操作利用。

你还能够通过命令批量一键接管你命名空间的全副工作负载，依据 KubeVela 的资源拓扑关系能力，零碎会自动识别关联的资源，造成一个残缺的利用。对于 CRD 等自定义资源，KubeVela 也反对自定义关联关系的规定。

vela adopt --all --apply

这个命令会默认以内置资源拓扑规定辨认以后命名空间下的资源及其关联关系，并进行利用接管。以一个 Deployment 为例，主动接管后的利用如下，除了主工作负载 Deployment 之外，还接管了它的对应资源，包含 ConfigMap，Service 以及 Ingress。

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: test2
  namespace: default
spec:
  components:
  - name: test2.Deployment.test2
    properties:
      objects:
      - apiVersion: apps/v1
        kind: Deployment
        metadata:
          name: test2
          namespace: default
        spec:
          ...
    type: k8s-objects
  - name: test2.Service.test2
    properties:
      objects:
      - apiVersion: v1
        kind: Service
        metadata:
          name: test2
          namespace: default
        spec:
          ...
    type: k8s-objects
  - name: test2.Ingress.test2
    properties:
      objects:
      - apiVersion: networking.k8s.io/v1
        kind: Ingress
        metadata:
          name: test2
          namespace: default
        spec:
          ...
    type: k8s-objects
  - name: test2.config
    properties:
      objects:
      - apiVersion: v1
        kind: ConfigMap
        metadata:
          name: record-event
          namespace: default
    type: k8s-objects
  policies:
  - name: read-only
    properties:
      rules:
      - selector:
          componentNames:
          - test2.Deployment.test2
          - test2.Service.test2
          - test2.Ingress.test2
          - test2.config
    type: read-only

演示成果如下：

如果你心愿应用自定义资源拓扑关系纳管自定义资源，能够应用如下命令：

vela adopt <your-crd> –all –resource-topology-rule=<your-rule-file.cue>

“接管规定”灵便定义

鉴于 KubeVela 充沛可扩大的设计准则，资源接管面临的工作负载、接管形式也各不相同，咱们天然也设计了齐全可扩大、可编程的工作负载接管形式。事实上，命令行的一键接管能力，也只是基于 KubeVela 可扩大接管规定的一种特例[1]。其核心思想是通过 CUE 定义一种配置转换的规定，而后在执行 vela adopt 命令时指定转换规则即可，如下所示。

vela adopt deployment/my-workload --adopt-template=my-adopt-rule.cue

这种模式仅实用于高阶用户，在这里咱们将不做过于深刻的开展。如果你想理解更多细节，能够参考工作负载接管的官网文档[2]。

大幅性能优化

性能优化也是本次版本中的一大亮点，基于过往社区中各类用户不同场景的实际，咱们在默认资源配额不变的状况下，将控制器的整体性能、单利用容量、利用解决吞吐量整体晋升了 5 到 10 倍。其中也蕴含了一些默认配置的变动，针对一些影响性能的小众场景，做参数上的裁剪。

在单利用容量层面，因为 KubeVela 的利用可能会蕴含大量理论的 Kubernetes API，这往往会导致 Application 背地记录理论资源状态的 ResourceTracker 以及记录版本信息的 ApplicationRevision 对象超过 Kubernetes 单个对象的 2MB 限额。在 1.7 版本中，咱们退出了 ztsd 压缩性能并默认开启，这间接将资源的大小压缩了近 10 倍[3]。这也意味着单个 KubeVela Application 中可能反对的资源容量扩充了 10 倍。

除此之外，针对一些场景如记录利用版本、组件版本，这些版本记录自身会因为利用数量规模的回升而等比例倍数晋升，如默认记录 10 个利用版本，则会按利用数量的十倍递增。因为控制器自身 list-watch 的机制，这些减少的对象都会占用控制器内存，会导致内存使用量大幅晋升。而许多用户（如应用 GitOps）可能有本人的版本管理系统，为了防止内存上的节约，咱们将利用版本的默认记录下限从 10 个改成了 2 个。而对于应用场景绝对小众的组件版本，咱们则默认敞开。这使得控制器整体的内存耗费放大为原先的 1/3。

除此之外，还有一些参数调整包含将 Definition 的历史版本记录从 20 个放大为 2 个，将 Kubernetes API 交互的限流 QPS 默认从 100 晋升到 200 等等。在后续的版本中，咱们将继续优化控制器的性能。

易用性晋升

除了版本外围性能和性能晋升以外，这个版本还对诸多的性能易用性进行了晋升。

客户端多环境资源渲染

dry run 是 Kubernetes 中很受欢迎的一个概念，即在资源理论失效之前，先空运行一下，校验资源的配置是否非法。在 KubeVela 中也有这个性能，除了校验资源是否能够运行，还能将 OAM 形象的利用转换为 Kubernetes 原生资源的 API，可能在 CLI 客户端实现从利用形象到理论资源的转换。而 1.7 中减少的性能，就是指定不同的文件做 dry run，生成不同的理论资源。

如咱们能够将测试和生产两个不同环境的策略 (policy) 和工作流 (workflow) 写成不同的文件，别离为 “test-policy.yaml” 和 “prod-policy.yaml”，这样就能够在客户端，对同一个利用指定不同环境的策略和工作流，生成不同的底层资源，如：

• 测试环境运行

vela dry-run  -f app.yaml -f test-policy.yaml -f test-workflow.yaml

• 生产环境运行

vela dry-run  -f app.yaml -f prod-policy.yaml -f prod-workflow.yaml

其中，app.yaml 中的内容如下，指定了援用一个内部的工作流：

# app.yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: first-vela-app
spec:
  components:
    - name: express-server
      type: webservice
      properties:
        image: oamdev/hello-world
        ports:
         - port: 8000
           expose: true
      traits:
        - type: scaler
          properties:
            replicas: 1
  workflow:
    ref: deploy-demo

而 prod-plicy.yaml 和 prod-workflow.yaml 的内容别离如下：

apiVersion: core.oam.dev/v1alpha1
kind: Policy
metadata:
  name: env-prod
type: topology
properties:
  clusters: ["local"]
  namespace: "prod"
---
apiVersion: core.oam.dev/v1alpha1
kind: Policy
metadata:
  name: ha
type: override
properties:
  components:
  - type: webservice
    traits:
    - type: scaler
      properties:
        replicas: 2

apiVersion: core.oam.dev/v1alpha1
kind: Workflow
metadata:
  name: deploy-demo
  namespace: default
steps:
  - type: deploy
    name: deploy-prod
    properties:
      policies: ["ha", "env-prod"]

对应的，测试环境的 YAML 文件能够用同样的模式批改其中的参数，这个性能十分实用于将 KubeVela 用作客户端形象工具的用户，联合 Argo 等工具做资源的同步。

利用删除性能加强

在许多非凡场景下，利用删除始终是一个比拟苦楚的体验。在 1.7 版本中，咱们退出一些简便的形式，针对各类非凡状况，反对利用的顺利删除。

• 在集群失联的非凡状况下删除局部对应工作负载

咱们提供了一个交互式删除资源的办法，能够通过查看集群名称、命名空间、资源类型，来抉择底层工作负载，摘除集群失联这类非凡场景下波及的资源。

• 删除利用时保留底层资源

如果只想删除利用元数据而底层的工作负载和配置想保留，此时能够用 –orphan 参数在删除利用是保留上层资源。

• 在控制器曾经卸载的状况下删除利用

当你曾经卸载了 KubeVela 的控制器，但发现还有残留利用没删洁净时，你能够通过指定 –force 来删除这些利用。

插件装置后自定义输入

对于 KubeVela 插件体系，咱们新增了一个 NOTES.cue 文件，能够容许插件的制作者动静的输入装置实现后的提醒。比方针对 backstage 这个插件，其中的 NOTES.cue 文件如下：

info: string
if !parameter.pluginOnly {
  info: """
    By default, the backstage app is strictly serving in the domain `127.0.0.1:7007`, check it by:
                
        vela port-forward addon-backstage -n vela-system
    
    You can build your own backstage app if you want to use it in other domains. 
    """
}
if parameter.pluginOnly {info: "You can use the endpoint of'backstage-plugin-vela'in your own backstage app by configuring the'vela.host', refer to example https://github.com/wonderflow/vela-backstage-demo."}
notes: (info)

这个插件的输入就会依据用户装置插件时应用的不同参数显示不同内容。

工作流能力加强

在 1.7 版本中，咱们反对了更多细粒度的工作流能力：

• 反对指定某个失败的步骤做重试

vela workflow restart <app-name> --step=<step-name>

• 工作流的步骤名称能够不填，由 webhook 主动生成。
• 工作流的参数传递反对笼罩已有参数。

除此之外，咱们新增了一系列新的工作流步骤[4]，其中比拟典型的步骤是 built-push-image，反对在工作流中构建镜像并推送到镜像仓库中。在工作流步骤的执行过程中，你能够通过 vela workflow logs –step 查看执行日志。

VelaUX 性能加强

VelaUX 的控制台也在 1.7 版本中做了一系列加强包含：

• 反对更丰盛的利用工作流编排能力，反对残缺的工作流能力，包含子步骤、输入输出、超时、条件判断、步骤依赖等性能。利用工作流状态查看也更全面，能够查问历史工作流记录、步骤详情、步骤的日志和输入输出等信息。
• 反对利用版本回归，能够查看多版本之间利用的差别，抉择某个版本回滚。
• 多租户反对，对多租户权限做更严格的限度，于 Kubernetes RBAC 模型对齐。

近期的布局

近期，KubeVela 1.8 正式版也在紧锣密鼓的策划中，预计会在 3 月底正式跟大家见面，咱们将在如下几个方面进一步加强：

• KubeVela 外围控制器的大规模性能和稳定性加强，针对控制器程度扩容提供分片（Sharding）计划，对多集群场景下万级别利用规模做控制器的性能优化和摸底，为社区提供一个全新的性能评测。
• VelaUX 反对开箱即用的灰度公布能力，对接可观测插件做公布过程的交互。与此同时，VelaUX 造成可扩大框架体系，对 UI 的定制提供配置能力，反对业务自定义扩大和对接。
• GitOps 工作流能力加强，反对 git 仓库同步的利用对接 VelaUX 的残缺体验。

相干链接：

[1] 特例
https://github.com/kubevela/kubevela/blob/master/references/cli/adopt-templates/default.cue
[2] 官网文档
https://kubevela.net/zh/docs/end-user/policies/resource-adoption
[3] 近 10 倍
https://github.com/kubevela/kubevela/pull/5090
[4] 新的工作流步骤
https://kubevela.net/docs/end-user/workflow/built-in-workflow…

原文链接

本文为阿里云原创内容，未经容许不得转载。