KubeVela

集群、云平台等基础设施之上#xff0c;通过开放应用模型来对组件、云服务、运维能力、交付工作流进…前言

在学习

集群、云平台等基础设施之上通过开放应用模型来对组件、云服务、运维能力、交付工作流进行统一的编排和交付。

具体来说KubeVela

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

模块化能力控制器

1开放应用模型允许用户把一个现代微服务应用部署所需的所有组件和各项运维动作描述为一个统一的、与基础设施无关的部署计划进而实现在混合环境中进行标准化和高效率的应用交付。

具体来说

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

OAM

规范设计为独立的可插拔模块允许用户按照自己的需求进行组合或者定制。

OAM

规范一个应用部署计划Application由待部署组件Component、运维动作Trait、应用的执行策略Policy以及部署工作流Workflow这四部分概念组成。

Bookinfo

运维特征Trait负责定义组件可以关联的通用运维行为比如服务发布、访问、治理、弹性、可观测性、灰度发布等。

在

OAM

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

部署执行工作流

部署执行工作流Workflow定义了从部署开始到达到部署终态的一条完整路径KubeVela

KubeVela

Step帮助用户在混合环境中进行标准化和高效率的应用交付。

在实际使用时用户通过上述

Application

对象来引用预置的组件、运维特征、应用策略、以及工作流节点模块填写这些模块暴露的用户参数即可完成一次对应用交付的建模。

核心控制器工作原理

componentdefinition、traitdefinition、policydefinition、workflowstepdefinition

控制器分别用于调谐管理组件、运维特征、策略、工作流步骤类型及其版本状态信息而

application

的核心控制器它会解析应用部署计划生成当前应用的修订版本并与最近一次修订版本进行比较根据是否有差异来判断修订版本状态是否需要更新然后解析工作流

Steps

资源对象的状态变化当资源对象的状态变化时控制器会尝试将其状态调谐为期望的状态。

接下来笔者将对

的调谐逻辑进行详细说明主要包括解析应用部署计划、创建应用修订版本、应用外部策略、解析执行工作流任务等四个过程。

1、解析应用部署计划

解析应用部署计划的过程实际上就是解析应用部署计划中的组件、运维特征、策略和工作流然后生成应用描述文件

AppFile在生成

作为后续调谐逻辑的基准数据模型不仅包含了应用部署计划中的信息还记录了调谐过程中所必须的

PolicyWorkload

monitorContext.DurationMetric(func(v

float64)

{metrics.AppReconcileStageDurationHistogram.WithLabelValues(generate-appfile).Observe(v)}))defer

subCtx.Commit(finish

appRev.Spec.Application.Specreturn

p.GenerateAppFileFromRevision(appRev)}return

app)

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

err

handler.PrepareCurrentAppRevision(logCtx,

appFile);

event.Warning(velatypes.ReasonFailedRevision,

err))return

r.endWithNegativeCondition(logCtx,

app,

condition.ErrorCondition(Revision,

err),

common.ApplicationRendering)}if

err

handler.FinalizeAndApplyAppRevision(logCtx);

err

event.Warning(velatypes.ReasonFailedRevision,

err))return

r.endWithNegativeCondition(logCtx,

app,

condition.ErrorCondition(Revision,

err),

common.ApplicationRendering)}logCtx.Info(Successfully

prepare

handler.currentAppRev.Name,revisionHash,

isNewRevision,

handler.isNewRevision)app.Status.SetConditions(condition.ReadyCondition(Revision))r.Recorder.Event(app,

event.Normal(velatypes.ReasonRevisoned,

velatypes.MessageRevisioned))if

err

handler.UpdateAppLatestRevisionStatus(logCtx);

err

r.endWithNegativeCondition(logCtx,

app,

common.ApplicationRendering)}logCtx.Info(Successfully

apply

外部策略指的是未在内部策略中声明的且在工作流步骤中使用的策略这些策略是在应用的命名空间下声明的策略。

AppFile

PolicyWorkload

LoadExternalPoliciesForWorkflow(ctx

context.Context,

[]workflowv1alpha1.WorkflowStep,

internalPolicies

utils.StrictUnmarshal(_step.Properties.Raw,

props);

types2.NamespacedName{Namespace:

appNs,

po.Properties})policyMap[policyName]

struct{}{}}}}}return

monitorContext.DurationMetric(func(v

float64)

{metrics.AppReconcileStageDurationHistogram.WithLabelValues(apply-policies).Observe(v)}))defer

subCtx.Commit(finish

af.GeneratePolicyManifests(ctx)if

err

{util.AddLabels(policyManifest,

map[string]string{oam.LabelAppName:

h.app.GetName(),oam.LabelAppNamespace:

err

核心控制器中最重要的也是最难理解的部分应该就属工作流任务的解析执行了因为该部分使用了大量的函数式编程和异步编程对于一个

语言的初学者来说捋清楚这段代码并不是一件易事。

接下来笔者将从解析和执行两个方面来介绍工作流任务。

handlers

主要供后续执行工作流任务使用不管是内置的还是自定义工作流步骤在声明

Step

来完成工作任务的执行。

第二步是初始化工作流实例执行工作流任务的阶段也会根据这个工作流实例创建工作流的执行器用于执行工作流中任务

handlers

{metrics.AppReconcileStageDurationHistogram.WithLabelValues(generate-app-steps).Observe(time.Since(t).Seconds())}()appLabels

map[string]string{oam.LabelAppName:

app.Name,oam.LabelAppNamespace:

app.Namespace,}handlerProviders

providers.NewProviders()kube.Install(handlerProviders,

h.r.Client,

h.Delete,})configprovider.Install(handlerProviders,

h.r.Client,

{res.SetLabels(util.MergeMapOverrideWithDst(res.GetLabels(),

appLabels))}return

applyOptions)})oamProvider.Install(handlerProviders,

app,

h.applyComponentFunc(appParser,

appRev,

h.renderComponentFunc(appParser,

appRev,

velaprocess.NewContext(generateContextDataFromApp(app,

func(ctx

appParser.ParseWorkloadFromRevisionAndClient(ctx,

comp,

appRev)}multiclusterProvider.Install(handlerProviders,

h.r.Client,

af,h.applyComponentFunc(appParser,

appRev,

af),h.checkComponentHealth(appParser,

appRev,

af),renderer)terraformProvider.Install(handlerProviders,

app,

renderer)query.Install(handlerProviders,

h.r.Client,

app)executor.InitializeWorkflowInstance(instance)runners,

err

wfTypes.StepGeneratorOptions{Providers:

handlerProviders,PackageDiscover:

h.r.pd,ProcessCtx:

template.NewWorkflowStepTemplateRevisionLoader(appRev,

h.r.dm),Client:

(workflowv1alpha1.WorkflowStep,

error){wfTypes.WorkflowStepTypeApplyComponent:

func(lstep

(workflowv1alpha1.WorkflowStep,

error)

convertStepProperties(copierStep,

app);

[apply-component])}copierStep.Type

wfTypes.WorkflowStepTypeBuiltinApplyComponentreturn

*copierStep,

生成任务运行程序的过程是根据应用部署计划中配置的工作流遍历工作流步骤

Step

ctx.Fork(generate-task-runners,

monitorContext.DurationMetric(func(v

float64)

{metrics.GenerateTaskRunnersDurationHistogram.WithLabelValues(workflowrun).Observe(v)}))defer

subCtx.Commit(finish

generateStepID(instance.Status,

options.PackageDiscover,ProcessContext:

typ,

执行工作流任务的过程也包含三个步骤第一步是根据工作流实例创建工作流执行器。

第二步是调用执行器的

ExecuteRunners

方法按顺序执行工作流任务运行程序。

第三步则是根据工作流任务运行程序的执行结果即工作流执行状态和工作流实例状态的

EndTime

主要是用来跟踪和维护应用管理的资源会在转发应用管理的资源清单之前在

HubCluster

{InitializeWorkflowInstance(w.instance)status

status.Mode.Steps

v1alpha1.WorkflowModeDAGcacheKey

fmt.Sprintf(%s-%s,

w.instance.Namespace)allRunnersDone,

allRunnersSucceeded

{StepStatusCache.Delete(cacheKey)}if

checkWorkflowTerminated(status,

allRunnersDone)

v1alpha1.WorkflowStateTerminated,

nil}return

v1alpha1.WorkflowStateSuspending,

nil}if

v1alpha1.WorkflowStateSucceeded,

nil}wfCtx,

v1alpha1.WorkflowStateExecuting,

err}w.wfCtx

StepStatusCache.Load(cacheKey);

{//

steps)StepStatusCache.Store(cacheKey,

v1alpha1.WorkflowStateExecuting,

err}StepStatusCache.Store(cacheKey,

len(status.Steps))if

feature.DefaultMutableFeatureGate.Enabled(features.EnablePatchStatusAtOnce)

{return

是一个的功能强大的组件部署步骤使用策略进行多集群交付。

另外使用最多的应用策略是

topologytopology

parameter.parallelismignoreTerraformComponent:

parameter.ignoreTerraformComponent}parameter:

{//usageIf

workload.ignoreTerraformComponent:

*true

核心控制器的工作原理包括核心控制逻辑中解析应用部署计划、创建应用修订版本、应用外部策略、解析执行工作流任务等四个部分本篇作为综述帮助大家初步了解

KubeVela

核心控制器的技术要点和运行机制后续我们将分别从上述四个部分进行详细解读。

参考文献

kubevelahttps://qiankunli.github.io/2022/10/23/kubevela.html

kubevela

源码分析https://qiankunli.github.io/2022/11/06/kubevela_source.html

KubeVela

源码仓库https://github.com/kubevela/kubevela