关于云原生:KubeVela云原生应用和平台工程之路

背景

最近，云原生计算基金会 CNCF 下的 App Delivery TAG（利用交付畛域小组）公布了《CNCF 平台工程白皮书》，KubeVela 被纳入“对立 API 层”我的项目。

原文下载链接：https://appdelivery.cncf.io/whitepapers/platforms/

回溯 2019 年，Kubernetes 逐步成为部署和治理基础设施的事实标准。越来越多的平台工程师开始在 Kubernetes 之上构建平台，并向最终用户提供服务。容器化部署和申明式 API 大大降低了简单零碎操作的难度。

然而，当集群中存在数千个工作负载和相干资源时，操作人员很难辨认逻辑关系，并依据其外部关系进行精确且合乎业务须要的治理。

同时，像 Helm 或 Kustomize 这样的工具曾经摸索了 打包和交付 Kubernetes 资源的解决方案。这些已被证实是十分无效的，显然 Helm Chart 当初是在 Kubernetes 中打包和散发制品最受欢迎的形式。

另一方面，各种我的项目也开始定义应用程序。这些尝试不仅是简略地打包资源，而是从自上而下的视角寻求解决方案。与将离散的对象分组以更方便使用相比，应用程序旨在弥合业务利用的研发者和基础设施之间的认知差距。凋谢利用模型 Open Application Model（OAM）[1] 及其对 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"

Pic 2. Example of a component inside an OAM application

随着微服务变得越来越广泛，许多应用程序开发人员开始将宏大的单体程序合成为小的局部。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

更多

除了 Component 和 Trait 之外，还有其余货色能够从不同的层面为应用程序工作。

每个应用程序可能蕴含多个原子性能单元，即 Component（组件），每个 Component 能够由多个 Trait 润饰。如果咱们想定义一些与运行 Component 没有明确一对一关系的应用程序级别的行为或策略，须要更多的利用程序定义。

截至目前，OAM 还没有对这部分建模提出决定性的解决方案。曾经提出了包含 Scope、Policy、Workflow、Scope 在内的一些概念，用于定义应用程序的应用范畴。Policy 用于形容常见的策略和行为。Workflow 侧重于应用程序的交付方面。其中一些已被 KubeVela 采纳，KubeVela 是基于 Kubernetes 的 OAM 实现之一，在模型的演进上能够帮忙咱们通过实际来驱动设计。

从实践到实际

凋谢利用模型（Open Application Model）的标准从概念上为那些心愿从利用开发人员的角度对应用程序和构建平台进行建模的平台构建者们提供领导。在过来的几年中，包含 KubeVela、Crossplane、Verrazzano 和 Intuit 在内的采纳者都做了各种尝试。只管 OAM 标准被提出为与基础架构无关，但到目前为止，目前大部分的（性能）实现都是基于 Kubernetes 作为管制立体。

回顾历史，咱们得出的论断是，在 Kubernetes 上进行应用程序建模尤为重要。在将 OAM 标准利用于 Kubernetes 时，KubeVela 做了很多工作来解决各种细节上的技术问题。这些问题又能够分为三个不同的方向：形象、交付和治理。

形象

OAM 中的组件定义了应用程序的运行实例。不同类型的组件实用于不同类型的运行实例。在 Kubernetes 中，它对应于不同的工作负载实现，如 Deployment 或 StatefulSet。KubeVela 将这些类型申明为 ComponentDefinition，并为可扩展性解决方案引入 CUE。CUE 用于模板化 Kubernetes 资源，因而平台构建者能够进行任意的自定义操作。

Pic 4. KubeVela leverages CUE for templating Component and Trait

在 Trait 这层，形象的办法与 Component 相似，也就是用 TraitDefinition 来申明不同类型。与 Component 的次要区别之一是，某些类型的 Trait 须要对 Component Definition 所形象的资源进行批改。例如，为了裸露端口，咱们须要同时增加 Service 对象并在 Deployment 标准中裸露端口。CUE 自身并没有提供这样的办法，然而 KubeVela 会以某种形式对 CUE 进行扩大来实现了这一性能。除动态渲染外，KubeVela 的形象层还有运行时感知能力。这意味着渲染逻辑能够依据运行环境进行更改，就像它以后运行的 Kubernetes 版本一样。当 KubeVela 用作跨集群的对立管制立体时，这一点尤其有用。

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，业务研发负责应用程序。

Pic 6. KubeVela leaves the abstraction implementation to platform engineers and lets app developers to use predefined types of Components and Traits to compose Applications

交付

形象层次要解决构建、打包和散发利用的问题。在交付应用程序并将它们作为对立的整体时，状况会变得更加简单。应用程序作为一个整体，在 KubeVela 中，被视为是交付的根本单元。一个应用程序外部不同组件之间的关系能够决定如何交付这些组件，这些关系会在 dependsOn 字段中批示。

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

Pic 7. KubeVela provides a consistent, programmable, declarative workflow to orchestrate app delivery process

一些用户可能会遇到多个关联应用程序进行交付的状况，KubeVela 甚至为此提供了更高级别的解决方案，称为 Pipeline。同时，应用程序模型是否应该与交付一起设计，也是一个有争议的问题。像 Tekton、Argo Workflow 这样的独立交付工具曾经倒退了多年。其余 CI 工具如 Jenkins 或 GitHub Actions 也在一直倒退以反对各种交付场景。KubeVela 在将应用程序模型和交付流程联合在一起方面迈出了极为前瞻性的一步，因为它认为这种办法是将应用程序模型投入到生产应用的最佳实际。然而 OAM 标准并没有急于增加工作流等内容，因为对于实践建模的答案仍须要更宽泛的探讨。

治理

应用程序模型不仅用于交付，申明式 API 面向终态的能力也同样实用。因而，在实践中，应用程序模型也被用于 KubeVela 的一致性比照。KubeVela 确保在交付过程胜利实现后不会偏离冀望状态，这合乎 Kubernetes 的最终面向状态的理念。

Pic 8. KubeVela constantly ensures there’s no configuration drift for the delivered application

此外，KubeVela 还嵌入了许多其余治理操作，包含版本治理、权限管制、资源共享和垃圾回收。目前这些性能不蕴含在 OAM 标准中，但被认为是将来 OAM 标准的一部分。

总体而言，为了满足在 Kubernetes 上应用程序应用的各种需要，KubeVela 始终在 OAM 标准之外做一直的尝试，并摸索更多可能的利用操作形式。

如果您对更多的技术细节感兴趣，请参阅此博客 [2]。

将来

很多人质疑为什么 OAM 的 Github 仓库仿佛不沉闷了。对于次要关怀生产实践和模型应用的人来说，答案是，KubeVela 作为 OAM 的 实现 始终在高速倒退，驳回 KubeVela 的用户始终在减少，并且 KubeVela 刚刚成为一个 CNCF 孵化我的项目，这也意味着 OAM 模型的采纳者始终在疾速减少。

至于实践模型，KubeVela 仍在期待来自工业生产实际的更多反馈和证据，咱们不心愿过快的对标准引入变更导致标准的稳定性呈现问题。咱们的打算是 KubeVela 的实际被宽泛采纳并逐步稳固后，再向 OAM 标准提出其额定附加的概念，如工作流程或策略。咱们心愿在 CNCF 基金会的帮忙下越来越多的人能退出社区，使在现代化利用的部署和运维变得更容易、更高效、更牢靠。

相干链接：

[1] Open Application Model（OAM）https://oam.dev/
[2] 此博客 https://kubevela.net/blog/2022/11/29/retro-2022

作者：殷达

原文链接

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