KubeVela：云原生应用和平台工程之路

Pic 1. OAM is proposed to bridge the gap between app developers and the use of underlying infrastructures

由微软和阿里云支持的开放应用程序模型（OAM），其目标是为云原生应用程序应该是什么样子提供一个理论模型。它最初被设计为不与 Kubernetes 绑定，并且倾向于为操作应用程序提供统一的接口。OAM 提出了组件和特性的概念，以对应用程序架构进行抽象。这对于原生 Kubernetes 用户来说是一个很大的变革，但这是有原因的。

在 Kubernetes 中，Deployment 或 Service 等资源侧重于实现。每种资源类型都提供特定的功能。一些低级功能，（如运行容器），会转到 Pod 等基本单元。一些更高级别功能，例如容器编排，处理回滚的功能，（例如 Deployment 或 StatefulSet），则是建立在较低级别的功能之上的。毫无疑问，“为平台构建者服务的平台”这个定位获得了巨大的成功。但对于应用开发人员来说，社区正在迫使他们成为 Kubernetes 专家才能使事情正常运行。此外，对低级资源的肤浅理解实际上可能导致不正确操作带来的显著风险。

OAM 切入的视角与传统的解决方案显著不同。应用程序的真正组成是什么？应用程序开发人员需要什么？

运行应用程序的东西。对于应用程序来说，这绝对是最核心的部分。在 Kubernetes 中，它可以是 Deployment、Pods 或其他东西。在 Kubernetes 之外，它可以是 Docker 容器、虚拟机或云执行引擎。99.9% 的应用程序开发人员创建程序并运行它。OAM 将运行应用程序的整个内容定义为组件。它不仅仅是一组资源。没有组件，你将无法知道应用程序的用途。

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: webserver-demo
spec:
  components:
    - name: hello-world
      type: webserver               # claim to deploy webserver component definition
      properties:                   # setting parameter values
        image: crccheck/hello-world
        port: 8000                  # this port will be automatically exposed to public
        env:
        - name: "foo"
          value: "bar"
        cpu: "100m"

随着微服务变得越来越普遍，许多应用程序开发人员开始将庞大的单体程序分解为小的部分。OAM 的定义中的每个可运行的部分都可以建模为一个组件，作为一个整体，它们共同组成了一个完整的 OAM 应用程序。它们的内部逻辑关系也在组件中绘制。

要使应用程序正常运行，还需要其他一些东西。例如，在 Kubernetes 中，我们有 Service、ConfigMap、PersistentVolumeClaim 和许多其他资源，它们为 Deployment 提供特定的功能。但是这些资源是为了满足某些技术需求而创建的，而不是以目的为导向的。ConfigMap 为Kubernetes 用户提供了一种存储配置数据的方法，但要让容器使用该配置，用户需要在 Deployment 中添加卷部分并设置容器参数或环境变量。

如果我们再次改变视角，考虑应用程序开发人员在使用这些资源时真正想要做什么，我们可能会得出这样一个结论即许多资源都是为应用程序组件提供额外功能。创建 Service 或 Ingress 对象是为应用程序提供访问而创建的。PersistentVolumeClaim 和 Deployment 中的卷部分是为提供存储而创建的。 第三方对象（如 Prometheus 中的ServiceMonitor）用于提供观察规则。这些提供功能的辅助资源和修改在 OAM 中被定义为特性。

这些特性 Trait 不能独立工作。这些功能附加到组件并用作装饰。没有它，应用程序的主要目的不会改变，但会不完整。

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: my-example-app
spec:
  components:
    - name: publicweb
      type: web-ui
      properties: # properties targeting component parameters.
        image: example/web-ui:v1.0.2@sha256:verytrustworthyhash
        param_1: "enabled" # param_1 is defined on the web-ui component
      traits:
        - type: ingress # ingress trait providing a public endpoint for the publicweb component of the application.
          properties: # properties are defined by the trait CRD spec. This example assumes path and port.
            path: 
            port: 8080
    - name: backend
      type: company/test-backend # test-backend is referenced from other namespace
      properties:
        debug: "true" # debug is a parameter defined in the test-backend component.
      traits:
        - type: scaler # scaler trait to specify the number of replicas for the backend component
          properties:
            replicas: 4

Pic 3. Example of an OAM application containing two components with traits attached

截至目前，OAM 还没有对这部分建模提出决定性的解决方案。已经提出了包括 Scope、Policy、Workflow、Scope 在内的一些概念，用于定义应用程序的使用范围。Policy 用于描述常见的策略和行为。Workflow 侧重于应用程序的交付方面。其中一些已被 KubeVela 采用，KubeVela 是基于 Kubernetes 的 OAM 实现之一，在模型的演进上可以帮助我们通过实践来驱动设计。

Pic 5. In traditional system, application developer needs to deal with version upgrades across clusters

总之，与 Helm Chart 使用的 Go Template 或通过 Kustomization 做配置简化类似，KubeVela 中抽象层的实现在功能上是完整包含的。另一方面，KubeVela 将这些抽象基础建立在 ComponentDefinitions 和 TraitDefinitions 之上，以便更好地实现重用。与直接使用 Helm Chart 对整个应用程序进行模板化相比，这为平台构建者提供了更精细的选择。这反过来又为平台工程师和业务研发人员之间的职责划分提供了更清晰的界限：平台工程师负责 X-Definitions，业务研发负责应用程序。

抽象层主要解决构建、打包和分发应用的问题。在交付应用程序并将它们作为统一的整体时，情况会变得更加复杂。应用程序作为一个整体，在 KubeVela 中，被视为是交付的基本单元。一个应用程序内部不同组件之间的关系可以决定如何交付这些组件，这些关系会在 dependsOn 字段中指示。

除了资源调度外，应用程序的交付有时还涉及更多，比如对生产环境的高风险交付进行人工审核、在自动交付完成时通知、跨多集群进行差异化交付等。为了让用户能够自定义交付过程，KubeVela 在应用程序模型中添加了 Workflow，其中 WorkflowStepDefinition 利用 CUE 定义原子执行单元。

此外，KubeVela 还嵌入了许多其他管理操作，包括版本管理、权限控制、资源共享和垃圾回收。目前这些功能不包含在 OAM 规范中，但被认为是未来 OAM 规范的一部分。

英文原文地址：https://www.cncf.io/blog/2023/03/31/kubevela-the-road-to-cloud-native-application-and-platform-engineering/  

您可以通过如下材料了解更多关于 KubeVela 以及 OAM 项目的细节：

• 项目代码库：
  https://github.com/kubevela/kubevela
  欢迎 Star/Watch/Fork！
• 项目官方主页与文档：kubevela.io ，从 1.1 版本开始，已提供中文、英文文档，更多语言文档欢迎开发者进行翻译。
• 项目钉钉群：23310022；Slack：CNCF #kubevela Channel
• 加入微信群：请先添加以下 maintainer 微信号，表明进入 KubeVela 用户群：

相关链接：

[2] 此博客

点击阅读原文查看 KubeVela 项目官网