kubevela随笔

知识点：

1、+patchKey=name 对于name字段，如果没有就加上，有的话更新。

2、webhook：trigger 当制品仓库里推送了新的镜像时，VelaUX 中会收到对应的触发请求，执行对应的workflow，从而完成自动部署

3、healthScope：对application的组件进行周期性健康检查，检查策略是component-definition里的spec.status.healthPolicy或customStatus设置的检查规则，即cue表达式，然后healthScope控制器会不断检查cue表达式是否满足（渲染eval），且检查结果会patch记录到app.status.services字段。其中每次app控制器都会获取所有的k8s对象并填充到context字段。

4、velaql 会读取cm里cue模板中的ql.#ListResourcesInApp，执行具体的provider里对应的注册的方法；而op.#Steps是怎么处理的；

5、CUE context配置项

6、workflowstep执行过程

- 1 在执行workflowstep前会首先计算app的hash是否变化，以及判断wfstatus，如果是finished、terminated、suspended则直接退出，然后会创建对应的workflow的cm，再执行TaskGenerator的run方法；
- 2 run方法中会将workflowstep的cue模板和参数生成的cue.value合并成一个新的cue.value作为taskValue，然后调用doSteps对cue中#component-apply等进行处理，对应会执行具体的provider注册的某个方法。
- 3 生成组件部署所需的Manifest及ControllerRevision
--3.1 applyComponentFunc首先会从appRev中获取workload;
--3.2 生成compManifest，即对应的完整的deployment和service等结构体
--3.2.1 生成用于处理cue模板的pCtx；
--3.2.2 根据component的cue模板（TaskLoader加载的）生成基础的workload(deploy)和auxiliary(service)的cue模板，并存入pCtx.base和pCtx.auxiliaries;
--3.2.3 基于pCtx.base和pCtx.auxiliaries，patch等、并生成compManifest即完整的deployment和service，包括根据trait struct加载trait模板并eval后unify到pCtx.base,并包含trait的patchKey的处理等;对patcher进行处理，但deploy2env中patch一直为空；eval pCtx.base和pCtx.auxiliaries并生成compManifest，即完整的deployment和service；
--3.3 然后给base、auxiliaries，即deployment、service等，添加oam相关的标签和注解，且组件有变化时生成新的componentRev
--3.4 component有变化则在deploy所在ns创建新的componentRevision即ControllerRevision
-4 渲染组件，进行apply前的准备，给workload和auxiliaries添加appRev、appRev-hash、env等标签、并检查是否由该trait管理workload
-5 部署manifest到k8s，首先会将manifest记录在rt中，之后会将manifest patch部署到k8s,并记录被部署的资源到appHandler.appliedResources
-6 分别针对component和trait根据HeathScope和CustomStatus的cue模板进行eval计算状态，并记录到appHandler.services
-7 workflowstep执行完某个provider.handler后会查看wfStatus，如果suspend、ternimated、wait为true，则直接停止workflow，等待被重新触发

7、deploy2env的流程

deploy2env内部是op.#ApplyEnvBindApp，即multicluster.#ApplyEnvBindApp，
参数有env、policy、parallel、app、namespace，共包括三步：step1：#PrepareEnvBinding，输入参数有envName、policyName，
输出patchedApp.components、decisions，包括三步：step1.1：#LoadEnvBindingEnv，输入envName、policyName，调用oam的load-policies，
**load-policies会将app中的所有policy填充到value.policyName路径下**，
然后再对数据进行整理后输出policyName和envConfig(envName对应的env-binding的数据)；step1.2：#MakePlacementDecisions，输入envName、policyName、envConfig.placement，调用multicluster的make-placement-decisions，
**make-placement-decisions会生成decision(包含cluster和ns的数组)，并将decision写到app.status.policy**，且输出是decisions；step1.3：#PatchApplication，输入envName、envConfig.selector、envConfig.patch，调用multicluster的patch-application，
**patch-application实现对patch的处理和componentSelector对component的过滤**，并输出patchedApp；step2：#ApplyComponentsToEnv，输入参数有decisions、patchedApp.components、env、waitHealthy，
共有两层遍历，第一层遍历每一个decisions，第二层遍历每一个components，然后循环内执行#ApplyComponent即调用oam的component-apply，
**component-apply实现对资源进行部署（还要细看），且通过wfTypes.wait实现waitHealthy**，
且输入是component、cluster、ns、waitHealthy、env，无输出；step3：if parallel=true，则执行#ApplyComponentsToEnv，传入的waitHealthy为true，其余和step2一致；

provider.handler和cue模板通过v *value.Value传递数据。

8、velaql流程

velaql执行流程：
// 1、组装一个workflowstep，用于完成QueryView
// 2、通过provider注册了需要的方法，并提供了TaskLoader用于加载cue模板
// 3、使用TaskLoader加载cue模板，并生成TaskGenerator函数
// 4、执行上边返回的TaskGenerator函数，并生成executor，然后并把handler放到了对应的executor，然后是很成了taskRunnertaskRunner主要有run和checkPending两个函数，并返回taskRunner
// 5、执行TaskRunner的Run方法，run方法中会将workflowstep的cue模板和参数生成的cue.value合并成一个新的cue.value作为taskValue，然后调用doSteps对cue中#component-apply进行处理，对应会执行具体的provider注册的某个方法

9、ResourceTracker

RT是app的resource的record，通过RT+finalizer相较OwnerReference方式能够自定义的GC策略。

RT的4个核心函数：
Dispatch：将资源记录到RT，然后部署资源；
Delete：mark resource，然后删除resource，应该是deprecated
StateKeep：保证资源始终处于最新版本；
GarbageCollect：资源回收，包括过期的RT等；

RT的类型：
versioned RT：保存每一更新app spec的记录；
root RT：和app共享生命周期的app的resource的record；
componentRevision RT：track所有dispatch的component controller revision，包括删除等;

10、GC过程

1、初始化cache，以k/v的形式存储所管理的resource
2、Mark阶段
如果app标记为删除则rootRT和CurrentRT也被标记删除；
如果app没有标记删除且回收策略不是passive，则标记删除所有hisRTs；
如果app没有标记删除且回收策略是passive=true，则标记删除没有引用的hisRt;
3、Sweep阶段
遍历rootRT/currentRT/hisRT 如果RT已经被标记为删除，则遍历RT下所有资源,
如果RT下的资源都已被删除，则将RT上的finalizer字段删除,
如果RT下的资源没有被全部删除，则将未删除的资源放到waiting中
4、Finalize阶段
遍历rootRT/currentRT/hisRT,如果RT已经被标记为删除且存在finalizer字段，则遍历每一个RT下的每一个资源，如果该资源仍然存在，则将其删除
5、Garbage crRT阶段
找到正在被使用的crRT,对于没有被使用的crRT则将其删除，并重新更新crRT的ManagedResources
6、Garbage legacy RT阶段
从已部署资源种找到所有的集群信息，遍历每一个集群，找到所有的RT,如果RT.spec.type为空，则将其删除。

-----------------------------------------------------------------------------------------------------------------------

KubeVela性能测试

Kubevela运行在0.5CPU、1Gi的容器里，测试创建3,000 Applications (12,000 Pods in total) on 200 nodes，花费25min，每一次reconcile的平均耗时200ms 并且99% reconciles耗时少于800ms；
Kubevela运行在1CPU、2Gi的容器里，测试创建5,000 Applications (30,000 Pods in total) on 500 nodes，花费21min，reconciles耗时前边相当；
性能测试报告地址 https://kubevela.net/zh/blog/2021/08/30/kubevela-performance-test。

kubevela随笔相关推荐

Echo团队Alpha冲刺随笔 - 第九天
项目冲刺情况进展已经进入测试阶段,正在消除系统的bug 问题通过测试,找出了系统中存在的较多bug...... 体会测试太重要了,很多原本以为没什么bug,一测就能找到好几个,而且改个bug真 ...
第一篇随笔——新的开端
新的开端这是我第一次开通博客也是第一次在博客上写随笔,这既是博客的新开端也是JAVA学习的新开端,希望能好好经营这第一个博客~. 觉得自己专业吗?对专业的期望对于这个问题我不得不坦然承认虽然进入信 ...
我先了解一下博客园创建随笔/文章/日记的过程与三者的区别(隐私等级,是否审核等)...
我先了解一下博客园创建随笔/文章/日记的过程与三者的区别(隐私等级,是否审核等) 转载于:https://www.cnblogs.com/Totooria-Hyperion/p/5260289.htm ...
web高性能开发系列随笔
在BlogJava里写了一些关于高性能WEB开发的随笔,因为都是跟前端技术相关(html,http,js,css等),所以也贴到博客园来,吸收下人气. 1. HTTP服务器. 2.性能测试工具推荐 3 ...
cuda图像处理_CUDA随笔之图像直方图(优化历程)
在忙忙碌碌许久之后,终于有时间写 "CUDA随笔" 系列的第二集了! 这次给大家带来了一个图像处理的应用例子:计算图片的直方图. 虽然使用CUDA可以很轻松地在性能上超越CPU,如 ...
博客园的“随笔、文章、新闻、日记有啥区别”
随笔:是一些比较杂乱的技术类东西且有待修改和讨论的文章,假如是原创则只是作者随时提笔写下的内容,而并没有经过太多的推敲,甚至措辞也没有得到很合理的运用. 文章:直接获得的有正规性质的文章,或当随笔中的 ...
[Object-C语言随笔之二] 《NSLog》常用的打印调试语句与自动排版
本站文章均为李华明Himi 原创,转载务必在明显处注明: 转载自[黑米GameDev街区] 原文链接: http://www.himigame.com/iphone-object/395.html ...
做一个略调皮的个人主页--相册与随笔篇
目录做一个略调皮的个人主页--菜单篇做一个略调皮的个人主页--结构篇做一个略调皮的个人主页--相册与随笔篇总算在北京找到个便宜的房子租了,算是稳定下来啦. 新工作的节奏本来很快,有些不适用的, ...
Ibatis学习随笔
Ibatis学习随笔 < person > < id > 1 </ id > < firstName > Clinton </ ...

kubevela随笔

kubevela随笔相关推荐

最新文章

热门文章