CNCF Application Definition & Image Build 涵盖应用定义、开发工具、调试、环境配置、镜像构建、发布等方方面面的内容。截止2022.10.01 共 52 个项目，其中：

• • CNCF 项目：16 个
    • CNCF 毕业项目： 1个，Helm
    • CNCF 孵化项目：4个，Backstage、Buildpacks、KubeVirt、Operator Framework
    • CNCF 沙箱项目：11个，Artifact Hub、Devfile、Konveyor、Krator、KubeVela、KUDO、Nocalhost、Porter、sealer、Serverless Workflow、Telepresence

• • CNCF 成员产品/项目：37 个，包括 Open Application Model（OAM）
  • 非 CNCF 成员产品/项目：10 个

KubeVela基于OAM实现，KubeVela之于OAM类似于Istio之于服务网格，不同的是OAM已经从理念上升为规范。KubeVela的主旨是“Make shipping applications more enjoyable.（让应用部署和管理更轻松）”。

KubeVela is a modern software delivery platform that makes deploying and operating applications across today's hybrid, multi-cloud environments easier, faster and more reliable.
KubeVela 是一个现代化的软件交付平台，它可以让你的应用交付在当今流行的混合、多云环境中变得更加简单、高效、可靠。

KubeVela is infrastructure agnostic, programmable, yet most importantly, application-centric. It allows you to build powerful software, and deliver them anywhere!
KubeVela 是基础设施无关的、可编程的，但最重要的是： 它是完全以应用为中心的。它可以帮助你构建多样化的云原生应用，并交付到任意的云和基础设施！

每一个应用部署计划都由四个部分组成，分别是组件、运维能力、部署策略和工作流，分别对应了 component、trait、policy 以及 workflow step这四种类型，这些类型背后都是平台构建者（运维团队）维护的可编程模块。这种抽象方式是高度可扩展、可定制的。

• 组件（Component）: 组件定义一个应用包含的待交付制品（二进制、Docker 镜像、Helm Chart...）或云服务。我们认为一个应用部署计划部署的是一个微服务单元，里面主要包含一个核心的用于频繁迭代的服务，以及一组服务所依赖的中间件集合（包含数据库、缓存、云服务等），一个应用中包含的组件数量应该控制在约 15 个以内。
• 运维特征（Trait）: 运维特征是可以随时绑定给待部署组件的、模块化、可拔插的运维能力，比如：副本数调整（手动、自动）、数据持久化、 设置网关策略、自动设置 DNS 解析等。
• 应用策略（Policy）: 应用策略负责定义指定应用交付过程中的策略，比如多集群部署的差异化配置、资源放置策略、安全组策略、防火墙规则、SLO 目标等。
• 工作流步骤（Workflow Step）: 工作流由多个步骤组成，允许用户自定义应用在某个环境的交付过程。典型的工作流步骤包括人工审核、数据传递、多集群发布、通知等。

3.2.1.2. 插件（Addon） -- 底层无关

KubeVela 提供了强大的插件机制，插件被定义为可编程能力及其实现构成的包，具体由 OAM 的模块定义和背后的Kubernetes CRD 控制器组成的集合。事实上，就是Application中component、trait、policy、workflow最后输出的资源对象或cr，由插件 watch 到之后去施工。插件本身也是应用。

目前 KubeVela 一共有四种不同类型的模块定义，分别是组件定义（ComponentDefinition）、运维特征定义（TraitDefinition）、策略定义（PolicyDefinition）以及工作流步骤定义（WorkflowStepDefinition），对应了构成应用的四个基本概念。

事实上就是KubeVela Application 有component、trait、policy、workflow四种模块，这些模块都有类型，这些类型就需要被解析成对应的资源对象或者cr，能力提供商的插件watch这些cr 去施工。模块定义就是根据用户填写的component、trait、policy、workflow类型和参数，解析成资源对象和CR。

2.2.3.1. KubeVela是一套控制平面系统

KubeVela 依赖一个独立的 Kubernetes 集群来运行。这其实是一个“有意为之”的设计：云原生社区中大量的实践已经证明“构建一个科学的、健壮的控制平面系统”，正是 Kubernetes 项目最擅长的工作。

具体来说，KubeVela 本身主要由如下几个部分组成:

• 核心控制器 为整个系统提供核心控制逻辑，完成诸如编排应用和工作流、修订版本快照、垃圾回收等等基础逻辑
• 模块化能力控制器 负责对 X-Definitions 对象进行注册和管理。
• 插件控制器 负责注册和管理 KubeVela 运行所需要的第三方插件，比如 VelaUX、 Flux、Terraform 组件等等。
• UI 控制台和 CLI UI 控制台服务于希望开箱即用的开发者用户，CLI 适用于集成 KubeVela 和终端管理的用户。

2.2.3.2. KubeVela是编程的

• 云原生应用平台的构建者、PaaS、Serverless平台工程师、基础设施平台管理员
• 第三方软件供应商（ISV）、垂直领域软件开发者、架构师
• 云原生时代的应用研发、运维人员、DevOps 工程师

2.2.4 个人看法

痛点/不足：

1. 编排能力不足

1. 原因一，先天不足，没有规范标准确定应用应该包含什么、关注什么。此时，CD系统对应用的定义如果比较“狭隘”（例如应用就是业务的可执行程序本身），那自然就没有编排的土壤。业务程序与外部依赖的关系可能仅仅是躺在配置文件中（例如数据库地址、账号和密码），可能是基于sdk的注册和发现机制（例如第二代微服务框架）。
2. 原因二，关系描述能力不足，部分CD系统意识到应用除了业务程序还有依赖组件（例如数据库、缓存、消息等），但没有向上抽象仅仅是通过应用目录框在一起。

2. OAM 还在持续的演进，尚未到理想状态

1. 当前版本的OAM刻画了应用、组件、运维特征的关系，但并没有刻画组件之间的关系，以及交付的过程是怎么样

KubeVela 的优势：

1. 基于OAM规范的优越性，对应用有了更全面的定义（应该还不是终态），方便编排。

1. 一个应用可包含至少一个组件，组件可以是业务程序，也可以是数据库等依赖类型的组件（基于 X as Code的理念与实现，在公有云上可以方便的订购其他产品做为组件）
2. 一个组件包含一个类型和可选数量的运维特征。一个类型就是一个组件实现，组件实现输出的内容有output和outpus，前者是一个工作负载（例如kubernetes workload），后者是其他资源（例如service，configmap等）；运维特征是围绕某个组件本身，内置的运维特征有有亲和性（亲和反亲和、容忍等）、暴露（服务和ingress等）、伸缩器、边车等22种，还支持扩展。如此一来，组件内有丰富的内容（运维特征）可供编排。事实上跨组件也一样。

2. KubeVela关注到了跨组件的关系，也给出了编排工具 - Policy，是KubeVela领先于OAM的实践。除了Policy 还提供了 Workflow，提供了应用交付过程的描述。
3. KubeVela的抽象方式，使得系统高度可扩展，能力提供商通过插件机制可以轻松的围绕应用构建各种能力，包括混合环境等等