雲栖号資訊：【 點選檢視更多行業資訊】
在這裡您可以找到不同行業的第一手的上雲資訊，還在等什麼，快來！
作者 | 新勝 阿裡雲技術專家
導讀：OpenYurt 開源兩周以來，以非侵入式的架構設計融合雲原生和邊緣計算兩大領域，引起了不少行業内同學的關注。阿裡雲推出開源項目 OpenYurt，一方面是把阿裡雲在雲原生邊緣計算領域的經驗回饋給開源社群，另一方面也希望加速雲計算向邊緣延伸的程序，并和社群共同探讨未來雲原生邊緣計算架構的統一标準。為了更好地向社群和使用者介紹 OpenYurt，我們特地推出【深度解讀OpenYurt】系列文章，本文為系列文章的第三篇，一一介紹了 OpenYurt 中元件 YurtHub 的擴充能力。
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 向更高性能，更高穩定性發展。
【雲栖号線上課堂】每天都有産品技術專家分享！
課程位址：
https://yqh.aliyun.com/live立即加入社群，與專家面對面，及時了解課程最新動态！
【雲栖号線上課堂 社群】
https://c.tb.cn/F3.Z8gvnK
原文釋出時間：2020-06-30
本文作者：阿裡巴巴雲原生
本文來自：“
掘金”，了解相關資訊可以關注“掘金”