本文作者：
李志信，OpenYurt Member，Apache dubbo PMC，專注於雲原生邊緣計算的系統架構和解決方案
張逸飛，OpenYurt Member，浙江大學 SEL 實驗室
雲原生邊緣計算智能開源平臺 CNCF OpenYurt 於近期發佈了 v1.2 版本。OpenYurt 是業界首個對雲原生體系無侵入智能邊緣計算平臺，具備全方位的“雲、邊、端一體化”能力，能夠快速實現海量邊緣計算業務和異構算力的高效交付、運維及管理。
在 v1.2 版本中，OpenYurt 遵循社區提出的“節點池治理”理念，新增組件 Pool-Coordinaotr，提出了一套針對雲邊場景的資源、網絡、應用、監控等角度的邊緣治理方案。本文首先聚焦雲邊場景下的網絡優化問題的解決進行解讀，敬請持續關注。
Pool-Coordinator 節點池治理及其對雲邊網絡的優化
組件背景
早在去年年初，社區就提出了 “節點池治理” 的概念。節點池爲 OpenYurt 生態概念，表示集羣內一組網絡互通的邊緣機器節點。在雲邊協同場景，邊緣 IOT 設備與算力往往依賴多臺機器節點工作，節點池概念爲 OpenYurt 生態在邊緣算力的管控粒度方面增加了一個維度。而“節點池治理”，專注於邊緣機器的資源、網絡、生命週期、可觀測指標等等角度，提供了邊緣測視角與管理思路。
Pool-Coordinator 在社區內首次踐行了這一概念，提出了一套針對雲邊場景的資源、網絡、應用、監控等角度的邊緣治理方案，具備高可用能力。
邊緣基礎組件對雲邊網絡的需求與挑戰
邊緣基礎組件對於邊雲網絡的要求，驅使着 OpenYurt 爲開發者提供更合理、更優化的解決方案。
首先是雲邊網絡帶寬基礎條件的問題。在雲原生邊緣計算的場景中，雲邊網絡通路帶寬往往受到各個方面的限制，例如機器資源，物理距離，資金成本等，這就導致對於部分廠商和用戶，其雲邊網絡條件帶寬較低，甚至在各別特定環境的節點池帶寬極低。
其次是集羣資源數據量的問題。邊緣集羣往往覆蓋較多地域、機器節點與物理設備，相比於普通集羣，其覆蓋地域廣闊，規模較大，集羣整體資源量也就相對較多。對於部分集羣基礎組件，例如代理組件、CNI 組件、DNS 組件，甚至部分業務組件，例如設備驅動程序，邊緣基礎架構中間件等，需要在啓動時通過 K8S List/Watch 機制來拉取全量資源並監聽，這個過程對網絡要求較高。
再者是邊緣基礎組件的重要性，在新節點納管入邊緣集羣時，初始化程序會拉起一系列 OpenYurt 邊緣基礎組件與配置，待順利初始化，纔會調度業務程序至節點。一旦邊緣基礎組件由於帶寬原因，拉取依賴資源失敗，會導致邊緣機器業務應用無法啓動，邊緣節點算力擴容失敗。另一方面，處於運行中的邊緣基礎組件，如果長時間拉取資源失敗，可能造成網絡、代理、存儲資源與中心不同步，造成業務風險。
能力、架構實現與工作方式
3.1 Pool-Scope（節點池維度）資源緩存
Pool-Coordinator 會爲節點池維度的資源提供邊緣側緩存，從而降低因爲這些資源的大量 list/watch 請求造成的雲邊網絡帶寬問題。
在部署階段，開發者可以通過安裝 Chart 包的方式，將 Pool-Coordinator 組件安裝至集羣，該過程利用了 OpenYurt 生態的 YurtAppDaemon 資源，將這一組件以節點池粒度部署至所有的邊緣節點池，每個節點池一個實例。
待 Pool-Coordinator 實例啓動，會由選主機制選出的 Leader YurtHub 將 Pool-Scope 資源，例如 endpoints/endpointslice 拉取至邊緣，進而同步至 Pool-Coordinator 組件，緩存起來，以供節點池內全部節點使用。
節點池內全部節點上運行的 YurtHub，將 Pool-Scope 資源讀請求代理至 Pool-Coordinator。理論上，針對一個資源的全量請求，一個節點池只需要一條雲邊長鏈接即可，節點池內的這些資源的讀請求，都交由 Pool-Coordinator 向下提供服務，從而極大程度降低雲邊網絡消耗。特別是在具有帶寬要求的弱網絡場景，Pool-Coordinator 可以削弱由於邊緣基礎容器啓動/重建導致的大量請求，以及減少運行時期的雲邊資源下發量。
Pool-Scope 資源默認定義爲 endpoints 和 endpointslices 兩種資源。這兩種資源在 YurtHub 代理的雲邊流量中佔比較高，這在規模較大集羣中體現的更爲明顯；另外 Pool-Scope 資源要求爲節點池內公用的資源，與調用方所屬節點無關，這也適配於上述兩者。Pool-Scope 資源可由用戶配置其他資源，例如 Pods，Node，以及 CR，以應對在特定資源量大的網絡優化場景。
3.2 YurtHub 的初始化、選主與容災機制
當新的節點池創建並添加算力時，YurtHub 作爲邊緣機器節點的底層進程將最先啓動。其優先直連 APIServer，執行正常的初始化邏輯。待節點加入集羣，OpenYurt 組件 Yurt-App-Manager 將按需調度邊緣節點池組件 Pool-Coordinator 至該機器。等到 Pool-Coordinator 成功啓動，YurtHub 將探知其可用狀態，與之建聯交互。YurtHub 提供 --enable-coordinator 啓動參數，將該參數置爲true時，YurtHub 會對節點池 Pool-Coordinator 組件進行探知，爲節點池內靈活的切流、按需啓動提供了支持。
一個節點池內的全部 YurtHub 實例存在讀寫衝突問題，我們指定這些 YurtHub 通過 Pool-Coordinator 內的分佈式鎖執行選主，只有 Leader YurtHub 負責緩存資源寫操作。其他 Follower 將時刻監聽 Pool-Coordinator 內保存的 Leader Lease 資源，從而確定是否 Leader 存活，只有存活的 Leader 才能保證緩存資源的正確性和時效性。當 Leader YurtHub 因爲某些原因，例如和中心網絡斷開，以及自身原因而退出，將由其他 Follower YurtHub 中重新選主，保證邊緣緩存的可用性。
這個過程我們提供了 Grace Period 機制，即當短暫的雲邊網絡故障導致的 Leader YurtHub 不健康狀態，不會導致邊緣節點池切流至雲端，當超過一定時間之後再進行切流，以防網絡抖動和大量節點切流導致帶寬徹底打滿。
當 Pool-Coordinator 因異常原因退出後，邊緣 YurtHub 將感知，並將代理請求轉發至雲端，從而獲得正確響應。待 Pool-Coordinator 重建後，會重啓選主機制，重建邊緣緩存，降低雲邊帶寬消耗。
證書與鑑權
Pool-Coordinator 套件提供完備的證書管理機制，並保證在流量轉發過程的權限正確。
在系統初始化階段，會由 Yurt-Controller-Manager 簽發證書，該證書被 YurtHub 和 Pool-Coordinator 獲取，保證 YurtHub 有權限，並可以安全讀寫緩存。
對於 Pool-Scope 資源請求轉發緩存的過程中，會進行 Token 替換，保證這次請求帶有緩存讀寫權限。
展望
隨着 v1.2 版本的發佈，Pool-Coordinator 在後續將繼續着重於穩定性建設和生態組件建設，包括可觀測能力、網絡抖動的魯棒性優化、斷網自制能力、Pool-Coordinator 容器運維能力等。Pool-Coordinator 組件也將會工業生產中的大規模落地實踐，並像其他 OpenYurt 生態組件一樣在生產過程中迭代和優化，提升系統穩定性。
歡迎有更多的貢獻者與用戶參與 Pool-Coordinator 的建設！如果您對於 OpenYurt 有任何疑問，歡迎使用釘釘掃描二維碼或者搜索羣號（12640034121）加入釘釘交流羣。
戳此處，立即瞭解 OpenYurt 項目