《深度解讀 OpenYurt：從邊緣自治看 YurtHub 的擴展能力》

做者 | 新勝  阿里雲技術專家

導讀：OpenYurt 開源兩週以來，以非侵入式的架構設計融合雲原生和邊緣計算兩大領域，引發了很多行業內同窗的關注。阿里雲推出開源項目 OpenYurt，一方面是把阿里雲在雲原生邊緣計算領域的經驗回饋給開源社區，另外一方面也但願加速雲計算向邊緣延伸的進程，並和社區共同探討將來雲原生邊緣計算架構的統一標準。爲了更好地向社區和用戶介紹 OpenYurt，咱們特意推出【深度解讀OpenYurt】系列文章，本文爲系列文章的第三篇，一一介紹了 OpenYurt 中組件 YurtHub 的擴展能力。

系列文章推薦：

• OpenYurt 開箱測評 | 一鍵讓原生 K8s 集羣具有邊緣計算能力
• 深度解讀 OpenYurt ：邊緣自治能力設計解析

OpenYurt 介紹

阿里雲邊緣容器服務上線 1 年後，正式開源了雲原生邊緣計算解決方案 OpenYurt，跟其餘開源的容器化邊緣計算方案的區別在於：OpenYurt 秉持 Extending your native Kubernetes to edge 的理念，對 Kubernetes 系統零修改，並提供一鍵式轉換原生 Kubernetes 爲 openyurt，讓原生 K8s 集羣具有邊緣集羣能力。

同時隨着 OpenYurt 的持續演進，也必定會繼續保持以下發展理念：

• 非侵入式加強 K8s
• 保持和雲原生社區主流技術同步演進

YurtHub 架構說明

在上篇文章中，咱們介紹了 OpenYurt 的邊緣自治能力，重點解讀了其中的組件 YurtHub。其架構圖以下：

同時在介紹 YurtHub 的優點中咱們提到 與 Kubernetes 設計理念契合，YurtHub 很是容易擴展出更多的能力。具體在 YurtHub 擴展出了什麼能力呢？接下來咱們將一一展開介紹。

YurtHub 的擴展能力

1. 邊緣網絡自治

首先介紹一下何謂邊緣網絡自治：即在邊緣和雲端網絡斷連時，無論時業務容器重啓，或是邊緣節點重啓等，邊緣業務的跨節點通訊能夠持續工做或是自動恢復。

在 OpenYurt 中，實現邊緣網絡自治須要解決以下的問題（以 flannel vxlan overlay 網絡爲例）：

• 問題 1: 節點上的網絡配置能夠自治，kube-proxy 的 iptables/ipvs 規則，flannel 的 fdb/arp/route 配置，coredns 的域名解析等網絡配置，在節點重啓後能夠自動恢復，不然邊緣跨節點通訊將沒法持續；
• 問題 2: 業務容器 IP 保持不變，由於和雲端網絡斷連狀態下容器 IP 變化將沒法通知到其餘節點；
• 問題 3: vtep(vxlan tunnel endpoint) 的 mac 地址保持不變，緣由和容器 IP 保持不變相似。

從問題 1 能夠看出，必須解決 kube-proxy/flannel/coredns 等組件的自治，才能實現網絡配置的自治。若是以前邊緣自治是採用重構 kubelet 來實現的話，要實現邊緣網絡自治就會碰到很大的麻煩，若是強行把重構的 kubelet 自治能力移植到各個網絡組件 (kube-proxy/flannel/coredns)，也對整個架構將是噩夢。

在 OpenYurt 中由於 YurtHub 的獨立性，kube-proxy/flannel/coredns 等網絡組件輕鬆使用 YurtHub 來實現網絡配置的自治能力。由於 YurtHub 緩存了 service 等網絡配置資源在 local storage，即便斷網而且節點重啓，網絡組件仍然能夠得到斷網前的 object 狀態以及相應的配置信息。以下圖所示:

問題 2，3 和 Kubernetes core 無關，主要涉及到 cni 插件和 flanneld 的加強，後續文章中再詳細介紹。

2. 多雲端地址支持

公有云上的 Kubernetes 高可用部署時，多實例 kube-apiserver 前面通常都掛了一個 SLB，可是在專有云場景下或者邊緣計算場景下，節點須要經過多個雲端地址來訪問。好比:

• 專有云場景：由於沒有 SLB 服務，用戶須要須要在雲端經過 VIP 方式來自行實現 kube-apiserver 的負載均衡，或者像 kubespray 那樣在每一個節點上部署一個 nginx 來實現多雲端地址的訪問；
• 邊緣計算場景: 考慮到邊緣和雲端之間網絡的穩定性和安全性要求，某些場景下用戶也經過專線和公網兩種方式和雲端通訊，好比優先採用專線，當專線故障時能自動切換到公網通訊。

YurtHub 正式考慮到了上述的需求，支持多雲端地址訪問。雲端地址的負載均衡模式能夠選擇：

• rr(round-robin)： 輪轉模式，默認選擇該模式；
• priority: 優先級模式，高優先級地址故障後才使用低優先級地址。

具體能夠參照 YurtHub 的 LB 模塊，以下圖所示：

3. 節點維度的雲端流控

對於一個分佈式系統來講，流控都是一個沒法迴避的問題。原生 Kubernetes 從集羣視角在 kube-apiserver 中以及從訪問者視角在 client-go 庫中封裝了流量管控，在邊緣計算場景下，client-go 的流量管控既分散又對業務有必定侵入，顯然不能很好的解決流控問題。

YurtHub 在邊緣能夠接管不管是系統組件仍是業務容器對雲端訪問的流量，能夠很好的解決節點維度的雲端流控問題。目前 YurtHub 的流控配置是：單節點上對雲端的併發請求數超過 250 個時，將拒絕新的請求。

4. 節點證書輪換管理

Kubernetes 已經支持節點證書自動輪換，即當節點證書快過時前，kubelet 會自動向雲端申請新的節點證書。可是在邊緣計算場景下，頗有可能由於邊緣和雲端網絡的斷連，形成 kubelet 將沒法完成證書的輪換。證書過時後即便和雲端網絡鏈接恢復，節點證書也可能沒法自動輪換，並形成 kubelet 的頻繁重啓。

YurtHub 在接管節點和雲端通訊流量時，同時也能夠接管節點的證書管理。這樣既解決了各種安裝工具對節點證書的管理的不一致，也解決了證書過時後網絡再恢復時的證書輪換問題。另外目前 YurtHub 仍是 kubelet 共享節點證書，YurtHub 的獨立節點證書管理功能將在近期開源。

5. 其餘

YurtHub 除了前面介紹的擴展能力，還有不少有價值的能力，在此也簡單介紹：

• 節點多租隔離管理：在具有多租隔離能力的 Kubernetes 集羣中，假定節點歸屬於某個租戶，那麼 YurtHub 將能夠確保節點上全部雲端請求都只返回節點所屬租戶的資源。好比說 list service 將只返回該租戶的 service。而這種多租隔離能力不須要其餘組件作任何修改。固然若是要實現集羣內的多租隔離，須要配合相應的多組 CRD 等，詳細能夠參照項目 kubernetes-sigs/multi-tenancy；
• 集羣間節點遷移：某些場景下，邊緣節點須要從集羣 A 遷移到集羣 B，常規操做是先從集羣 A 下線，而後再次接入集羣 B，最後在集羣 B 部署節點上的應用。由於 YurtHub 對節點流量以及節點證書的接管，能夠直接對 YurtHub 注入集羣B的信息，讓節點無損遷移到集羣 B；
• 經過域名訪問雲端 kube-apiserver 等等一些其餘功能。

總結

• 經過上述的擴展能力能夠看出，YurtHub 不只僅是邊緣節點上的帶有數據緩存能力的反向代理。而是對 Kubernetes 節點應用生命週期管理加了一層新的封裝，提供邊緣計算所須要的核心管控能力；
• YurtHub 不只僅適用於邊緣計算場景，其實能夠做爲節點側的一個常備組件，適用於使用 Kubernetes 的任意場景。相信這也會驅動 YurtHub 向更高性能，更高穩定性發展。

參考連接

• kubespray: HA endpoints for K8s

OpenYurt 項目地址：https://github.com/alibaba/openyurt，歡迎你們參與共建！有疑問可加入釘釘交流羣：31993519

課程推薦

爲了更多開發者可以享受到 Serverless 帶來的紅利，這一次，咱們集結了 10+ 位阿里巴巴 Serverless 領域技術專家，打造出最適合開發者入門的 Serverless 公開課，讓你即學即用，輕鬆擁抱雲計算的新範式——Serverless。

點擊便可免費觀看課程：https://developer.aliyun.com/learning/roadmap/serverless

「 阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的公衆號。」