2021年阿里云KubeMeet 開發者沙龍線下演講實錄合輯（239頁）.pdf

《2021年阿里云KubeMeet 開發者沙龍線下演講實錄合輯（239頁）.pdf》由會員分享，可在線閱讀，更多相關《2021年阿里云KubeMeet 開發者沙龍線下演講實錄合輯（239頁）.pdf（239頁珍藏版）》請在三個皮匠報告上搜索。

1、卷首語伴隨著 Kubernetes 生態逐步完善，越來越多的大型互聯網終端企業開始加入到云原生梯隊中，云原生生態也在向一系列標準化趨勢演進。面對當下開發者普遍關注的云原生應用交付與管理、邊緣計算融合、多云混合云等難題，KubeMeet 系列線下開發者沙龍通過優秀經驗的總結和實踐案例的沉淀，讓我們感受到了云原生技術和開源社區的魅力。KubeMeet 是由云原生基金會 CNCF 與阿里巴巴聯合主辦的、面向一線開發者的技術交流活動，內容聚焦云原生&Kubernetes 方向，旨在通過熱門的開源技術、云原生在企業的應用實踐案例、架構設計思維等，幫助開發者學習云原生技術、交流實踐中的問題和痛點，推進云原

2、生和 Kubernetes 在國內的規?；瘧寐涞?。過去一年，KubeMeet 系列線下沙龍走過了上海、成都、深圳、杭州等城市，累計線下參與觀眾千余人，將 KubeVela、OpenYurt、OpenKruise、OCM、Sealer、Nacos 等從阿里巴巴走出來的熱門開源技術深入到了各地開發者群體當中。2021 KubeMeet 開發者沙龍線下演講實錄合輯是 2021 年度 KubeMeet 線下開發者沙龍中的演講內容沉淀，不僅包含云原生標準應用模型技術上的落地與思考、熱門開源項目的技術架構解讀、云原生應用部署開源實踐等話題，更有第四范式、攜程、極狐、Vmware、電信天翼云、深信服、招商

3、局、政采云等知名企業的一線云原生落地實踐。對于希望了解云原生應用交付與管理難題、邊緣計算融合難題的開發者，都可以在本書中找到答案和啟發。未來，也期待 KubeMeet 有機會走到你的城市，來到你的身邊。KubeMeet 杭州站活動現場合影KubeMeet 上海站參會者與嘉賓互動問答環節KubeMeet 深圳站演講嘉賓議題分享環節KubeMeet 杭州站參會現場活動氣氛高漲KubeMeet 成都站參會者針對演講內容進行記錄KubeMeet 成都站活動現場合影目錄阿里巴巴基于 KubeVela 的新一代應用交付管理系統實踐5AIOS 應用管理和交付實踐29OpenKruise：實現 Kuberne

4、tes 中容器粒度的不可變基礎設施41OpenKruise 在攜程的應用實踐56基于 KubeVela 面向混合環境的應用交付64Open-Cluster-Management(OCM)多云混合云容器編排引擎及阿里實踐79基于 GitLab+KubeVela 的 GitOps 實踐86OpenKruise 帶給云原生應用管理的新變化100開啟邊緣設備的云原生管理能力115深入理解 OpenYurt125深信服智能邊緣計算平臺與 OpenYurt 落地方案探索與實踐144從中心走向邊緣深度解析云原生邊緣計算落地痛點152OpenKruise 提升云原生應用自動化新高度174混合云環境云原生應用交

5、付和管理平臺190集群鏡像重塑分布式應用交付203政采云私有化業務交付實踐213開放模塊化多集群管理平臺 OCM218Nacos2.0 的 K8s 服務發現生態應用及規劃2285阿里巴巴基于 KubeVela 的新一代應用交付管理系統實踐阿里巴巴基于 KubeVela 的新一代應用交付管理系統實踐作者：王仁達(封崇)，阿里云高級技術專家。主要負責云原生應用管理和云資源管理相關工作，致力于提升客戶上云效率，推動云原生應用管理實現自研、開源、商用三位一體技術統一。議題簡介：隨著“云原生”的普及，越來越多的應用開發者開始追求快速構建交付應用，然而使用場景的不同往往意味著應用交付環境會有巨大的差異。如

6、何將應用管理和交付變得標準化，使應用研發不再需要花大量精力對接不同的交付平臺，逐漸成為云原生應用管理的一大痛點。本次分享將針對這些問題介紹如何基于 KubeVela 構建標準化的應用交付管理平臺，及阿里巴巴在此基礎上的實踐經驗。一、云原生應用交付面臨的問題與挑戰1、多樣化的交付環境是云原生應用交付面臨的挑戰：a、Workload 多樣：對接不用集群環境、灰度發布、流量管理方案；b、部署環境多樣：公共云、專有云、私有化部署，對接不同 APM 方案；c、云資源使用多樣：對接不同 Provider、云資源管理方案，對接云產品差異化配置。多樣化的交付環境，對于應用開發者來說門檻較高，需要了解 K8s

7、復雜的參數、配置等；而對于平臺開發者來說，開發成本較高，需要寫各種 controller 來完成比如像封裝等能力。2、基于 K8s 資源組合也存在同樣問題：a、復雜、難懂、門檻高；b、能力局限、不同場景各不相同；c、不統一，每個模式需要重新編寫發布對接。阿里巴巴基于 KubeVela 的新一代應用交付管理系統實踐阿里巴巴基于 KubeVela 的新一代應用交付管理系統實踐kubernetes-sigs/application4、Helm Chart：a、黑盒，不明確內部有哪些資源；b、缺失發布能力，helm upgrade 沒有灰度能力；c、無法使用/對接云資源；阿里巴巴基于 KubeVela

8、 的新一代應用交付管理系統實踐阿里巴巴基于 KubeVela 的新一代應用交付管理系統實踐a、基于 Kubernetes 和 OAM 模型構建；b、純 Golang 編寫；c、社區發起，社區構建；d、2021.03 KubeVela 1.0 發布；e、1.7k star，60+contributors；2、KubeVela 1.0 的主要能力a、豐富的抽象模板能力（組合、轉換、拆分、狀態回流、數據傳遞等）；b、漸進式發布能力；c、應用云資源創建和綁定；d、多集群、多環境的應用部署；e、使用 Helm chart 對接 KubeVela Traits 生態；3、KubeVela 的 Applic

9、ation 對象Application 對象包括組件類型、鏡像與啟動參數，多組件、彈性擴容和可靈活擴展的其它能力等，它具有以下優勢特點：a、完整的應用描述文件（以應用為中心）；b、靈活的“Schema”（能力模板自由組合）；阿里巴巴基于 KubeVela 的新一代應用交付管理系統實踐阿里巴巴基于 KubeVela 的新一代應用交付管理系統實踐b、運維能力KubeVela的運維能力寫作方式和component 的主要區別是要聲明Trait 應用的 workload是什么，以及 CRD 對象（某些情況下 CRD 也可以不指定），其它能力基本和 component 一樣。c、示例：上線新功能 met

10、rics平臺研發團隊：開發了一個新 Operator 叫做 metrics（監控），編寫一個 K8s 能力描述文件metrics.yaml；阿里巴巴基于 KubeVela 的新一代應用交付管理系統實踐阿里巴巴基于 KubeVela 的新一代應用交付管理系統實踐d、查看“能力模板”的用法$vela show webservice能力模板注冊時，KubeVela 控制器會自動生成 OpenAPI v3 的 json schema 文件和文檔；通過 vela 的命令行工具可以查看；用戶也可以自己基于 json schema 去渲染集成進自己的前端。5、KubeVela 為什么能對不同 Workloa

11、d 做統一發布？a、工作負載類型：統一類型注冊和識別；b、健康檢查：統一狀態檢查和回流；c、發布模式：統一發布方式；d、資源模板：統一抽象方式。阿里巴巴基于 KubeVela 的新一代應用交付管理系統實踐阿里巴巴基于 KubeVela 的新一代應用交付管理系統實踐模板參數，組裝成一個應用，在發布的時候由 KubeVela 把資源創建出來。所以 KubeVela 團隊協作的邊界相對比較清晰。2、KubeVela 應用管理依賴的能力a、抽象能力各種資源組合、拆分無需寫各種 Controller 對接安全的 patch 方案b、應對交付場景支持 helm 用于交付場景c、企業級應用發布能力版本化分批

12、發布滾動發布/原地發布發布暫停發布回滾日志監控健康檢查多版本部署多版本流量灰度多集群/多環境灰度d、云資源管理能力多種資源編排方案(Terraform、Crossplane)標準化應用綁定阿里巴巴基于 KubeVela 的新一代應用交付管理系統實踐阿里巴巴基于 KubeVela 的新一代應用交付管理系統實踐VolumeConfigMap阿里巴巴基于 KubeVela 的新一代應用交付管理系統實踐阿里巴巴基于 KubeVela 的新一代應用交付管理系統實踐5、漸進式發布a、面向終態模式現在社區基本上是基于流量管理的發布，最常見的像 rolling，比如說按副本數的調整。但有些模型其實不太適合用

13、rolling 的方式，而且也很難維護。KubeVela 補足了這方面的能力，支持按流量發布。下圖是按照副本數支持 rolling 的一個方案。面向終態模式是指在 application 里指定 rollout策略，它的工作機理是每次更新 application 的時候，KubeVela1.0 就新增一個 AppReversio-n 的操作對象，這個對象就等于是一個應用的完整的 snapshot，它包含了 definition 里面抽象的信息，也包含了轉化到 K8s 里面 APP 終態的信息，是個非常完整的一個鏡像。阿里巴巴基于 KubeVela 的新一代應用交付管理系統實踐阿里巴巴基于 Ku

14、beVela 的新一代應用交付管理系統實踐b、發布單模式任何 PaaS 發布的時候都有一個發布單，K8s 是面向終態的，發布就是從一個版本到另一個版本的過程。發布單模式的工作原理是在更新 application 的時候，每次都會創建一個 AppRevision，但此時只會創建一個鏡像，不會真正把資源下發下去，通過 AppRollout 的時候，它先接管應用的生命周期，把整個資源渲染出來下發到集群里。當發布完成之后，再把控制權交回給 applicati-on。阿里巴巴基于 KubeVela 的新一代應用交付管理系統實踐阿里巴巴基于 KubeVela 的新一代應用交付管理系統實踐發布單模式下 Ap

15、plication 的更新不再實際操作資源，只生成版本快照；擴縮跟發布使用相同模型。d、面向終態的多版本共存KubeVela 提供多版本，有多個 Revision，按照流量邏輯去發布，通過 TrafficRules 指定不同版本的流量配比，每個 Revision 部署在不同的集群上，指定多集群的 clusterSelector 參數。它的工作原理和 Rollout 類似，亦即 application 的變化只生成 Revision，然后由 deployme-nt 去創建 K8s 資源。阿里巴巴基于 KubeVela 的新一代應用交付管理系統實踐阿里巴巴基于 KubeVela 的新一代應用交付管

16、理系統實踐e、多環境/多集群/多版本現在規劃要做一個多環境/多集群/多版本的漸進式發布。首先定義環境，環境包括所依賴的集群和包，同時還要做一個基于環境的 patch，類似于kustomize-style 風格模板，指定相應的參數，patch 到不同的環境上。在真正集群里，比如說一個 application，對每一個 environment，patch 生成相應的 App Revision，然后復用這個application 的 deployment 多版本發布。6、云資源管理云資源管理有兩種方式，一個是單應用，一個是多應用。a、云資源管理的單應用完成供給和消費單應用是在一個應用里聲明云資源的供

17、給，比如說把 RDS 創建出來，同時做資源消費，把應用綁定。假如 application 有兩個 component，一個 component 是云資源的配置，創建 RDS，同時指定要綁定的 secret。這個背后有兩個能力模板，一個是做資源供給的，對接社區的方案，因為它本身 API 設計很好，擴展性很強，尤其是 secret 回血的能力，可以做成一個非常標準的東西。阿里巴巴基于 KubeVela 的新一代應用交付管理系統實踐阿里巴巴基于 KubeVela 的新一代應用交付管理系統實踐在使用不同資源的時候（比如 AWS，或者是阿里云），所產生的資源 output 是不一樣的，同樣的數據庫賬號比

18、如 db-name 的名字可能是不一樣的，有的可能是大寫，有的可能是小寫，那我們可以通過 insert 做一個轉換的邏輯，上面所說的 patch 過程是穩定不動的，我們可以用中間態去做 patch，對接不同的輸出資源。c、云資源管理集成 TerraformTerraform 已成為云資源管理事實上的一個標準，KubeVela 也正在集成 Terraform，做成一個正式化的 controller。其示意圖如下：阿里巴巴基于 KubeVela 的新一代應用交付管理系統實踐AIOS 應用管理和交付實踐AIOS 應用管理和交付實踐作者：馬浩，第四范式-機器學習平臺資深工程師，專注機器學習平臺應用，模

19、型，workflow，metadata 等組件和模塊的構建和優化。議題簡介：為了更好解決 AI 落地難題，更好地利用云原生技術紅利，為企業、生態伙伴、開發者提供更好的應用管理和交付平臺，第四范式基于 OAM kubernetes runtime+擴展的Workload 和 Trait 打造統一的 AIOS，使多個生態伙伴以較低的改造成本完成 AIOS 接入，同時為內部建模中 DAG 計算提供更靈活的計算服務。本次分享將基于上述經驗，介紹如何基于OAM 在 Kubernetes 之上開發聚焦應用、具備可靠性、可擴展性、可維護性的 PaaS。一、背景AIOS 是第四范式的一個機器學習的平臺，在 A

20、IOS 之前，第四范式會把所有的產品 All-In-One 的打成一個包，通過 DevOps 開發的腳本給客戶部署。但是隨著產品的不斷豐富完善和客戶場景的日漸復雜化，這種 All-In-One 的模式帶來了一些問題：迭代慢、靈活性差、不夠開放。在這種情況下第四范式提出了 AIOS 的概念：1、所有的東西都是 App；2、Internal App,Eco Partner App,Developer App，所有的能力圍繞 App 來打造；3、插件化；4、底層有 Kernel 來支撐 App，App 和 Kernel 可以獨立發布；AIOS 應用管理和交付實踐AIOS 應用管理和交付實踐Open

21、Application Model Specification第四范式采用了將核心的業務邏輯做成 component 的鏡像，其它四個方面圍繞 OAM 的trait 加上 workload 去做 App 的封裝的思想，設計了如下架構：該設計方案將上層 App 的靜態文件通過集群的 Nexus 去展示，動態文件通過 AppConfig 去拉取，一個 App 可以拉取多個 Instance，每一個 Instance 可以拉取多個 AppConfig。這個方案不僅可以滿足 App 的需求，算子平臺、Model-Serving、Hypercycle ML 也都可以通過這個架構來滿足。二、實踐和場景落地

22、1、實踐AIOS 應用管理和交付實踐AIOS 應用管理和交付實踐下圖是 component 和 service 的模板示例：基于上面的模板，可以設計 AppFormat，主要包括 app 和 component 兩個文件夾：app 文件夾包括：app 靜態文件和 service.yaml 模板；component 文件夾包括：docker tar，component.yaml 模板，flyway 等。AIOS 應用管理和交付實踐AIOS 應用管理和交付實踐c、Model Serving 場景AIOS 應用管理和交付實踐AIOS 應用管理和交付實踐三、問題和挑戰1、問題一：ManualScale

23、rTraita、副本數問題：ManualScalerTrait 負責副本數，但在上線一段時間后發現副本數自動發生了變化，原來是K8s 的 Server-Side Apply 允許多個 controller 控制一個 resource，這個過程如下：workload 創建 deploy；trait 更新副本數為 3；當更新 appconfig image 從 1.0.0 到 2.0.0；workload 把副本數改回到 0。使用過程中我們不希望 workload 修改副本數，得到社區的反饋是不建議全量更新 deployme-nt 而是去增量更新。AIOS 應用管理和交付實踐AIOS 應用管理和交

24、付實踐statefulSet 禁止更新 volumeClaimTemplatesb.、解決方案：目前還是采取提前渲染 volumeClaimTemplates 的方法，但我們還是希望 VolumeMouterTra-it 去完成這個事情，社區已有同事在做，目前已經完成大部分的開發工作。社區參考網址：https:/ Binding隨著 component 的不斷增多，可以拿到 componentHub 等能力，有中間件的，有 app 注冊的，當解決了一個 AppConfig 之后，是否可以把多個 app 還有中間件的部署，通過 bindi-ng 的能力綁定起來？讓業務只需要渲染 yaml 就可以

25、迅速拉起服務，同時在 bingding 增多的時候，可以在 bingding 上端集成一整套解決方案。這個探索未來面臨服務調用的問題，狀態管理怎么去做，是否可以參考 event driver 去做，以及如何利用 sidecar 等問題。AIOS 應用管理和交付實踐OpenKruise：實現 Kubernetes 中容器粒度的不可變基礎設施OpenKruise：實現 Kubernetes 中容器粒度的不可變基礎設施作者：王思宇(酒祝)，阿里云技術專家、OpenKruise 作者&負責人，Kubernetes/OAM 社區貢獻者，長期從事云原生、容器、調度等領域研發；阿里巴巴百萬容器調度系統核心研

26、發成員，多年支撐阿里雙十一超大規模容器集群經驗。議題簡介：眾所周知，原生 Kubernetes 限制了最小操作單元為 Pod 級別，默認情況下我們只能操作擴容、縮容 Pod，甚至發布升級都是依賴于擴縮 Pod 來完成的。而 OpenKruise 在不對原生 Kubernetes 做任何侵入的基礎上，為用戶提供了更多細化到容器粒度的控制能力。在本次分享中，我們將會主要介紹 OpenKruise 項目是如何在不侵入 Kubernetes 的前提下實現這些容器粒度操作能力，以及用戶如何通過使用 OpenKruise 這些能力更好地部署運維和管理云原生應用。一、OpenKruise 是什么1、Open

27、Kruise 簡介Kruise 是 Cruise 的諧音，K for Kubernetes，寓意是 Kubernetes 上應用的自動化巡行，它是：CNCF 托管的 Sandbox 項目；阿里云開源的基于 Kubernetes 的云原生應用自動化套件；阿里巴巴經濟體上云全面使用的部署基座；2、OpenKruise 的用戶國內用戶：阿里巴巴、螞蟻、攜程、美團金融、網易、小米、OPPO、有贊、蘇寧、比心、申通、小紅書、掌門教育、杭銀消費、哈啰出行等。國外用戶：Lyft、Bringg、Arkane Systems、Spectro Cloud、Linkedin 等。OpenKruise：實現 Kube

28、rnetes 中容器粒度的不可變基礎設施OpenKruise：實現 Kubernetes 中容器粒度的不可變基礎設施ImagePullJob支持用戶指定在任意范圍的節點上預熱鏡像。4、OpenKruise 即將提供的功能容器重啟支持對 running Pod 中的指定容器觸發重啟操作；級聯刪除防護防護 CRD、Namespace、Workload 的刪除操作，避免批量 Pod 等資源被誤刪除；PodUnavailableBudget應用 Pod 可用性保護，相對于只能限制驅逐的 PDB，PUB 能保護 Pod 的刪除、驅逐、原地升級等所有會導致服務不可用的操作；全局 Pod 刪除流控可配置集群

29、中 Pod 刪除流控規則，在限定時間范圍內刪除 Pod 數量超過閾值后則發生熔斷；通用 operator 擴展支持對 operator 做運行時管控，通過水平擴展、灰度升級能力解決 controller 單主問題，外部對 controller 的異常行為做攔截防護、控制爆炸半徑，同時帶來更靈活的集群內多租能力。二、什么是容器粒度的不可變基礎設施1、Kubernetes：Pod 維度的不可變基礎設施OpenKruise：實現 Kubernetes 中容器粒度的不可變基礎設施OpenKruise：實現 Kubernetes 中容器粒度的不可變基礎設施2、OpenKruise 所提供的容器粒度管控能

30、力a、應用部署層面，以 CloneSet 為例：支持修改 image 以及 labels/annotations 原地升級；Pod 原地升級b、sidecar 容器定義：支持獨立定義 sidecar 容器；一次聲明，應用規?；⑷?；c、容器管理：支持對任意 running Pod 中一個或多個容器做重啟操作；d、鏡像預熱：指定任意范圍的節點上批量拉取鏡像；OpenKruise：實現 Kubernetes 中容器粒度的不可變基礎設施OpenKruise：實現 Kubernetes 中容器粒度的不可變基礎設施Kubernetes+OpenKruise 形態在 Kubernetes+OpenKrui

31、se 形態中，增加了 kruise-manager 和 kruise-daemon 組件，通過這個兩個組件，OpenKruise 提供了一系列的拓展能力。1、原地升級能力a、技術背景背景 1：kubelet 計算容器 hash。當 Pod 的某個容器的 image 發生了變化，hash 值就發生變化，Kubelet 就會停掉舊容器，啟用新容器。背景 2：apiserver 對 Pod 更新限制。目前對于存量 Pod 只允許更新 spec 中以下字段：OpenKruise：實現 Kubernetes 中容器粒度的不可變基礎設施OpenKruise：實現 Kubernetes 中容器粒度的不可變基

32、礎設施結論：對于一個現有的 Pod，我們能且只能修改其中的 spec.containersx.image 字段，來觸發Pod 中對應容器升級到一個新的 image。如何判斷升級成功由背景 3 可知：比較 spec 和 status 中的 image 字段是不靠譜的，因為很有可能 status 中上報的是 Node 上存在的另一個鏡像名（相同 imageID）；結論：判斷 Pod 原地升級是否成功，相對來說比較靠譜的辦法，是對比升級前后的 imageID 是否變化；隱含的問題：不能用 tag 不同、實際 imageID 相同的鏡像做原地升級。如何保證流量無損由背景 4 可知：addon 組件可以

33、通過設置 readinessGates 和更新 pod.status.conditions 中的自定義狀態，來控制 Pod 是否可用；結論：定義一個叫 InPlaceUpdateReady 的 readinessGate，升級前修改 condition 為 not ready，升級完成后修改 condition 為 ready。達到原地升級過程中摘流的目標。原地升級是否存在一些問題？Q：原地升級能否支持修改 env 等字段？A：由于 apiserver 的限制，目前只能支持針對 image 的原地升級，修改 env 等其他字段還是會觸發重建升級。Q：通過 imageID 判斷升級完成有什么隱含

34、問題？A：不能用 tag 不同、實際 imageID 相同的鏡像做原地升級。Q：通過 readinessGate 切流是否有損？A：為了避免摘流延遲，Kruise 提供了優雅靜默時間，可以等待摘流一段時間后再真正執行升級。OpenKruise：實現 Kubernetes 中容器粒度的不可變基礎設施OpenKruise：實現 Kubernetes 中容器粒度的不可變基礎設施4、Pod 容器重啟（重建）通過聲明一個名為 ContainerRecreateRequest 的 CRD，指明 Pod 中要重啟的容器，Kruise-manager 會向其中補充一些信息，節點上的 Kruise-daemon

35、 感知到信息后，和 kubelet 配合，Kruise-daemon 執行 preStop 和 stop，然后由 kubelet 重建，從而實現對 K8s 無損的容器重啟。OpenKruise：實現 Kubernetes 中容器粒度的不可變基礎設施OpenKruise：實現 Kubernetes 中容器粒度的不可變基礎設施原地升級 Pod 中某個容器時，其他容器保持正常運行，網絡、存儲均不受影響。3、使用 SidecarSet 管理 sidecar 容器a、原生 K8s 用法存在的問題：業務 Pod 里面包含了運維、安全、代理等多個 sidecar 容器，業務不僅要完成自身主容器的配置，而且還

36、需要熟悉這些 sidecar 容器的配置（增加了業務方的工作量和風險）；Sidecar 容器的升級需要連同業務主容器一起重建（原生 Deployment 等 workload 基于Pod 重建來實現 Pod 的滾動升級），推動和升級支撐著線上數百款業務的 sidecar 容器（極大的業務阻力）；作為 sidecar 容器的提供者對線上諸多各種配置以及版本的 sidecar 容器沒有直接有效的升級手段（潛在的管理風險）。b、SidecarSet 特性：配置單獨管理：為每一個 sidecar 容器配置單獨的 SidecarSet 配置，方便管理；自動注入：在新建、擴容、重建 pod 的場景中，實現

37、 sidecar 容器的自動注入；原地升級：支持不重建 pod 的方式完成 sidecar 容器的原地升級，不影響業務主容器，并包含豐富的灰度發布策略；熱升級（v0.9.0）：對于 envoy/nginx 這類接入流量的 sidecar 容器，默認原地升級過程中會導致流量中斷。V0.9.0 版本的 SidecarSet 提供 sidecar 熱升級能力（同時也需要 sidec-ar 中的進程支持熱切換）。3、組合拳：鏡像預熱+擴容a、原始 Pod 擴容的流程/耗時，可以看到最長的是 app 容器和 sidecar 容器拉鏡像的耗時：OpenKruise：實現 Kubernetes 中容器粒度的

38、不可變基礎設施OpenKruise：實現 Kubernetes 中容器粒度的不可變基礎設施在使用 OpenKruise 的原地升級之后，沒有優化的部分還有拉取少量 image layer 的耗時，如何繼續優化呢？c、原地升級+鏡像預熱：在灰度第一批 Pod 的時候，提前在后續批次 Pod 的節點上預熱即將發布的新版鏡像，當后續的這些 Pod 真正做原地升級的時候，就不需要拉取鏡像；d、終態原地升級：所以，最終的原地升級耗時就是啟動應用的耗時，中間過程的時間都被優化了。OpenKruise 在攜程的應用實踐OpenKruise 在攜程的應用實踐應用發布：FAT GroupUAT Group（接近

39、生產環境的測試環境）PRO Group（生產環境）Group 發布：堡壘金絲雀第一批次最后批次實例發布：拉出實例部署實例點火拉入實例4、PaaS 1.0 經典部署模式如上圖，PaaS 1.0 部署模式存在以下不足：虛擬機思維：先分資源再發布，限制擴容能力；CMS 為中心化存儲，多云場景實時性不足，無法滿足快速變化場景；K8s 只用來做資源調度，限制了發揮；PaaS 需要負責實例的拉入拉出，比較繁重；二、攜程如何實現 K8s 云原生發布1、部署模式PaaS2.0 云原生部署模式的核心是以 K8s 做為 PaaS 引擎，做了以下改進：OpenKruise 在攜程的應用實踐OpenKruise 在攜

40、程的應用實踐抽象出具有可擴展性的工作流引擎；操作皆可作為變更，細粒度拆分為 Step；過程用戶透明，易于排障；變更支持在任意節點重試與回滾，降低用戶試錯成本。3、基于 Kruise 的 Rollout 云原生發布方案發布流程 Operator 化，下沉至 K8s；中間件 Operator 化，下沉至 K8s，簡化發布流程；精確控制發布流程（堡壘，金絲雀，滾動）；落地 Kruise 原地升級能力；同時支持無狀態有狀態發布；無狀態：28000+CloneSet有狀態：200+StatefulSet然后看下中間件，這里中間件主要是流量的入口，定義了一些 lable 的規范，用于控制流量的拉入拉出。O

41、penKruise 在攜程的應用實踐OpenKruise 在攜程的應用實踐e、對 inplace update 的修復和改進，當有多個 hook 的時候，在 update 完成后，未等到所有的 hook 移除就變成 normal 狀態，攜程內部有些有狀態應用，希望將 lifecycle hook和 inplace update 結合，于是增加了 lifecycle hook 對 AdvancedStatefulSet 的支持。三、攜程 PaaS 平臺后續規劃1、目標和挑戰目標：控制面高可用的集群聯邦，跨集群、跨 AZ 高可用，實現自動化容量管理。挑戰：發布涉及所有資源集群聯邦改造；發布狀態難以

42、判斷（zone、cluster）；存量 Group 如何無損遷移到集群聯邦；對于 HPA 的高可用，是類似 Fed 的設計，如下圖：OpenKruise 在攜程的應用實踐OpenKruise 在攜程的應用實踐3、Kruise 新特性落地a、Pod 生命周期 hook:原地升級前執行拉出，原地升級后做流量拉入；b、安全防護：刪除、更新、驅逐保護；c.、原地升級與鏡像預熱結合?；?KubeVela 面向混合環境的應用交付基于 KubeVela 面向混合環境的應用交付力推動了 OAM 模型的落地和發展。2021 年 6 月 OAM/KubeVela 正式成為 CNCF 項目（https:/ 月，K

43、ubeVela 發布 v1.1 版本，其核心能力是多集群混合云的管理能力。2、面向多云多環境的易用可擴展的部署引擎OAM/KubeVela 流程圖OAM/KubeVela 流程圖展示了基于 OAM 模型設計部署的拓撲結構、策略以及工作流。最上面End User 代表 KubeVela 面向的最終開發者；Workflow 工作流引擎用來解決 OAM 應用的完整交付鏈路和交付反饋問題，它是 KubeVela 的核心實現；KubeVela 下面是根據策略和工作流將應用的組件分發到目標云、IoT/邊緣設備，或者任意 Kubernetes 集群?；?KubeVela 面向混合環境的應用交付基于 Kub

44、eVela 面向混合環境的應用交付運維能力 traits應用部署后的持續運維，比如路由規則、自動擴縮容規則等 像樂高一樣可以附著作用于組件上；應用的全局策略 policies比如多集群分發策略、安全策略、健康檢查策略、防火墻規則等，任何一個部署前需要遵守的規則都可以在這個階段聲明和執行；交付工作流 workflow比如藍綠部署、帶流量的漸進式部署、手動審批等任意的管道式持續交付策略?；?KubeVela 面向混合環境的應用交付基于 KubeVela 面向混合環境的應用交付示例 1：組件定義示例 2 是 sidecar 容器注入的運維特征，通過 patch 的方式注入到組件中使 Deploym

45、ent 的配置更加豐富。示例 2：運維特征定義基于 KubeVela 面向混合環境的應用交付基于 KubeVela 面向混合環境的應用交付關于 IaC 存在缺陷的相關討論State of infrastructure drift 2021下載地址： IaC 的缺陷，在 IaC 模式（CUE）的基礎上增加一個統一控制平面，管理應用工作流和生態對接。如下圖所示，開發者（Application）編寫一個 yaml 文件放入集群中形成從希望狀態到現實狀態的循環控制，然后結合上層 API 及對象 UI 體驗回流到用戶端以實現品牌化體驗?；?KubeVela 面向混合環境的應用交付基于 KubeVela

46、 面向混合環境的應用交付模式二：下發 Pull 模式，使用 Cluster Gateway 對接 OCM 獲取狀態當遇到邊緣集群或網絡受限集群無法直接通訊時，就需要 Pull 模式來解決。如下圖所示，底層Runtime Cluster 通過 OCM 管理證書注冊到 Cluster gateway，Cluster gateway 借助代理的Tunnel 反向獲取資源。這種模式的下發使用 Pull 模式，而回流則仍然需要主動查詢。四、KubeVela 多集群（混合云）方面的用戶場景綜合上面對 KubeVela 的介紹，總結以下幾個主要的用戶場景：基于 KubeVela 面向混合環境的應用交付基于

47、KubeVela 面向混合環境的應用交付3、場景三：混合環境（多集群、混合云）應用交付控制平面特點：圍繞應用的多集群資源編排和部署；混合環境差異化部署；圍繞應用的多集群狀態查詢；跨環境部署工作流；開發者經常遇到的場景是從開發環境、測試環境到生產環境的多環境或混合環境的實踐，或面對不同客戶的集群，都會需要使用多集群、混合云的部署模式，即運用控制面進行應用集群編排，再分發至多個集群的分發流程?；?KubeVela 面向混合環境的應用交付基于 KubeVela 面向混合環境的應用交付5、場景五：GitOps 多集群/多環境應用交付特點：無縫對接各類傳統 CI；完全基于 Pull 模式的 GitOp

48、s 支持；基于集群環境的自治；發布維度的場景，是基于 Pull 模式的 GitOps 體驗。當上層 CI 完成后生成 image 并推送到應用配置倉庫進行變更，之后被 KubeVela 獲取后進行 CD 流程。Pull 模式下，控制面數據下發以后，runtime 集群會自動訂閱數據 repo 的變化，形成集群自治?；?KubeVela 面向混合環境的應用交付Open-Cluster-Management(OCM)多云混合云容器編排引擎及阿里實踐Open-Cluster-Management(OCM)多云混合云容器編排引擎及阿里實踐作者：金敏(左修)，阿里云開發工程師，Kubernetes 維

49、護者一、OCM 概述1、OCM 定義OCM 是企業級多集群管理平臺開源社區項目，也會是未來開源社區多集群工作小組 SIG Multi-Cluster 主推的多集群管理平臺。目前主要的生態合作維護伙伴主要有支付寶、阿里云、RedHat，Microsoft Azure。同時，OCM 項目也正在積極和生態中相關的優秀開源社區項目比如 KubeVela，ArgoCD，騰訊云 Clusternet、OpenKruise、Submariner 等等研發集成，通過登陸 OCM 多集群管理平臺，可以平滑引入更多優秀云原生開源項目到實際生產中。2021 年底，OCM 進入 CNCF 沙箱項目。網站鏈接：http

50、s:/open-cluster-management.io/2、OCM 的核心優勢OCM 作為多集群容器資源管理平臺的核心優勢在于：高度模塊化，功能可以根據場景自由裁剪；可納管集群數量規模多；分布式自治架構，更強容災能力；自定義拓展性強；廠商中立；Open-Cluster-Management(OCM)多云混合云容器編排引擎及阿里實踐Open-Cluster-Management(OCM)多云混合云容器編排引擎及阿里實踐c、站點級別彈性問題站點級別彈性問題包括：機房級別離線：支付寶 527 事故；機房級別伸縮：雙十一大促擴容建站；三、OCM 架構1、OCM 整體架構對標 KubeFed 架構，

51、KubeFed 架構是在多機房/站點之上由一個中樞大腦做決策和部署，屬于Push 架構；OCM 架構是將中樞大腦分割開沉到各個機房/站點中，每個機房自治管理，屬于Pull 架構。OCM 架構的優勢體現在以下幾個方面：a、機房集群高度自治：當遇到網絡分區或機房災害的情況時，機房內部可以實現自治，根據自身情況判斷，而不是通過大腦自動化下達操作指令；b、開放式插件化：OCM 是模塊化，模塊支持熱插拔，即可以在模塊運行時進行安裝或卸載；“輕”管控面；c、“零信任”握手控制權限：不同于之前的中樞集群和子集群的控制管理關系，OCM 的子集群和中樞集群是從“零信任”開始握手慢慢放開權限，在注冊管理方面有效避

52、免了異構環境中可能產生的子集群對中樞集群的侵害。Open-Cluster-Management(OCM)多云混合云容器編排引擎及阿里實踐Open-Cluster-Management(OCM)多云混合云容器編排引擎及阿里實踐4、OCM 特性雙向互信的集群注冊及注銷管理；多集群路由/匹配規則編寫；多集群資源/配置下發能力；插件框架允許開發者自由集成；5、阿里云開源家族關系OCM 在阿里內部定位是多集群基礎功能/資源管理的界面。下圖展示了 OCM 與阿里云開源家族的關系。Open-Cluster-Management(OCM)多云混合云容器編排引擎及阿里實踐Open-Cluster-Managem

53、ent(OCM)多云混合云容器編排引擎及阿里實踐3、阿里云 CNStack AECP 遷移到 OCM 作為底層引擎AECP 是一個基于 Kubernetes 的私有化容器管理平臺。在 CNStack 內作為容器管理產品與其他的產品（EDAS、MQ 等）一起在小天基平臺上部署和運維。小天基也是一套包含 Kubernetes的管理平臺，以及一系列基礎服務，其中一些基礎服務以虛擬機為運行環境。目前正在緊鑼密鼓構建基于 OCM 的高級多集群產品能力。4、螞蟻集團 PaaS 多集群建站及演練在阿里/螞蟻的 LDC 應用架構下，一個應用根據自己的業務屬性可以被劃分到不同 Cell 里進行部署，可能是 G-

54、Zone，C-Zone 或者 R-Zone。而 Cell 和物理集群之間事實上是多對多的關系：一個集群可能被規劃切割為多個 Cell：這也是最常見的默認的場景，一個集群從被創建出來再到可以進行 LDC 架構的應用的部署之間就需要管理員提前將其切割為多個 Cell；一個 Cell 可能橫跨多個集群：在實際的場景中，因為某些歷史原因，單個數據中心里會同時部署多個 Sigma/Kubernetes 集群；除此之外，在新春紅包的場景中，還出現了在單個 IDC中擴建 ASI 集群的需求，出現這些 ASI 集群的 Cell 也可能是同時橫跨 Sigma 集群的?；?GitLab+KubeVela 的 G

55、itOps 實踐基于 GitLab+KubeVela 的 GitOps 實踐3、GitLab 十年演進發展之路GitLab 從 2017 年開始持續保持每個月一個小版本發布，每年一個大版本更新。4、一體化 DevOps 平臺將 DevOps 平臺一體化可以提高系統維護能力，降低維護時間和成本。比如針對安全方面的管理，在平臺沒有一體化之前，平臺中任何功能的升級都不能錯過，一旦錯過就會造成安全隱患，現在只需要升級 GitLab 就可以將平臺上所有功能同步升級?；?GitLab+KubeVela 的 GitOps 實踐基于 GitLab+KubeVela 的 GitOps 實踐CI/CD Work

56、flow push 模型2、GitOps 特性GitOps 的特性主要包含以下幾個方面：以聲明式系統(包括基礎設施和應用程序)為基座(典型如 Kubernetes)；如下圖所示，在 GitOps 的這種模式中有一個保存配置文件的倉庫與配置文件保持實時同步，以實現簡化流程以及提高可觀測性；以 Git(典型如極狐 GitLab)為單一可信源；一切皆代碼(應用程序&基礎設施)。GitOps pull 模型基于 GitLab+KubeVela 的 GitOps 實踐基于 GitLab+KubeVela 的 GitOps 實踐三、KubeVela+GitLab1、GitOps+KubeVelaKubeV

57、ela 作為一個聲明式的應用交付控制平面，就是為 GitOps 而生。從下圖的針對 KubeVela 和 Kustomize、Helm 的對比可以看出，Kustomize 和 Helm 都包含了多層的字段，而其中一些基礎設施相關字段對于業務開發者來說并不需要關注，如果強制他們參與則會產生更多的問題。反觀 KubeVela 是將平臺和業務的功能分開，平臺提供模板和架構，業務只需要根據具體需求填寫相關參數即可。2、Push 模型Push 模型是 CI/CD 模式，如下圖?；?GitLab+KubeVela 的 GitOps 實踐基于 GitLab+KubeVela 的 GitOps 實踐4、靈活

58、編排-有向無循環水線 DAG Pipeline有向無環流水線(DAG Pipeline)能夠突破普通流水線中前序步驟所有任務執行完后，才能執行后續步驟中任務的限制。支持按照任務為粒度進行跨步驟的關聯建立，降低任務等待時間的浪費。并提供可視化能力快速識別任務的運行情況。適用場景操作系統類軟件；多平臺支持類軟件；單倉庫多模塊微服務應用；價值體現減少任務等待時間；提升流水線執行效率；加快交付結果反饋；直觀呈現任務關系；基于 GitLab+KubeVela 的 GitOps 實踐基于 GitLab+KubeVela 的 GitOps 實踐7、app.yaml 配置相比 kustomize 和 Helm

59、，以應用為中心的 KubeVela 對于開發更加友好，無需操心各種無關字段，專注業務相關配置即可。Demo 地址：https:/ GitLab+KubeVela 的 GitOps 實踐基于 GitLab+KubeVela 的 GitOps 實踐2）基礎設施Kubernetes與 GitLab Agent 集成安裝新代理；系統自動生成一個唯一的 token（下圖紅框中），打開 CLI 并連接到需要安裝代理的集群使用給出的命令進行安裝即可?；?GitLab+KubeVela 的 GitOps 實踐基于 GitLab+KubeVela 的 GitOps 實踐為積極響應國家“十四五規劃和 2035

60、年遠景目標綱要”指導精神，進一步推動中國開源、開放GitOps 技術在各“產學研”領域的規范化實施和落地，極狐信息技術(湖北)有限公司聯合云原生計算基金會（CNCF）共同發起“開源 GitOps 產業聯盟”（Open GitOps Industry Alliance，英文簡稱：OGA），致力于支撐國家相關技術標準的研究制定和規范實踐，構建國內外領先開源技術提供商與行業用戶之間的研究、交流平臺，推動開源、開放 GitOps 技術在中國的自主創新發展與落地實踐，幫助企業在滿足數據安全和信息安全的同時加速軟件開發創新與價值實現。OpenKruise 帶給云原生應用管理的新變化OpenKruise 帶

61、給云原生應用管理的新變化PaaS 可以通過使用 OpenKruise 提供的擴展功能使應用部署、管理流程更加強大與高效。2、功能視圖如下圖所示，OpenKruise 的能力主要專注于五個領域：應用工作負載（部署、發布）；Sidecar 容器管理；應用分區管理；包括多中心部署、不同資源池、不同機型差異化部署；增強運維能力；應用安全性防護；OpenKruise 絕大部分能力都是基于 CRD 擴展來定義的，可以運行在任意純凈的 Kubernetes集群中。官方文檔：https:/openkruise.io/zh/docs/OpenKruise 帶給云原生應用管理的新變化OpenKruise 帶給云原

62、生應用管理的新變化2、如何看待原生 Workload 的局限性下圖是 OpenKruise 進入 CNCF 時針對 K8s 原生 Workload 的討論。大意是 K8s 官方認為上游原生 Kubernetes 已經不傾向于接受新的工作負載 controller，他們歡迎第三方項目如 OpenKr-uise 加入以拓展 K8s 工作負載能力。3、原地升級（In-Place Update）原地升級是 OpenKruise 擴展應用工作負載所帶來的一大特性。首先看一下鏡像重建升級，以下圖為例，重建升級后舊的 pod-a 被刪除，重建了新的 pod-b，變化包括：name、uid、image、nod

63、eName、podIP。反觀原地升級如下圖所示，改變的只有鏡像，從 v1 升級至 v2。鏡像（重建）升級OpenKruise 帶給云原生應用管理的新變化OpenKruise 帶給云原生應用管理的新變化示例：原地升級自動鏡像預熱Advanced StatefulSet vs.StatefulSet：支持 maxUnavailable 控制并發窗口，提高發布效率;流式窗口擴容;可配置 Ordinal 序號保留（跳過）;原地升級自動鏡像預熱;Advanced DaemonSet vs.DaemonSet：按 node label selector 標簽選擇灰度升級;通過 partition 控制灰度

64、分批;支持 Pod 熱升級，保證升級過程 Daemon 服務不中斷。5、Sidecar 容器獨立定義與管理在很多場景下都會有針對 Sidecar 容器獨立定義和管理的需求，比如在業務中需要 Sidecar 容器采集日志，因此要在工作負載中定義 Sidecar 容器，如果升級 Sidecar 容器則需要升級整個Deployment，就導致在良好運行的業務 pod 需要重建的問題。OpenKruise 提供的 Sidecar 容器獨立管理方案是新定義一個 SidecarSet，如下圖所示，用戶定義一個 logtail SidecarSet，業務部署 Deployment 或 CloneSet 工作

65、負載而無需定義 Sidecar容器，這個 pod 在創建時會被 OpenKruise Webhook 攔截，并將定義好的 logtail 注入到業務pod 中。這樣對于業務人員無需關注 Sidecar 容器，對于維護 logtail 容器的人員也只需要關注SidecarSet CR，而業務 pod 中的 Sidecar 容器則無需費心。如果業務將 SidecarSet 中鏡像版本從 1.0.0 改成 1.1.0，SidecarSet 會將已有 pod 中的 logtail容器從 1.0 原地升級。OpenKruise 帶給云原生應用管理的新變化OpenKruise 帶給云原生應用管理的新變化如

66、下圖所示，workloadspread 通過 targetRef 關聯到原生 Deployment 或者 CloneSet，可以定義多個 subset，這里的 subset 等同于 pod 分組的概念。特性：無需修改 Workload 或 Pod，可直接配合原有 Deployment/CloneSet 使用；多個拓撲或區域維度，按比例打散，或按固定數量分配；支持多區域調度順序選擇，在前一個 subset 數量滿足或資源不足時選擇下一個 subset；通過 deletion-cost 自動設置 Workload 縮容優先級。3、應用場景場景一：兩個資源池，Normal 是固定資源池，Elasti

67、c 是彈性資源池，即其中的業務是具有周期性的，比如白天將 node 開機，晚上停機以節省成本。通過定義 workloadspread 將固定量的 pod 部署到基礎資源池，將彈性 node 部署到彈性資源池。OpenKruise 帶給云原生應用管理的新變化OpenKruise 帶給云原生應用管理的新變化場景四：集群中有不同機型，如下圖示例中的 x86 和 arm，不同機型的算力不同導致 pod 在不同機型中部署的 request limit 就可能不同。四、增強機型運維能力1、容器原地重啟OpenKruise 帶給云原生應用管理的新變化OpenKruise 帶給云原生應用管理的新變化定義好之后

68、，OpenKruise 會將符合條件的節點上的鏡像預拉到本地。鏡像預拉取運用的場景，比如剛部署的節點中的鏡像是空的，之后部署業務都需要一個拉取基礎鏡像的過程，如果先在集群中部署 ImagePullJob 并保持持續預熱，基礎鏡像預熱，之后任何新增節點都可以自動將基礎鏡像預熱，當這個節點提供服務時就可以直接使用，這樣可以大幅度提高應用部署的效率。五、應用安全性防護1、級聯刪除防護面向終態是 Kubernetes 的一個核心能力，但同時也存在一定的風險（見下圖）：CRD 誤刪除導致所有 CR 對象丟失；Newspace 誤刪除導致 Newspace 下所有對象被刪除；Workload 誤刪除導致下

69、面所有 Pod 被刪除。上述情況一旦出現會產生嚴重的后果。OpenKruise 帶給云原生應用管理的新變化OpenKruise 帶給云原生應用管理的新變化驅逐；刪除；應用原地升級；Sidecar 原地升級；容器重啟；當定義 maxUnavailable：25%時，OpenKruise 會盡量保證主動導致 Pod 不可用的操作數量在25%以下。apiVersion:policy.kruise.io/v1alpha1kind:PodUnavailableBudgetspec:selector:#.label selectortargetRef:#.workload referencemaxUnav

70、ailable:25%#minAvailable:15如下圖所示，所有會導致 Pod 不可用的操作在經過 ApiServer 時全部被 OpenKruise Webhook攔截，Webhook 會根據客戶定義的 PUB 結合 Pod 當前所用數量來決定當前操作是否可以執行。OpenKruise 帶給云原生應用管理的新變化開啟邊緣設備的云原生管理能力開啟邊緣設備的云原生管理能力作者：劉武明，VMware 主任工程師一、云原生場景下邊緣設備的管理云中心大多都是 X86 的服務器，但邊緣計算里會遇到不同廠商提供的各種邊緣盒子和設備。所以邊緣計算需要去管理更多設備。這些設備的能力不同，存儲架構也不同可

71、能是 arm 的，可能是 MIPS 的，還有一些很特殊的比如 RSICV。此外還有很多加速器、傳感器等等，除了傳統的溫度傳感器、壓力傳感器，現在還有一些激光雷達、機械控制的手臂等等。開啟邊緣設備的云原生管理能力開啟邊緣設備的云原生管理能力首先解釋一下為什么需要集成 EdgeX。因為 Kubernetes 主要是管理計算資源,不是管理邊緣設備的。另外物聯網開發，協議和應用是非常碎片化和定制化的，如果直接去改變原生的Kubernetes，需要對 Kubernetes 進行很大程度的定制化處理。而如果未來升級的話，會有很多 conflicate merge，也很繁瑣。Edgex 是 Linux 基金

72、會里面一個領先的開源物聯網平臺，它里面已經支撐了大量的物聯網設備和協議，通過集成它，可以減少 openyurt 用戶二次開發的成本，能讓快速支持很多的邊緣設備。開啟邊緣設備的云原生管理能力開啟邊緣設備的云原生管理能力OpenYurt 里面有很多節點池，可以對每個節點池創建不同的 edgex，它們會共享一個服務名稱。節點池的部署是以節點池為單位的，可以在里面定義 edgex 的模塊，根據所需要的設備去定制化。unite depoinment 是 OpenYurt 里的一個原生特性，通過它來部署 edgex 的時候，可以很大程度上減少維護量。我們在考慮集成的時候，也考慮了 edgex 的易用性和擴

73、展性。首先定義了 8 個基礎模塊，用戶只需要指定它的節點池和版本，就可以向對應的節點池里部署 edgex。同時它也允許用戶去定制化地對 edgex 進行部署，比如管理一個 gpl 設備或者藍牙設備，可以根據節點池里面設備的能力去自動部署這些插件。開啟邊緣設備的云原生管理能力開啟邊緣設備的云原生管理能力這里還做了不同設備的區分，分為已管理設備和未管理設備。有些設備并不支持云端控制，只能查詢它的狀態，比如說溫度或攝像頭等等，這些是未管理設備。但是有一些設備我們希望它是可以被云端控制的，就是已管理設備。而且云端的優先級是大于邊緣側的。另外它還是聲明式的設備管理。上圖右邊是一個配置的案例，如果想配置一

74、個燈泡，要先聲明顏色。未來我們要完成 edgex 新版本的支持。另外對于節點池里面有混合架構節點的問題，服務和高可用問題，都會在下一個版本里解決。三、使用 OpenYurt 管理邊緣設備看一下 OpenYurt 的新功能。開啟邊緣設備的云原生管理能力開啟邊緣設備的云原生管理能力device controller 部署下去以后，會去掃描邊緣設備節點，同時以 CR 的形式反映到云端，在云端就可以查詢到這些 CR。后面只需要控制 CR 就可以控制邊緣設備。四、演示接下來看一個實際的演示。這是一個云節點和一個邊緣節點組成的 OpenYurt 集群，邊緣節點是一個樹莓派，通過 GPIO連接一個帶顏色的燈

75、和一個溫度濕度傳感器。開啟邊緣設備的云原生管理能力深入理解 OpenYurt深入理解 OpenYurt作者：張力方，電信天翼云研發工程師一、從云到邊緣的挑戰與應對目前來看，邊緣計算場景下的挑戰還是比較多的。下圖中的兩個挑戰可以凸顯 OpenYurt 的一些特性。第一點是在邊緣計算場景下節點數量會非常多，特別是在一些 IoT 場景，運維的復雜度非常高。如果沒有一個統一的運維入口，分開管理會非常麻煩。同時，如果我們用原生 K8s 做法，按地域把每個內網劃分成一個集群，那就會有相當大的集群量，要對那么多集群進行管理，運維難度也是相當大的。第二點是網絡問題，沒有公網訪問條件的情況下，在原生 K8s 上

76、的 APIServer 沒有辦法訪問到節點 kubelet，exec/logs 命令都無法執行。再者,如果邊緣節點跟云端網絡斷聯，重啟邊緣節點的時候是沒有辦法恢復的，因為它沒辦法從 APIServer 里面拿到啟動它所需的 pod 和其他相關信息。深入理解 OpenYurt深入理解 OpenYurt上圖描述了這樣一個場景：假設我們有廣州、深圳兩個地域的應用。我們通過節點池把它們劃分出來，當我們需要在不同的地域節點上去部署應用的時候，就可以通過 YurtAppSet(原名（UnitedDeployment)去定義這個應用?？梢钥吹?，廣州的節點數量比深圳的少一些，通過YurtAppSet 就可以做

77、到對不同的節點池定義不同的副本數，去適配每個節點池的能力。單化部署有節點池流量閉環的能力，就是把節點池內部的 service 流量管控在單一的節點池之內。比如廣州深圳這兩個節點池，如果網絡上沒有做特殊打通的話，從廣州節點池肯定無法訪問到深圳 service Endpoint 的。深入理解 OpenYurt深入理解 OpenYurt在實際應用場景中，只提供副本數的差異化配置是不夠的，除了副本數以外，其他的字段也可能會有差異。這種情況下，YurtAppSet 提供了一種 patch 的功能，通過 patch 字段，可以修改節點池里的一些定義，這樣就可以在繼承整個部署模板的前提下做一些定制化的改造，

78、提高YurtAPPSet 的實用性。三、YurtHub1、YurtHub 概覽YurtHub 是 OpenYurt 里面非常重要的組件。深入理解 OpenYurt深入理解 OpenYurt除了上述反向代理能力以外，YurtHub 還有兩個比較重要的能力。一個是流量閉環，它用來保證 service 流量不出節點池的范圍，從而保證 service 可以正常訪問。還有一個是 API 地址的改寫能力，主要是為了讓邊緣應用無縫接入 YurtHub。YurtHub 數據緩存的原理是用 Json 文件的方式把響應保存在本地的磁盤上?？匆幌律蠄D右側的目錄，它的默認保存路徑是在 etc 的 cache 目錄下，

79、以組件的維度做了緩存，component/resource/namespace/name 這整一段就是一個 catch key。當組件去訪問 YurtHub，它就會根據 catch key 去拿對應的信息。2、YurtHub 數據緩存能力深入理解 OpenYurt深入理解 OpenYurt3、YurtHub 數據過濾框架YurtHub 的數據過濾框架，主要原理就是在收到 API server 響應后，返回響應前，在 YurtHu-b 中注入一個修改點。深入理解 OpenYurt深入理解 OpenYurt第三點要為 kube-proxy 開啟 EndpointSlices feature gat

80、e；只有開啟了 EndpointSlices feature gate，kube-proxy 才能拿到這個節點上的 endpoint 拓撲信息。如果使用的版本是小于等于 1.18 的，我們要手動開一下，因為它默認是關閉的；如果使用的版本是大于 1.18 的，它是默認支持的。最后要配置 kube-proxy，將 YurtHub 地址作為 APIserver 的地址。如何方便的將 kube-proxy 的 APIServer 地址替換成 YurtHub 呢？這就引出下面一個問題：Yurthub 數據過濾框架的 APIServer 地址改寫。APIServe 集群里面的 pod 可以通過內部的 se

81、rvice 去訪問 APIServer，當 kubelet 在 listwatch service 的時候，我們會看到這個地址是一個 service 地址clusterIP 10.96.0.1。如果這個 service 的后端 endpoint 對應的是一個公網 IP 的話，那它的確是可以訪問的，但訪問的依舊是 APIServer，而不是 YurtHub。深入理解 OpenYurt深入理解 OpenYurt從原來的架構圖來上看，大家可能覺得只有邊緣才會有 YurtHub。實際上后來我們為 YurtHub增加了另外一種工作模式CloudMode。YurtHub 在云端主要的作用是開啟流量閉環，它

82、不需要做緩存工作。所以當 YurtHub 工作在cloud mode，它會關閉緩存能力，請求只透傳，不緩存。并且禁用數據過濾框架的 discardcl-oudservice fliter。三、YurtTunnel1、YurtTunnel 概覽深入理解 OpenYurt深入理解 OpenYurt首先，Agent 啟動的時候，要有一個注冊流程。其次，當 TunnelServer 收到請求的時候，內部會有一個 Interceptor 模塊。因為 ANP server 是上游社區的組件，它要求客戶端要用HTTP Connect 的方式顯式地創建代理。顯然我們不太可能改變原有應用的請求方式，所以就在 T

83、unnelServer 內部增加了 Interceptor 模塊，由他來代替客戶端向 ANP server 去發起connect 請求。server 和 agent 之間是用 gRPC 的方式來通信，比如建立連接，然后響應數據關閉這些功能。2、YurtTunnel 導流模式提到 TunnelServer，有一個很重要的概念導流模式，就是怎么樣把云端訪問到邊緣的流量導入到 tunnel 里面。YurtTunnel 目前有兩種導流方式，第一種就是 DNAT 的模式，它是開箱即用的，開發人員可以直接使用它，不用做任何配置。第二個是 DNS 模式，稍微復雜一點。深入理解 OpenYurt深入理解 Op

84、enYurt上圖描述了隧道不通的情形。在多 master 的架構下，client 通過 loadBalance 去訪問，如果采用的是這種輪巡的方式，訪問到沒有 Tunnel 的節點，運維隧道就沒有辦法正常工作。要解決這個問題，我們推薦使用 DNS 模式。深入理解 OpenYurt深入理解 OpenYurt第三點是要修改 DNS 的配置，要將 yurt-tunnel-nodes ConfigMap 掛載為 Volume。還要修改 CoreDNS 的配置，添加 Host 插件。3、YurtTunnelWhats next最后談一下對 YurtTunnel 的期待和展望。首先 DNS 的配置的確比較

85、復雜，不夠便捷。其次 YurtTunnel 不具備邊緣通信能力，也不支持PodeIP 和 ServiceIP 的訪問，它相對于原生的 k8s 體驗還是有一定的差距的。這些都將成為接下來行業發展的方向和目標。深信服智能邊緣計算平臺與 OpenYurt 落地方案探索與實踐深信服智能邊緣計算平臺與 OpenYurt 落地方案探索與實踐萬物互聯的時代，產生了很多智能家居，它們除了簡單的接入網關之外，還有很多數據需要處理，這部分也是邊緣側的應用場景。以上都是是我們遇到的機遇，那挑戰是什么？對于一些傳統行業而言，它們的云計算可能是很小的，比如市面上有很多私有云場景、政府專有云場景，它們不足以做到像大廠商那

86、些云計算一樣無限的擴容來做很多計算處理。目前的市場環境下，云和端的環境非常不理想，主要原因有以下幾個方面。第一，因為端側數據采集的設備普及率非常低，導致很多有用的數據沒有辦法采集上來供云端的大腦進行分析操作。第二，采集數據的維度特別低，功能單一，會漏掉一部分有價值的數據。第三，前端設備的維保非常難。以攝像頭為例，我們沒辦法對每一個攝像頭進行嚴密的監控和維護。出事故以后去追溯問題，可能已經過了好幾天了。在這種情況下，這部分數據就會丟失。第四，行業的數據標準不一樣。設備一直在更新迭代，數據的標準也在不斷更新。市面上有很多不同類型的設備，把這些設備的數據統一集中到云端去做處理，云端的能力也跟不上。深

87、信服智能邊緣計算平臺與 OpenYurt 落地方案探索與實踐深信服智能邊緣計算平臺與 OpenYurt 落地方案探索與實踐首先，我們采取的是云端一體化架構。在邊端給用戶部署一個云邊一體機，也可以理解成是一個小型的服務器，它可以和終端設備放在同一個地方。于是他們之間會整體形成一個獨立的小網絡。這樣邊端的設備就可以把數據發給云邊一體機，數據就可以得到盡快的處理和響應。其次，即使在云邊斷網的情況下，端側可以和邊側一體機進行網絡訪問，我們可以內置一些 AI算法進去，讓他在特定場合下的指令也可以得到響應。最后就是關于數據的處理。云側邊側的網絡帶寬是有限的，我們可以先將數據收集在一體機里，先做一輪處理，把

88、一些有效的數據處理出來。再將這些數據通過的 SD-WAN 網絡匯報到中心側進行處理，這樣一方面減輕了帶寬的壓力，另一方面提高了中心側的數據處理能力。云邊斷網情況下的邊緣自治能力其實是根據我們和社區的 OpenYurt 進行結合，將云邊運維通道、邊緣端的自治以及單元化部署都有機結合到了一起，形成了這樣一個邊緣計算的架構圖。云邊一體機的最終目標是為智能化改造打通最后一公里。它里面提供了很多功能，包括控制面板，AI 算法的平臺，以及監控日志的收集，當然還有最重要的安全網絡管理，以及一些視頻的解碼編碼。同時這個盒子也是支持硬件適配的，比如 arm架構、x86 架構，還包括不同的網絡 GPU 的配合、底

89、層數據操作系統適配。深信服智能邊緣計算平臺與 OpenYurt 落地方案探索與實踐深信服智能邊緣計算平臺與 OpenYurt 落地方案探索與實踐說了這么多關于真實業務落地場景，后面將會結合整個平臺的架構來講解我們的改造思路。KubeManager（KM）架構是我們公司自研的一個產品，它是一個容器管理平臺，底層是由多個 k8s 集群管理構建起來的，集成了多個應用商店和軟件，還有一些數據的采集和監控、給用戶的可視化展示。它主要分為兩個大的模塊，上圖左下方是管理集群，前文提到的一系列內容都是在管理集群里去承接的。用戶集群可以通過接入層來進行數據接入，然后將 API 的數據發送到 API 業務層，再把

90、這些數據存儲到原生 k8s 的 etcd 里面去。我們做改造的部分主要是針對用戶集群這一塊，跟 OpenYurt 做結合。在改造落地的過程中也出現了很多問題。深信服智能邊緣計算平臺與 OpenYurt 落地方案探索與實踐深信服智能邊緣計算平臺與 OpenYurt 落地方案探索與實踐改造之后，用戶集群架構就從上圖左邊這切換到了右邊的狀態。這里面的改造主要有以下幾點：第一，對 YurtControlManager 組件做了改動，以前它是個 deployment，它的副本數是 1?，F在把它改成了 DaemonSet，會隨著 master 數量的變化自動擴縮容，這是一個。第二，因為整體流量是通過 Ng

91、inx 找不同的 APS server 做代理，所以 YurtHub 其實不是直接訪問 APIserver，而是通過 Nginx。但它現在這樣也可以達到邊緣集群和 OpenYurt 的結合之后想要的效果比如流量過濾和邊緣自治。四、行業未來展望以及社區發展期許最后說一下關于整個行業的發展和未來的期望。從上圖可以看到，邊緣設備的成長是一個不斷累積的過程。整個行業的發展對邊緣設備會有非常多的需求，這么大的需求會帶動整個行業的發展，行業的發展也離不開邊緣社區，包括OpenYurt 社區的貢獻。希望每一個用戶在使用 OpenYurt 的時候可以更加邊緣化、安全化和智能化。從中心走向邊緣深度解析云原生邊緣

92、計算落地痛點從中心走向邊緣深度解析云原生邊緣計算落地痛點儲、應用核心能力的開放平臺，就近提供邊緣智能服務，滿足行業數字化在敏捷連接、實時業務、數據優化、應用智能、安全與隱私保護等方面的關鍵需求”。從 CT 電信領域視角，邊緣計算最初也被稱為移動邊緣計算（MEC）。歐洲電信標準協會（ETSI）對 MEC 的定義：“移動邊緣計算在移動網絡的邊緣、無線接入網（RAN）的內部以及移動用戶的近處提供了一個 IT 服務環境以及云計算能力”。邊緣計算的定義各有側重，但核心思想基本一致邊緣計算是基于云計算核心技術，構建在邊緣基礎設施之上的新型分布式計算形式，在邊緣端靠近最終用戶提供計算能力，是一種靠近數據源的

93、現場云計算。中心云計算憑借其強大的數據中心，為業務應用提供大規模池化，彈性擴展的計算、存儲、網絡等基礎設施服務，更適用于非實時、長周期數據、業務決策場景；邊緣計算則聚焦在實時性、短周期數據、本地決策等業務場景，比如當下熱門的音視頻直播、IoT、產業互聯網、虛擬現實甚至元宇宙等，將工作負載下沉至離終端設備或者靠近最終用戶的地方，以此實現更低的網絡延遲，提升用戶的使用體驗。2、“章魚式”邊緣計算邊緣是相對中心式計算的邊緣分散式計算。邊緣計算的核心目標是快速決策，將中心云的計算能力拓展至“最后一公里”。因此它不能獨立于中心云，而是在云-邊-端的整體架構之下，有中心式管控決策，也有分散式邊緣自主決策，

94、即章魚式邊緣計算。從中心走向邊緣深度解析云原生邊緣計算落地痛點從中心走向邊緣深度解析云原生邊緣計算落地痛點邊緣計算生態參與者眾多，云廠商、設備廠商、運營商三大關鍵服務商方以及一些新型 AI 服務商等，都是從各自現有優勢延伸，拓展更多客戶及市場空間。設備商借助物聯網逐漸構建單一功能的專業云；云廠商從中心化的公有云開始下沉，走向分布式區域云，區域云之間通過云聯網打通，形成一個覆蓋更大的云。運營商在互聯網時代被公有云及繁榮的移動應用完全屏蔽只能充當管道，但在邊緣計算時代，業務及網絡定義邊緣計算，運營商重新回歸焦點，不可替代。4、邊緣計算的類型1）網絡定義的邊緣計算：通過優化終端與云中心網絡路徑，將中

95、心云能力逐漸下沉至靠近終端，實現業務就近接入訪問。從中心到邊緣依次分為區域云/中心云，邊緣云/邊緣計算，邊緣計算/本地計算三大類型：區域云/中心云：將中心云計算的服務在骨干網拓展延伸，將中心化云能力拓展至區域，實現區域全覆蓋，解決在骨干網上耗時，將網絡延遲優化至 30ms 左右，但邏輯上仍是中心云服務。邊緣云/邊緣計算：將中心云計算的服務沿著運營商的網絡節點延伸，構建中小規模云服務或類云服務能力，將網絡延遲優化至 15ms 左右，比如多接入邊緣計算（MEC）、CDN。邊緣計算/本地計算：主要是接近終端的現場設備及服務能力，將終端部分邏輯剝離出來，實現邊緣自主的智能服務，由云端控制邊緣的資源調度

96、、應用管理與業務編排等能力，將網絡延遲優化至 5ms 左右，比如多功能一體機、智能路由器等。從中心走向邊緣深度解析云原生邊緣計算落地痛點從中心走向邊緣深度解析云原生邊緣計算落地痛點碼頭，礦山等）領域，相比消費者領域，相信會帶來更大變革與價值。2）業務定義的邊緣計算：除了面向消費者的互聯網邊緣場景，邊緣計算更多的是面向實體產業及智慧化社會衍生的場景。對于實體產業場景來說，由于歷史原因，在邊緣及現場存在大量異構的基礎設施資源；通過業務需求驅動邊緣計算平臺的建設，不僅要整合利用現有基礎設施資源，還要將中心云計算技術及能力下沉至邊緣及現場，實現大量存量業務運營管控上云，海量數據統一入湖，以此支持整個企

97、業的數字化轉型。對于智慧化社會衍生場景來說，越是新型的業務，對網絡時延敏感越高，數據量越大，結構化數據逐漸轉化成非結構化數據，需要人工智能，神經網絡等高等智能化技術支持。當前對網絡時延敏感的新型業務場景，都是通過云端總控管理，設備現場實時計算這種分布式架構策略，以此減弱對網絡的強依賴。面向業務將邊緣計算分為智能設備/專業云及產業邊緣/行業云兩種類型：智能設備/專業云：基于云計算能力之上，圍繞智能設備提供整體化，有競爭力的解決方案，包含智能設備、云端的服務以及端到云之間的邊緣側服務，比如視頻監控云、G7 貨運物聯等；從中心走向邊緣深度解析云原生邊緣計算落地痛點從中心走向邊緣深度解析云原生邊緣計算

98、落地痛點總的來說，邊緣計算范圍大，場景泛，目前整個行業缺少經典的案例及標準。因此推動邊緣計算落地，一定是面向真實的業務場景及需求整體規劃，面向價值逐步建設。二、Kubernetes 從中心走向邊緣Kubernetes 遵循以應用為中心的技術架構與思想，以一套技術體系支持任意負載，運行于任意基礎設施之上；向下屏蔽基礎設施差異，實現底層基礎資源統一調度及編排；向上通過容器鏡像標準化應用，實現應用負載自動化部署；向外突破中心云計算的邊界，將云計算能力無縫拓展至邊緣及現場，快速構建云邊一體基礎設施。將云原生技術從中心拓展到邊緣，不僅實現了云邊基礎設施技術架構大一統，業務也實現了云邊自由編排部署。相對于

99、 Kubernetes 在中心云的革命性創新，在邊緣場景雖優勢明顯，但缺點也很致命，因為邊緣側存在資源有限、網絡受限不穩定等特殊情況，需要根據不同業務場景，選擇不同 Kubernetes 邊緣方案。1、Kubernetes 架構及邊緣化的挑戰Kubernetes 是典型的分布式架構，Master 控制節點是集群“大腦”，負責管理節點，調度Pod 以及控制集群運行狀態。Node 工作節點，負責運行容器（Container），監控/上報運行狀態。邊緣計算場景存在以下比較明顯的挑戰：從中心走向邊緣深度解析云原生邊緣計算落地痛點從中心走向邊緣深度解析云原生邊緣計算落地痛點邊緣節點 Remote Nod

100、e：基于 Kubernetes 二次開發增強擴展，將 Kubernetes 解耦適配成云邊分布式架構的場景，中心化部署 Master 管理節點，分散式部署 Worker 管理節點。此外，一致性是邊緣計算的痛點，在邊緣增加一個 Cache 即可實現斷網特殊情況的邊緣自治，同時可以保證正常網絡情況的數據一致；還有就是 Kubelet 比較重的問題，隨著 Kubernetes放棄 Docker 已經開始精簡；同時硬件更新迭代較快，相比少量硬件成本，保持 Kubernetes 原生及通用性為大。其實更希望 Kubernetes 社區本身提供適配邊緣化方案，同時考慮為 Kubelet增加緩存機制。3、K

101、ubernetes 邊緣容器快速發展Kubernetes 已成為容器編排和調度的事實標準，針對邊緣計算場景，目前國內各個公有云廠商都開源了各自基于 Kubernetes 的邊緣計算云原生項目，比如阿里云向 CNCF 貢獻的OpenYurt，采用邊緣節點 Remote Node 方案,是業界首個開源的非侵入式邊緣計算云原生平臺，秉承“Extending your native Kubernetes to Edge”的非侵入式設計理念，擁有可實現邊緣計算全場景覆蓋的能力。華為、騰訊、百度等，也都開源了自己的邊緣容器平臺。邊緣容器的快速發展帶動了領域的創新，但一定程度上也導致構建邊緣計算平臺時難以抉

102、擇。從技術架構來看，幾個邊緣容器產品總的架構思路主要是將 Kubernetes 解耦成適合云邊、弱網絡及資源稀缺的邊緣計算場景，本質上無太大差異；從產品功能來看也是如此，基本上都涵蓋云邊協同、邊緣自治、單元化部署功能等。4、如何構建云邊一體化云原生平臺從中心走向邊緣深度解析云原生邊緣計算落地痛點從中心走向邊緣深度解析云原生邊緣計算落地痛點三、OpenYurt：智能邊緣計算平臺開源實踐OpenYurt 以上游開源項目 Kubernetes 為基礎，針對邊緣場景適配的發行版。是業界首個依托云原生技術體系、“零”侵入實現的智能邊緣計算平臺。具備全方位的“云、邊、端一體化”能力，能夠快速實現海量邊緣計

103、算業務和異構算力的高效交付、運維及管理。1、設計原則OpenYurt 采用當前業界主流的“中心管控、邊緣運行”的云邊分布式協同技術架構，始終貫徹“Extending your native Kubernetes to Edge”理念，同時遵守以下設計原則：“云邊一體化”原則：保證與中心云一致的用戶體驗及產品能力的基礎上，通過云邊管控通道將云原生能力下沉至邊緣，實現海量的智能邊緣節點及業務應用，基礎架構提升至業界領的云原生架構的重大突破?！傲闱秩搿痹瓌t：確保面向用戶開放的 API 與原生 Kubernetes 完全一致。通過節點網絡流量代理方式（proxy node network traffi

104、c），對 Worker 工作節點應用生命周期管理新增一層封裝抽象，實現分散式工作節點資源及應用統一管理及調度。同時遵循“UpStream First”開源法則；從中心走向邊緣深度解析云原生邊緣計算落地痛點從中心走向邊緣深度解析云原生邊緣計算落地痛點3）邊緣單元化負載：在邊緣計算場景，面向業務一般都是“集中式管控，分散式運行”這種云邊協同分布式架構；對于管理端，需要將相同的業務同時部署到不同地域節點；對于邊緣端，Worker 工作節是一般是分散在廣域空間，并且具有較強的地域性，跨地域的節點之間網絡不互通、資源不共享、資源異構等明顯的隔離屬性。適配增強 Kubernetes 能力，基于資源，應用及

105、流量三層實現對邊緣負載進行單元化管理調度。通過 OpenYurt 開源社區引入更多的參與方共建，聯合研發方式提供更多的可選的專業功能，OpenYurt 特性正在逐步完善，并擴大覆蓋能力：1）邊緣設備管理：在邊緣計算場景，端側設備才是平臺真正的服務對象；基于云原生理念，抽象非侵入、可擴展的設備管理標準模型，無縫融合 Kubernetes 工作負載模型與 IoT 設備管理模型，實現平臺賦能業務的最后一公里。目前，通過標準模型完成 EdgeX Foundry 開源項目的集成，極大的提升了邊緣設備的管理效率。2）本地資源管理：在邊緣計算場景，將邊緣節點上已有的塊設備或者持久化內存設備，初始化成云原生便

106、捷使用的容器存儲，支持兩種本地存儲設備：（一）基于塊設備或者是持久化內存設備創建的 LVM；（二）基于塊設備或者是持久化內存設備創建的 QuotaPath3、OpenYurt 設計架構及原理1）設計架構從中心走向邊緣深度解析云原生邊緣計算落地痛點從中心走向邊緣深度解析云原生邊緣計算落地痛點OpenYurt 踐行云原生架構理念，面向邊緣計算場景實現云邊協同分布式架構及中心管控邊緣運行的能力：針對邊緣節點自治能力，一方面，通過新增 YurtHub 組件實現邊緣向中心管控請求（Edge ToCloud Request）代理，并緩存機制將最新的元數據持久化在邊緣節點；另一方面新增YurtControl

107、lerManager 組件接管原生 Kubernetes 調度，實現邊緣自治節點狀態異常不觸發重新調度；針對 Kubernetes 能力完整及生態兼容，通過新增 YurtTunnel 組件，構建云邊（Cloud ToEdge Request）反向通道，保證 Kubectl，Promethus 等中心運維管控產品一致能力及用戶體驗；同時將中心其他能力下沉至邊緣，包含各不同的工作負載及 Ingress 路由等。針對邊緣單元化管理能力，通過新增 YurtAppManager 組件，同時搭配 NodePool,YurtAppSet（原 UnitedDeployment），YurtAppDaemon，S

108、erviceTopology 等實現邊緣資源，工作負載及流量三層單元化管理；針對賦能邊緣實際業務平臺能力，通過新增 NodeResourceManager 實現邊緣存儲便捷使用，通過引入 YurtEdgeXManager/YurtDeviceController 實現通過云原生模式管理邊緣設備。4、核心組件OpenYurt 所有新增功能及組件，均是通過 Addon 與 Controller 方式來實現其核心必選與可選組件如下：從中心走向邊緣深度解析云原生邊緣計算落地痛點從中心走向邊緣深度解析云原生邊緣計算落地痛點5、當前挑戰1）云邊網絡在邊緣計算場景中，被提到最多的就是云邊網絡差且不穩定；其實

109、國內基礎網絡在 2015 年開始全面升級；尤其是在“雪亮工程”全面完成之后，基礎網絡有一個很大的提升。上圖摘自第48 次中國互聯網絡發展狀況報告，固網 100Mbps 接入占比已達 91.5%；無線網絡接入已經都是 4G，5G 的優質網絡。真的挑戰在云邊網絡組網，對于使用公有云的場景：公有云屏蔽數據中心網絡，只提供了互聯網出口帶寬，通過互聯網打通云邊，通常只需要解決數據安全傳輸即可，接入不復雜。對于私有自建的 IDC 場景：打通云邊網絡并不容易，主要是運營商網絡沒有完全產品化，同時私有IDC 層層防火墻等其他復雜產品，需要專業的網絡人員才能完成實施工作。2）list-watch 機制與云邊流量

110、從中心走向邊緣深度解析云原生邊緣計算落地痛點從中心走向邊緣深度解析云原生邊緣計算落地痛點源非常充足，足以將整個云原生體系下沉。針對智能設備邊緣，資源相對比較稀缺，但一般都會通過一個智能邊緣盒子，一端連接設備，一端連接中心管控服務，從上圖的 AI 邊緣盒子來看，整體配置提升速度較快，長期來看，邊緣的算力快速增強以此來滿足更復雜更智能化的場景需求。4）Kubelet 比較重，運行占用資源多對于 Kubelet 比較重，運行占用資源多的問題，需要深入了解節點資源分配及使用情況，通常節點的資源自下而上分為四層：運行操作系統和系統守護進程（如 SSH、systemd 等）所需的資源。運行 Kuberne

111、tes 代理所需的資源，如 Kubelet、容器運行時、節點問題檢測器等。Pod 可用的資源。保留到驅逐閾值的資源。從中心走向邊緣深度解析云原生邊緣計算落地痛點從中心走向邊緣深度解析云原生邊緣計算落地痛點基于中心云的分布式業務應用架構，與云邊分布式協同業務應用架構本質上有很大差別。在中心云更多的是基于 DDD 業務領域，將復雜的業務系統拆分成一個個相對獨立的服務，整體構建一個松耦合的分布式應用；但在云邊分布式場景下，更多強調的是集中式管控運營，分散式運作支撐；將管理運營系統集中在云中心，實現中心式管控；將支撐業務實時運作的應用分散至邊緣，實現低延遲快速響應。從業務應用來看，財務/經營，計劃/管

112、理兩層屬于管控運營類的應用，就是需要通過中心云統一匯聚，實現集中化強管控；對延遲不敏感，對安全，大數據分析能力等要求較高；控制，傳感/執行，生產過程三層屬于運作支撐類應用，也可以優先考慮中心云；如果業務場景對延遲敏感，才考慮通過邊緣計算能力，實現分散式低時延響應；從請求響應來看，對時延不敏感（50ms 以上）都有限考慮部署在中心云計算及云化的邊緣產品（CDN）實現；對延遲敏感（小于 10ms），運營商骨干網完全無法支持的，考慮建設邊緣計算平臺，同時業務面臨不小的投入及人員；以實體物流領域為例，經典的 OTW 系統（OMS 訂單管理系統，WMS 倉庫管理系統，TMS 運輸管理系統）；其中 OT

113、就屬于典型的管理運營系統，所以建議部署在中心云，通過中心云數據匯聚，實現拼單拆單，多式聯運等跨區域業務；W 是倉庫管理系統，管理四面墻的任務，屬于運作支撐應用，并且倉庫一般都有一些自動化設備，就可以考慮將 W 部署在邊緣。五、總結邊緣計算平臺的建設，以 Kubernetes 為核心的云原生技術體系，無疑是當前最佳的選擇與建設路徑；但是云原生體系龐大，組件復雜，將體系下沉至邊緣會面臨很大的挑戰與困難，同時充滿巨大的機遇及想象空間。業務應用想要真正踐行邊緣的云原生體系，需要從理念、系統設計、架構設計等多方面來共同實現，才能充分發揮邊緣的優勢及價值。OpenKruise 提升云原生應用自動化新高度O

114、penKruise 提升云原生應用自動化新高度基于 OpenKruise 部署 K8S 的邏輯架構圖3、OpenKruise 能做什么？a、OpenKruise 專注領域包括：通用工作負載（部署、發布）；Sidecar 容器管理；應用分區管理；增強運維能力；可用性防護；OpenKruise 提升云原生應用自動化新高度OpenKruise 提升云原生應用自動化新高度OpenKruise 是阿里“雙十一”全鏈路部署基座。其中：CloneSet 部署了集團大部分無狀態應用；Advanced StatefulSet 是針對原生 StatefulSet 的擴展，部署有狀態的中間件應用；SidecarSe

115、t 是 Sidecar 管理的資源，針對 Mesh 容器、運維容器、安全容器的管理；Advanced DaemonSet 針對基礎網絡組件和基礎存儲組件；Operation Capabilities 針對運維能力。二、OpenKruise 為云原生帶來高效的部署能力1、核心能力 1-原地升級a、Kubernetes-Pod 維度的不可變基礎設施如下圖所示，在 K8s 中 Pod 重建需要刪除舊的 Pod 然后調度再拉起新的 Pod，流程復雜且耗時長，如果在類似雙十一的場景下就無法實現。b、容器維度的管控能力-原地升級下圖中 CloneSet 是針對 Deployment 的工作負載，省去中間的

116、 Replicas 直接連 Pod，如果Pod 要升級，CloneSet 先停止 nginx v1，拉起 v2 版本鏡像，這個過程不涉及 Pod 重建，Pod的網絡、存儲都不變，即為原地升級。OpenKruise 提升云原生應用自動化新高度OpenKruise 提升云原生應用自動化新高度a、優勢：將輔助能力同業務容器解耦，實現獨立發布和能力重用；b、缺點：Sidecar 升級將導致業務 Pod 重建；業務 Pod 配置耦合（運維、安全、代理）多種 sidecar，增加配置的復雜性，以及 sidecar更新難度。c、SidecarSet 管理 Sidecar 容器的利器針對上述缺點開發的 Sid

117、ecarSet 工作負載，如下圖：OpenKruise 提升云原生應用自動化新高度OpenKruise 提升云原生應用自動化新高度思考：鏡像拉取占用了大量時間，能否有優化的空間？b、OpenKruise 提供“規?；R像預熱的能力”OpenKruise 提供 ImagePullJob 的 CRD 解決上述問題。組合拳：鏡像預熱+擴容1）原始 Pod 擴容流程/耗時：2）用 ImagePullJob 長期預熱 app 基礎鏡像和 Sidecar 鏡像：3）基礎預熱后的 Pod 擴容/耗時：OpenKruise 提升云原生應用自動化新高度OpenKruise 提升云原生應用自動化新高度面向終態是

118、Kubernetes 的一個核心能力，但同時也存在一定的風險（見下圖）：CRD 誤刪除導致所有 CR 對象丟失；Namespace 誤刪除導致 Namespac 下所有對象被刪除；Workload 誤刪除導致 Workload 下面所有的 Pod 被刪除。因此，OpenKruise 提供級聯刪除防護能力，將定義的資源增加一個 label，當發生刪除時，OpenKruise 會對加 label 的資源進行再校驗。metadata:labels:policy.kruise.io/delete-protection:CascadingCascading：這個對象如果還有可用的下屬資源，則禁止被刪除；

119、Always：這個對象禁止被刪除，除非上述 label 被去掉。支持防護的資源類型：NamespaceCustomResourceDefinition（CRD）OpenKruise 提升云原生應用自動化新高度OpenKruise 提升云原生應用自動化新高度5、核心能力 5-分區拓撲和彈性管理a、云時代的“部署挑戰”在 K8s 中部署都是均勻的，不會有優先等級。OpenKruise 提供彈性調度能力，在業務高峰期時將 Pod 部署在 ECI 上按量付費，高峰期過后就可以將 ECI 中的 Pod 縮容。OpenKruise 提升云原生應用自動化新高度OpenKruise 提升云原生應用自動化新高度

120、WorkloadSpread 架構d、“極致彈性調度”最佳實踐在上圖代碼中：subset-a 和 subset-b，分別對應右圖中的自由資源池和彈性資源池；maxRelicas:300，是自由資源池最多 300 個 Pod；OpenKruise 提升云原生應用自動化新高度 2021.12（v1.0.0）規劃：2022 年 CNCF Sandbox-Incubation雙周周會（每周四晚 19 點）業界用戶：國內：阿里巴巴、螞蟻、攜程、蘇寧、OPPO、小米、斗魚 TV、有贊、Boss 直聘、申通、小紅書等 25+登記企業用戶；國外：Lyft、Bringg、Arkane Systems、Spect

121、ro Cloud 等 5+登記企業用戶。感興趣的朋友可以加入社區釘釘群了解更多內容，一起交流分享。189OpenKruise 提升云原生應用自動化新高度2、Roadmap未來會針對以下領域開展工作：針對有狀態的服務，比如固定 IP 或 PV；資源分發；分批發布、流量發布、灰度發布；歡迎對以上領域感興趣的朋友加入社區一起分享?；旌显骗h境云原生應用交付和管理平臺混合云環境云原生應用交付和管理平臺1、CI：如圖示上方是一個典型的 CI 流程，可分為三個部分：鏡像構建（Build）、測試(Test)和應用打包(Artifacts)。這個流水線過程的目的是輸入源碼到輸出云原生制品。在這個過程中針對代碼處

122、理和制品處理的工具鏈已經很豐富，比如 Jenkins 的插件體系。目前也有比較多的企業在 CI 流水線的最后一步直接進行應用的部署，它的目標可能有主機、容器環境、K8s 環境、甚至更大規模的多集群 K8s 環境等，把服務進行發布上線的過程就是接下來我們要聊的 CD 環節。2、CD：圖示下方是將 CD 環節拆開來看，將制品進行部署的過程包括環境和參數配置、資源組裝、流程編排、部署到多環境等，在開發環境、預發環境、生產環境、私有環境或各個邊緣環境中去部署和發布。發布過程需要可觀測，可追蹤、可回退，發布的后續動作還會包括監控、運維等。我們可以發現，CD 環節需要面對的復雜性不亞于 CI 環節，相反，

123、它還是影響業務穩定的最重要環節。3、CIOps:圍繞 CI 工具的持續交付kubectl applyhelm upgrade其它模板方案然后 apply.以上是圍繞 CI 做發布的常見形式，比較籠統的將服務配置下發的目標集群上。二、CIOps：做 CI 很好，CD 問題很多1、問題一：“基礎設施的復雜性”暴露給開發者混合云環境云原生應用交付和管理平臺混合云環境云原生應用交付和管理平臺目前中大型公司已經開始了上云、容器化的工作，整個云的形態已經朝著分布式的形式發展，但由于發布環境各異，需求各異，導致編排極其復雜。a、場景現狀：同一個應用，在不同環境下部署的組件依賴差異巨大；數據庫、負載均衡、K8

124、s,在不同云上也存在諸多差異；b、開發現狀：開發者心智負擔重，單一系統缺乏統一交付能力；需要補充大量人工操作，缺乏自動化；c、同一個應用，在不同場景下的運維能力要求差異巨大開發測試環境：需要進行熱加載、調試、查看開發日志以及實時運行的情況等；預發聯調環境：需要考慮服務之間的調用，測試時需要觀看響應指標，綁定資源，錯誤定位，進行攻防演練等；生產環境：包括可觀測性、流量、云服務等。3、問題三：以“腳本”為中心的系統缺乏自動化混合云環境云原生應用交付和管理平臺混合云環境云原生應用交付和管理平臺CI/CD 的安全域無法隔離，各種權限混合使用；CI 系統的權限難以控制，多集群、多租戶。三、云原生應用持續

125、交付，用戶的核心訴求是什么？1、用戶對云原生應用持續交付的核心訴求CD 持續發布過程中的訴求：統一抽象：K8s 持續演進幫助我們把底層各種各樣的基礎設施完全抽象化，抽象化過程需要不同企業的相應類似描述文件，描述文件相同的是描述、日志等，不同的是服務名稱、鏡像、服務端口等；自動化編排：屏蔽編排的復雜性，提供自動化能力；部署能力：安全、穩定、大規模地把此資源分發到不同環境和集群里。目標是開發者在制品倉庫輸入變量，后面的過程可以完全自動化的進行，將復雜巨大的程序都屏蔽在底層，如果有問題可以由專業的工程師做相應的維護和調試。2、如何實現K8s 帶來的啟示：聲明式是用戶側抽象的最佳表達方式，將復雜管理邏

126、輯下沉到 K8s 中，對用戶僅暴露終態/意圖的輸入?；旌显骗h境云原生應用交付和管理平臺混合云環境云原生應用交付和管理平臺KubeVela 為廣大開發者提供了一個面向現代云原生環境的應用交付/持續交付系統：以應用為中心的開發者體驗；面向終態的聲明式交付工作流；面向混合環境，基礎設施無關；laC/可編程，高度可擴展；CNCF 項目地址：https:/ K8s 控制平面，面向混合環境統一交付混合云環境云原生應用交付和管理平臺混合云環境云原生應用交付和管理平臺面向終態的統一云資源管理；KubeVela 集成了 Terraform 的云資源描述能力，繼而集成了 Terraform 的云資源支持生態，通過

127、 Application 描述用戶可以同時交付普通服務和云服務組成完整交付應用。云邊一體的統一交付模式；集成邊緣應用的描述規范，邊緣環境以 KubeAPI 規范接入到管控平面，實現邊緣應用的維護和分發。面向不同場景需求用戶分層集成；KubeVela 架構上分為核心模塊和上層終端產品 VelaUX，對于大型企業的 PaaS 平臺開發者，可直接集成 KubeVela 核心模塊，獲取應用引擎能力。對于中小型終端客戶，可借助終端產品生態快速落地。同時 VelaUX 也具備了必要的擴展能力，通過編輯配置即可適應不同企業的應用管理訴求。3、Application Demo 示例：1）待交付組件比如容器鏡像

128、、Helm chart、云資源 Terraform 模塊等.定義任意可交付制品!混合云環境云原生應用交付和管理平臺混合云環境云原生應用交付和管理平臺5、生態項目對比純粹的 GitOps 系統：本質上是在運行時集群中的 agent,無法跨環境交付；經典應用 CI/CD 交付平臺：本質上是面向過程的執行，不具備聲明式系統的自動、冪等、收斂、確定等特性；安全性問題的本質：基于過程式的 Push vs 基于統一模型的 Pull；各類 Kubernetes 發行版：定位上就嚴格遵守 K8s 的 API,不提供 K8s 之.上的應用層能力；經典 PaaS/各類“云原生應用管理平臺：本質上是不具備開放性的封

129、閉抽象只能處理容器交付，不能面向云進行統一交付不可擴展(需要重寫代碼和重新部署)，不能跟隨用戶一起成長和演進被集成性差:用戶需要做出唯-性選擇，不能夠跟其他平臺共存6、OAM：現代微服務與應用交付模型要屏蔽繁雜的底層，一個重要的問題就是標準化。將應用通過標準化的描述，讓業務和基礎測試有完美的銜接，KubeVela 體系完全基于 OAM 的生態去做，歡迎各大廠商共建，普惠云的開發者。7、實踐案例-Serverless 應用引擎（SAE）混合云環境云原生應用交付和管理平臺集群鏡像重塑分布式應用交付集群鏡像重塑分布式應用交付作者：方海濤(中弈)，sealer 項目發起人，阿里云技術專家，擁有七年以上

130、云原生從業經驗，sealos 作者，數千家企業在生產環境中使用該項目。議題簡介：集群鏡像把整個集群看成一臺服務器，把 K8s 看成云操作系統，實現整個集群的鏡像化打包和交付，為企業級軟件提供一種“開箱即用”的應用封裝技術。以行業 ISV 為例，集群鏡像幫助企業解決了分布式軟件的部署一致性難題、降低了交付出錯率，最終指數級降低分布式軟件的交付成本。受 docker 等容器技術的啟發，集群鏡像將單機應用封裝技術，上升到分布式集群維度，最終實現分布式軟件的高效交付（build,share,run)。一、背景介紹從應用視角看云的發展歷程，就是一個不斷屏蔽底層細節的過程。最早是物理機；openstack

131、：做了資源虛擬化，但并未對應用管理做思考，注重了利用率；Docker：主要考慮針對單個應用的打包；kubernetes：管理整個集群，向下整個資源做抽象，向上整個分布式應用做管理，如何部署、升級、配置等；集群鏡像重塑分布式應用交付集群鏡像重塑分布式應用交付要的鏡像甚至二進制如何打包。更不會幫你處理交付時一些常規的操作如修改主機名，時間同步等。三、Sealer-集群鏡像介紹定義：如同 Docker 或者虛擬機鏡像一樣，把整個集群當成一臺機器把 kubernetes 當成操作系統，整個集群所有依賴整體打包的技術稱之為集群鏡像。1、集群鏡像介紹如上對比圖所示：驅動層：單機上有計算、存儲、網絡驅動，集

132、群里是 K8s 容器運行 CRI、CNI、CSI 時的實現；操作系統層：單機有 ubuntu centos，集群里是 Kubernetes；容器層：單機是 Docker 鏡像，集群里運行著 K8s 的集群；鏡像層：單機是 Docker 鏡像，而集群里是缺失的環節。集群鏡像重塑分布式應用交付集群鏡像重塑分布式應用交付定義一個類似于 Docker 文件的 kubefile（如上圖左邊所示），進行創建 Sealer 集群鏡像，包含了內嵌的 kubernetes 和它的所有依賴，到客戶環境中，只需要提供好機器，裝好操作系統，連接好網絡就可以去運行 Sealer。4、集群分享與運行集群鏡像重塑分布式應用

133、交付集群鏡像重塑分布式應用交付在做高可用的時候不用再去依賴過重的組件；如果啟用 Nginx 做反向代理，流量會走 Nginx 的進程，當進程出現問題會影響整體的可用性，而 ipvs 負載只要內核在運行，上層管控組件出現問題時不會影響整個集群的高可用。7、容器鏡像緩存機制集群鏡像重塑分布式應用交付集群鏡像重塑分布式應用交付在交付 Redis 時，賬戶密碼等有變更，同樣可以在 Clusterfile 中去定義一個 Config，可以覆蓋掉鏡像里的任何的文件，不管是 Helm 的 values，還是 etcd 里的文件或者修改自定義的文件。Sealer 的配置能力非常靈活，而且不會限制到底是使用哪種

134、編排工具。四、總結與規劃1、客戶列表很多客戶使用 sealer 極大的提升了交付穩定性和交付效率，把一周左右的交付周期縮短到了小時級別。2、Roadmap 未來規劃V1.0 版本發布：著重在整個核心功能，充分測試，高性能，高穩定性；生態系統：讓 CloudImage 足夠多，更好用，比如讓 MySQL、Redis 等更好用；社區推動：推動社區開發者，盡量把 Sealer 作為默認的安裝方式，一鍵交付到客戶的集群中。集群鏡像重塑分布式應用交付政采云私有化業務交付實踐政采云私有化業務交付實踐作者：汪勛，sealer maintainer，政采云技術專家，擁有多年云原生實踐經驗，具備豐富的大型私有化

135、項目交付實踐經驗。摘要：應用 Sealer 的政采云私有化業務交付實踐一、業務私有化交付之痛1、業務背景介紹政采云的業務主要是專注服務于政企采購的云服務平臺，業務主要面向政府和大型企業；具有較多的私有化部署項目；業務組件 300+，800+CPU 核心 2000G+內存；交付依賴：30G+2、交付痛點在業務私有化之前，政采云業務都是建立在公有云上，基礎設施穩定并可控，但轉為私有化以后，政府基于數據安全考慮對網絡和基礎設施都有一定的限制，導致在交付過程中遇到很多困難和問題：交付環境復雜，不可控；交付涉及任務太多，碎片嚴重，交付完總有遺漏事項；差異化的版本、配置導致 ansible 的方式成本很高

136、。下圖是最初第一版私有化業務交付系統的架構，使用 ansible 方式的問題是 ansible 只解決交付過程而不關心交付依賴。政采云私有化業務交付實踐政采云私有化業務交付實踐2、Sealer 的亮點功能a、編排定義：簡單而不失強大FROM kubernetes:1.19.9COPY helm/binRUN wgethttps:/cai- helm install app app-chartCMD helmlistb、鏡像緩存基于文本鏡像清單自動打包；多倉庫鏡像代理；多域名鏡像緩存能力；更多的 Sealer 亮點功能還包括：集群證書自動是 100 年無需擔心證書過期或額外配置；APIServi

137、ce 實現高可用無需用戶做額外配置等。3、交付架構升級下圖是交付系統升級后的架構，以 Sealer 為核心，通過編排渲染產出集群鏡像，其中包括交付環境的所有依賴，實現純離線場景下的業務交付。政采云私有化業務交付實踐政采云私有化業務交付實踐2、對 Sealer 未來的期望隨著對數據安全和隱私越來越高的需求，私有云逐漸搶占公有云市場，私有化業務也會隨之迅速增長。針對目前使用 Sealer 的一些經驗，對 Sealer 社區提出以下期望：生態建設：圍繞業務交付的中間件、存儲等依賴提供一整套的解決方案；管理功能強化：管理控制臺、API；使用體驗的持續優化：還存在一些待改進的地方；社區建設：吸引更多的伙

138、伴和場景。開放模塊化多集群管理平臺 OCM開放模塊化多集群管理平臺 OCMa、跨機房/地域 Etcd 運維問題首先是跨機房跨地域 Etcd 運維的問題，在輕量規模的 K8s 運維里，一個 Kubernetes 集群可以看作是 Etcd 上面無狀態的應用，大部分情況 K8s 的運維的問題，是取決于 Etcd 的運維問題；Etcd 有地域化配置的一些硬性要求，包括兩個機房之間的延遲，如果地域比較遠，將面臨Etcd 要拆分進行部署，如跨機房跨地域，因為 Etcd 要拆分進行部署，所以對應的 k8s 集群也需要進行重新規劃，另外在生產運維過程中也隨著K8s的規模增長而遇到Etcd請求壓力的瓶頸。b、K

139、ubenretes“可用性半徑”控制問題其次單機群的一個瓶頸是“可用性半徑”控制問題，在 K8s 里面雖然有 Namespace 的概念，在設計上希望能夠通過 Namespace 描述這樣的租戶隔離性，比如應用 1 應該部署在 Namespa-ce1，應用 2 部署在 Namespace2，但事實上 K8s 原生的隔離性還未達到期望，此外即使達到了理想的隔離狀態，但還需要預防一些不能預知的災難（如 k8s 升級/運維/宕機事件），為了能夠最簡單方式隔絕這些問題，就需要進行“可用性半徑”控制，也就是經常提到的爆炸半徑控制(比如在成都有個機房，上海有個機房，分別部署一套 K8s，在地域化推薦的服務

140、中也可以通過每個地域一套集群使得各自可用性不會出現沖突和相互牽連)。c、原生 Kubernetes 租戶級別隔離性不足最后是 K8s 內部原生租戶級別的隔離性不足，在多集群之外，還有一個并行的工作小組叫做多租戶，多集群和多租戶要解決的問題是同質的，而多集群解決隔離性是采取一種更溫和的方式：充分尊重單個集群 K8s，不修改源代碼，在控制平面進行對應 K8s 集群的管理，可以靈活的接管或者踢出一個集群。所謂的多租戶形態的集群管理，目標是能全透明的將各個集群的信息映射/收集回中樞控制面中再進行統一的管理。2、多集群用戶場景a、集群級別的彈性擴容目前多集群應用的場景也有很多，首先是集群級別的彈性擴容，

141、如阿里云上雙 11 的彈性大促和擴容；類似場景還有機房級別的彈性遷移，如在多機房遷移或者運營商的切換等情況下，需要進行集群級別的遷移，這種情況下需要多集群的控制平面，去管理和銜接其中的復雜性。開放模塊化多集群管理平臺 OCM開放模塊化多集群管理平臺 OCM1、主要架構OCM 的架構圖首先，在 K8s 架構中，K8s 有一個控制節點叫 kube-master（包括 Scheduler、Apiserver、Controller manager 等組件），將節點注冊到 master 里，在這個過程中，Node 是通過 ListWatch 是從遠端控制面里把對應的元數據信息（如 Pod、Node）拉取

142、下來，所以這是一個經典的 Pull 的架構模型。在原生的 K8s 里面有 Kubemaster，還有 Kubelet，在 OCM 里面對標是：Hub Cluster 對標 Kubemaster，Klusterlet 對標 Kubelet，將 K8s 集群當原子的黑箱看成Klusterlet，在運維 OCM 多集群管控面的集群時，其實就是在像運維某個 Node 一樣運維單個Kubernetes 群，該架構是天然模仿 Kubernetes 的架構也就是基于 Pull 模型。2、主要概念在了解 Hub 和 Klusterlet 這兩個核心的概念后，目前 OCM 支持的核心功能是什么呢？開放模塊化多集

143、群管理平臺 OCM開放模塊化多集群管理平臺 OCM如上圖是被納管的集群接入到 OCM 中樞的場景，首先需要規劃出中樞集群，在中樞集群里執行命令 Clusteradm join 操作，生成渲染后的指令，將其復制在被納管集群里執行，這樣被納管的集群就注冊成功了。OCM 注冊流程是不互信的，需要雙向握手，類似于 TCP 握手，不僅需要被納管的集群向中樞集群發起接管的請求，還需要中樞集群去批準這個請求。四、OCM 近期特性介紹1、插件框架/Addon-Framework插件框架具備以下特性：自由擴展；自由拆卸；持續運維和升級；開放模塊化多集群管理平臺 OCM開放模塊化多集群管理平臺 OCM3、多集群資

144、源狀態回流下圖是多集群資源狀態回流的 yaml 文件。4、可擴展的基于評分的多集群調度可擴展的基于評分多集群調度是基于打分機制將不同的應用部署到不同的集群中，適應于多集群細粒度調度、主備容災等場景。開放模塊化多集群管理平臺 OCM開放模塊化多集群管理平臺 OCM如上圖，用戶在中樞集群里面，需要訪問被納管的集群，Cluster Gateway 會將中樞集群與被納管集群的進行網絡打通，通過 Cluster Gateway 與 Knnoectivity 隧道做原生的集成，屏蔽掉中樞集群與納管集群網絡的復雜性，解決了多集群網絡連通性問題。如上圖，在 KubeVela1.2 版本中提供了安裝 OCM 的

145、快捷入口，OCM 是基于 Pull 指令的架構，可以通過安裝插件實現類似流量推送的功能。Nacos2.0 的 K8s 服務發現生態應用及規劃Nacos2.0 的 K8s 服務發現生態應用及規劃Nacos 誕生于阿里巴巴的五彩石項目，在阿里十年的雙十一中成長迭代，解決了應用擴展性和大規模治理的問題。為了幫助更多的公司和企業都能享受到微服務帶來的便利并加速數字化轉型，在 2018 年阿里巴巴將 Nacos 進行開源。Nacos 在開源的三年多中，用戶的使用場景變得越來越復雜，用戶規模越來越龐大，基于Nacos1.0 的 HTTP 架構就暴露出來了性能問題和擴展性問題，于是 Nacos 進行了 2.

146、0 的架構升級，引入了 Grpc 這個更高效的通信協議。并對功能架構做了大量的重構和優化。最終使得Nacos2.0 在擴展性和性能上提升了 10 倍。2、Nacos2.0 架構：Nacos2.0 架構圖，從上到下依次為接入層、通信協議、連接層、功能層、一次性協議、持久化層a、接入層首先是接入層，接入層為用戶使用和接入 Nacos 提供了一個入口，包括一些客戶端、OpenAPI、Springboot、阿里巴巴應用框架、Dubbo 的 RPC 框架，也有一些用戶（主要是運維人員）通過控制臺使用 Nacos。b、通信協議和連接層Nacos2.0 的 K8s 服務發現生態應用及規劃Nacos2.0 的

147、 K8s 服務發現生態應用及規劃比如 Dubbo、RPC 框架和 SOFA 的 RPC 框架以及應用框架 Spring Cloud Alibaba、還有高可用框架 Sentinel（在運行生態中做一些隔斷等操作）。各類網關也用到了 Nacos，比如阿里基于 Nginx 研發的 Tengine 網關、Spring Cloud Gatewa-y、Zuul 都是社區中比較常用的。Nacos 也在和原生社區進行結合，比如 MCP 協議就是進行數據交換、向 Envoy 網關推送配置規則、和應用框架（比如 Dapr 多語言框架）進行結合。二、Nacos 在 K8s 中服務發現的應用實踐1、早期的應用實踐早

148、期 Nacos 及整個微服務應用體系并沒有完全接入到 K8s 的能力體系中（比如服務網格體系），K8s 最初是作為一個容器資源調度的平臺來使用的，在這個框架下，所有的應用節點以及Nacos 自身節點會基于 K8s 進行部署，用 K8s 的一些自我恢復以及易于擴容縮容的能力作為資源的調度。Nacos2.0 的 K8s 服務發現生態應用及規劃Nacos2.0 的 K8s 服務發現生態應用及規劃a、Tengine 不支持熱更新Tengine 網關識別基于 Nginx 開發的，不支持動態配置，在配置變更后，需要人工進行 reload(重新加載)操作才能使變更后的配置生效，這就導致了緊急配置不能及時生效

149、，影響研發效率和線上處理故障的效率；b、兩層網關成本高流量經過兩層網關（Tengine 網關和微服務網關），流量的 RT 會相對變長，而且架構中如果引入一個插件，系統會變得更加復雜，對應的運維成本和服務器成本會增加；c、Fat SDK 模式，服務治理、服務發現等邏輯與 SDK 強耦合，升級困難在 Nacos 架構中，服務發現能力主要是基于應用所依賴的 Nacos SDK 所實現的，這會導致SDK 和應用的耦合度非常高，SDK 一旦出現問題或需要添加一個功能時，就需要應用側對 SDK進行升級，這個升級過程時間長而且難度大；d、多語言維護成本高，服務治理策略不統一不同公司的業務和系統會使用不同的編

150、程語言，維護不同多語言的 SDK 成本會比較高。不同語言的 SDK 在實現上會有一定的差別，而且版本演進遲緩，這導致有不能統一功能或治理策略，影響到最終的流量治理情況；e、純粹只拿 K8s 作為調度，應用程度低這個框架是純粹的將 K8s 作為一個資源調度的工具，并沒有使用到 K8s 提供的一些高級能力比如服務網格。2、云原生改造-使用服務網格為了解決以上 5 個問題，就需要對應用和框架進行改造。Nacos2.0 的 K8s 服務發現生態應用及規劃Nacos2.0 的 K8s 服務發現生態應用及規劃只有全新的應用可以使用，無法和舊體系互通，無法做到平滑迭代；應用元數據需要轉移到 Pod 的 la

151、bel 或 annotation 中，維護成本和改造成本高；注冊中心如何支持服務網格生態？3、解決方案a、將網關升級優化將兩個網關 Tengine 網關和 Envoy 網關進行融合，融合后的網關命名為云原生網關。云原生網關同時具備了微服務網關的能力，能夠直接對接 K8s 的所有服務體系，而且具備了一定Tengine 網關的能力、https 證書認證、安全防護的擴展能力。這個云原生網關的優勢就是將兩個網關合二為一，這樣減少了服務器的部署成本。這個云原生網關其實已經在阿里云上提供給廣大用戶生產使用了（可以搜索“微服務引擎MSE”）。流量經過網關，只需一次轉發，這樣可以降低整個 RT；另一方面，像應

152、用側這方面的能力可以通過輕量級 SDK 將邏輯下沉到 Sidecar 中，然后這種輕量級 SDK 只是去獲取信息，然后直接和Sidecar 進行交互，這樣大部分邏輯下沉到 Sidecar 之后，就會降低多語言的維護成本，不需要很大程度的改造業務代碼，可能只需要更換一下 SDK 版本就可以了。Nacos2.0 的 K8s 服務發現生態應用及規劃Nacos2.0 的 K8s 服務發現生態應用及規劃在阿里的落地實踐架構中，中間部分是集團的服務架構，如果新業務或部分應用的灰度節點會接入 MSE 體系，基于 Envoy/Sidecar 方式注冊到 Nacos 中，很多正在承載線上業務流量的節點仍然使用舊

153、的 SDK 的體系進行注冊和發現。在 Nacos 管理的所有服務列表中，通過 Istio 下發到 Ingress 的 Envoy 網關，實現預期的調用。隨著灰度程度擴大，會逐漸將原來的 Fat SDK 模式逐漸全部轉化為 Envoy/Sidecar 模式。在右邊釘釘的架構模型中，因為釘釘本身是一個新的業務，而且它和集團之間依賴關系比較弱，所以它可以直接使用這種云原生網關加服務網格的架構進行落地，流量經過 MSE 云原生網關，云原生網關中有從 Nacos 網關中獲取到的所有服務的信息，就可以通過 Dubbo3 協議轉發到各個微服務體系框架中，進行和預期一樣的調用。上圖左邊是螞蟻的用戶流量，它先是

154、經過 Tengine 網關，然后是經過 Mson On Envoy 網關，再路由到它們自身的一個 SOFA Micro Service 體系中進行調用。在跨業務域的調用過程中，云原生網關和 Envoy 網關也能夠很好的進行互相調用、互相發現，這樣的話也可以解決跨業務域之間的網絡安全性能問題，因為只有網關可以進行互相調用和互相發現，微服務體系之間是不能互相調用和發現的。三、Nacos 的 K8s 服務網格應用規劃Nacos2.0 的 K8s 服務發現生態應用及規劃Nacos2.0 的 K8s 服務發現生態應用及規劃Nacos 可以通過一定手段獲取到相關信息，可以獲取到暴露了哪些接口、輸入/輸出參

155、數對應的是什么等這類信息，利用這些更細節、更細膩的信息來進行控制面的生成，能夠更精細的控制流量的轉發（灰度能力），簡單來說就是微服務治理能力，這樣可以作為原生服務網格能力的增強。所以 Nacos 在未來會做一個控制面的功能，比如說直接實現 xDS 協議、暴露出一系列控制 API等），提供給使用 Nacos 的用戶做控制面的管理；同時實現 xDS 協議對控制面的直接對接，也可以解決一部分由于 MCP 協議同步大量服務信息所帶來的一些問題。3、Nacos 的服務治理生態其實在整個的實踐和落地過程中，將已經運行在微服務產品或微服務體系中的應用遷移到服務網格體系中的代價非常大的，而且這個過程中，對于不

156、同的業務線、不同部門在對接過程中是有很多重復工作的，將微服務體系遷移到微服務網格中同樣也會面臨這樣的問題和阻力。所以我們希望將 Nacos 和其它微服務產品共同解決這個問題，可以共同制定一個微服務治理的標準協議，來實現低成本或無成本的無縫對接；也可以將服務治理的標準協議轉化成服務網格協議（比如 xDS 協議），可以快速實現和原生服務網格控制面的對接，讓使用微服務產品的用戶享受到低成本遷移到服務網格生態的便利，這也是 Nacos 今后發展的主要方向。Nacos2.0 的 K8s 服務發現生態應用及規劃240相關鏈接：Nacos 官方文檔：https:/nacos.io/Nacos 源碼：https:/ 生態：https:/