知識點：

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随笔的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。