KubeVela核心控制器原理浅析

前言

在学习 KubeVela 的核心控制器之前，我们先简单了解一下 KubeVela 的相关知识。

KubeVela 本身是一个应用交付与管理控制平面，它架在 Kubernetes 集群、云平台等基础设施之上，通过开放应用模型来对组件、云服务、运维能力、交付工作流进行统一的编排和交付。

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

核心控制器 为整个系统提供核心控制逻辑，完成诸如编排应用和工作流、修订版本快照、垃圾回收等等基础逻辑。

模块化能力控制器 负责对 X-Definitions 对象进行注册和管理。

Cluster Gateway 控制器 为操作多集群提供了统一的访问接口。

插件体系 负责注册和管理 KubeVela 的扩展功能，包括 CRD 控制器和相关模块定义。比如 VelaUX、FluxCD、Workflow 等插件。

UI 控制台 和 CLI 分别为用户提供了图形化界面和命令行界面操作 API。

本文主要介绍 KubeVela 的核心控制逻辑，如未做特殊说明，以下内容均基于 KubeVela 社区版本 v1.8.2 阐述。

OAM 应用模型

在介绍 KubeVela 的核心控制逻辑之前，我们先了解一下核心控制器作用对象，OAM 应用模型（如图 1），开放应用模型允许用户把一个现代微服务应用部署所需的所有组件和各项运维动作，描述为一个统一的、与基础设施无关的"部署计划"，进而实现在混合环境中进行标准化和高效率的应用交付。

图1

具体来说：

• • 通过一个叫做应用部署计划（Application）的对象来声明一个微服务应用的完整交付流程，这其中包含了待交付组件、关联的运维动作、交付流水线等内容。

• • 所有的待交付组件、运维动作和流水线中的每一个步骤，都遵循 OAM 规范设计为独立的可插拔模块，允许用户按照自己的需求进行组合或者定制。

• • OAM 模型也会负责规范各个模块之间的协作接口。

应用部署计划

Application 对象是 KubeVela 核心控制器作用的最小单元，也是用户唯一需要了解的 API，它表达了一个微服务应用的部署计划。遵循 OAM 规范，一个应用部署计划（Application）由"待部署组件（Component）"、"运维动作（Trait）"、"应用的执行策略（Policy）"，以及"部署工作流（Workflow）"这四部分概念组成。

组件

组件（Component）是构成微服务应用的基本单元，比如一个 Bookinfo 应用可以包含 Ratings、Reviews、Details 等多个组件。

运维特征

运维特征（Trait）负责定义组件可以关联的通用运维行为，比如服务发布、访问、治理、弹性、可观测性、灰度发布等。在 OAM 规范中，一个组件可以绑定任意个运维特征。

应用的执行策略

应用的执行策略（Policy）负责定义应用级别的部署特征，比如健康检查规则、安全组、防火墙、SLO、检验等模块。

部署执行工作流

部署执行工作流（Workflow）定义了从部署开始到达到部署终态的一条完整路径，KubeVela 会按这个流水线执行工作流中定义的各个步骤来完成整个应用交付。

KubeVela 不仅内置了多种类型组件、运维特征、策略以及工作流 Step，还支持用户自定义组件、运维特征、策略及工作流 Step，帮助用户在混合环境中进行标准化和高效率的应用交付。在实际使用时，用户通过上述 Application 对象来引用预置的组件、运维特征、应用策略、以及工作流节点模块，填写这些模块暴露的用户参数即可完成一次对应用交付的建模。

核心控制器工作原理

KubeVela vela-core 的代码结构相对来说比较简单，因为它是基于 controller-runtime 框架开发实现的控制器管理器。其中 componentdefinition、traitdefinition、policydefinition、workflowstepdefinition 控制器分别用于调谐管理组件、运维特征、策略、工作流步骤类型及其版本状态信息，而 application 控制器则用于调谐应用部署计划。

application_controller 是 KubeVela 的核心控制器，它会解析应用部署计划，生成当前应用的修订版本，并与最近一次修订版本进行比较根据是否有差异来判断修订版本状态是否需要更新，然后解析工作流 Steps 中引用的外部策略生成 manifest 并执行 apply，再然后根据应用工作流 Steps 生成工作流 Instance 和待执行的任务 Runners，最后创建工作流 Executor 并执行任务 Runners。

KubeVela 核心控制器的工作原理跟 K8s Controller 是一样的，都是通过 API Server 提供的 List & Watch 接口来实时监控集群中 Application 资源对象的状态变化，当资源对象的状态变化时，控制器会尝试将其状态调谐为期望的状态。接下来笔者将对 application_controller 的调谐逻辑进行详细说明，主要包括解析应用部署计划、创建应用修订版本、应用外部策略、解析执行工作流任务等四个过程。

1、解析应用部署计划

解析应用部署计划的过程实际上就是解析应用部署计划中的组件、运维特征、策略和工作流，然后生成应用描述文件 AppFile，在生成 AppFile 之前会先检查最新的应用修订版与应用是否具有相同的 publishVersion，如果 publishVersion 相同则直接根据最新的应用修订版生成 AppFile，否则根据应用应用部署计划生成 AppFile。AppFile 作为后续调谐逻辑的基准数据模型，不仅包含了应用部署计划中的信息，还记录了调谐过程中所必须的 PolicyWorkload 等中间产物。

func (p *Parser) GenerateAppFile(ctx context.Context, app *v1beta1.Application) (*Appfile, error) {
   if ctx, ok := ctx.(monitorContext.Context); ok {
      subCtx := ctx.Fork("generate-app-file", monitorContext.DurationMetric(func(v float64) {
         metrics.AppReconcileStageDurationHistogram.WithLabelValues("generate-appfile").Observe(v)
      }))
      defer subCtx.Commit("finish generate appFile")
   }
   if isLatest, appRev, err := p.isLatestPublishVersion(ctx, app); err != nil {
      return nil, err
   } else if isLatest {
      app.Spec = appRev.Spec.Application.Spec
      return p.GenerateAppFileFromRevision(appRev)
   }
   return p.GenerateAppFileFromApp(ctx, app)
}

2、创建应用修订版本

创建应用修订版本的过程实际上就是保存应用版本，如果是更新应用的操作，会获取应用最近一次的版本信息，并与应用当前版本比较确认是否需要更新应用状态中的最近一次版本信息。

if err := handler.PrepareCurrentAppRevision(logCtx, appFile); err != nil {
        logCtx.Error(err, "Failed to prepare app revision")
        r.Recorder.Event(app, event.Warning(velatypes.ReasonFailedRevision, err))
        return r.endWithNegativeCondition(logCtx, app, condition.ErrorCondition("Revision", err), common.ApplicationRendering)
    }
    if err := handler.FinalizeAndApplyAppRevision(logCtx); err != nil {
       &