KubeVela：云原生应用和平台工程之路-低调大师

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

2023-04-10 959

作者：殷达

背景

最近，云原生计算基金会 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

从理论到实践

开放应用模型（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基金会的帮助下越来越多的人能加入社区，使在现代化应用的部署和运维变得更容易、更高效、更可靠。

最后做个预告，在 4 月 17 日至 21 日即将举办的 KubeCon + CloudNativeCon Europe 2023 中，将有三场围绕 KubeVela 的话题分享，欢迎大家提前锁定，了解 KubeVela 最新的技术升级、社区动态和企业实践：

（*TimeZone:Europe/Amsterdam)

Wednesday, April 19 • 15:25 - 16:00 ：Building a Platform Engineering Fabric with the Kube API at Autodesk - Jesse Sanford & Greg Haynes, Autodesk

https://kccnceu2023.sched.com/event/1HyXP/building-a-platform-engineering-fabric-with-the-kube-api-at-autodesk-jesse-sanford-greg-haynes-autodesk

Thursday, April 20 • 16:30 - 18:00 ：Tutorial: Deploying Cloud-Native Applications Using Kubevela and OAM - Daniel Higuero, Napptive

https://kccnceu2023.sched.com/event/1K8nU/challenges-of-modern-application-delivery-a-retrospection-of-kubevela-highlight-technologies-jianbo-sun-da-yin-alibaba-cloud

Friday April 21 • 11:00 - 11:35 ：Challenges of Modern Application Delivery: A Retrospection of KubeVela Highlight Technologies - Jianbo Sun & Da Yin, Alibaba Cloud

https://kccnceu2023.sched.com/event/1K8nU/challenges-of-modern-application-delivery-a-retrospection-of-kubevela-highlight-technologies-jianbo-sun-da-yin-alibaba-cloud

英文原文地址：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 用户群：

相关链接：

[1] Open Application Model（OAM）

https://oam.dev/

[2] 此博客

https://kubevela.net/blog/2022/11/29/retro-2022

点击此处查看 KubeVela 项目官网

微信关注我们

原文链接：https://my.oschina.net/u/3874284/blog/8645457

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

那些让 ChatGPT review 代码的程序员，后来都怎么样了？

Review PR 是开源项目的重要一环。对于项目维护者来说，社区有人来贡献代码，是一件值得开心的事情，说明自己的项目受到了认可。开源项目将通过社区贡献变得更强大。对于贡献代码的开发者来说，编程能力获得了开源项目的认可，也是一件值得写到简历的事情。在 Review 代码的过程中加上了 ChatGPT，会发生什么化学反应？我司 Second State 最近在自己的开源项目的 GitHub repo 中引入了一个基于 ChatGPT 的 PR Review 机器人。当有人提交新的 PR 的时候，这个机器人会总结 PR在干什么、潜在的风险与问题、以及这个 PR 里的每次 commit 都干了什么。这对 Reviewer 来说，能够大大增加 review PR 的速度。更重要的是 ChatGPT 还能找到代码里的潜在问题，提供更高效的写代码的方式。下面我们来看一个真实的例子。看看下面这段代码，你有发现什么问题吗？ let limit = (n as f64).sqrt() as i32; for a in 2..limit { if n % a == 0 { return JsVa...

2023-04-10

343

前篇《虚拟云网络系列 | Antrea 应用于 VMware 方案功能简介（六）》中，我们以实际画面展示了采用 NSX 搭配基于 Antrea 的 Kubernetes Cluster 内，在 NSX UI 管理界面内可以查看到 K8S 丛集的相关信息，并且可以基于 Namespace / Service / Pod Label 等，将要管理的 Pod 纳入 Antrea 群组。本篇内，同样地我想要以实际的画面与大家展示，在 NSX 内如何配置对应的 K8S 防火墙规则，并且查询相关日志。在前篇展示内我们建立了一个叫做 dvwa-ns 的群组，把所有在 dvwa-ns namespace 内的 Pods 都加到这个群组内。接下来我们要做的展示如下：在上述群组内的 Pod，可以连往任何地方，但不能连到 9.9.9.9 这个 IP 地址；防火墙规则符合时，可以提供日志记录。下图是我要实现上面的这个防火墙政策，在 NSX – Security – Policy Management – Distributed Firewall 内输入的规则：几个重点讨论如下： 1.定义规则前，我们...

2023-04-10

833

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。