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

導讀：OpenYurt 開源兩週以來，以非侵入式的架構設計融合雲原生和邊緣計算兩大領域，引起了不少行業內同學的關注。阿里雲推出開源專案 OpenYurt，一方面是把阿里雲在雲原生邊緣計算領域的經驗回饋給開源社群，另一方面也希望加速雲端計算向邊緣延伸的程式，並和社群共同探討未來雲原生邊緣計算架構的統一標準。為了更好地向社群和使用者介紹 OpenYurt，我們特地推出【深度解讀OpenYurt】系列文章，本文為系列文章的第二篇，詳細介紹了 OpenYurt 的邊緣自治能力的設計細節。

系列文章推薦：

• OpenYurt 開箱測評 | 一鍵讓原生 K8s 叢集具備邊緣計算能力

OpenYurt 介紹

5 月 29 號 OpenYurt 正式開源了。OpenYurt 作為公共雲服務 ACK@Edge 的核心框架，已經應用於 CDN、音視訊直播、物聯網、物流、工業大腦、城市大腦等實際應用場景中，並服務於阿里雲 LinkEdge、盒馬、優酷、視訊雲等多個業務或專案中。目前開源的能力包括：

• 邊緣自治能力

• 原生 K8s 叢集一鍵式轉換為邊緣叢集

OpenYurt 專案地址：https://github.com/alibaba/openyurt，歡迎大家一起來參與開源！

邊緣自治特性

1. 特性介紹

將 Kubernetes 系統延展到邊緣計算場景，邊緣節點將通過公網和雲端連線，從公網的不穩定性以及成本等因素考慮，邊緣要求斷網狀態或者弱網狀態下邊緣業務可以持續執行。我們從 Gartner 的邊緣計算報告中提到的邊緣計算訴求中，邊緣自治也是主要訴求之一：

而從 Kubernetes 系統架構來看，主要因為 Slave Agent(Kubelet) 中的容器資訊儲存在記憶體中，斷網狀態下因為無法從雲端獲取業務資料，如果節點或者 Kubelet 重啟，將無法進行業務容器恢復。如下圖：

2. 邊緣自治需要解決的問題

因此邊緣自治在 Kubernetes 系統裡，需要解決下面的問題:

• 問題 1：節點異常或重啟時，記憶體資料丟失，網路斷連時業務容器無法恢復；

• 問題 2：網路長時間斷連，雲端控制器對業務容器進行驅逐；

• 問題 3：長時間斷連後網路恢復時，邊緣和雲端資料的一致性保障。

問題 1 的解決方案

解決方案 1：重構 kubelet 元件，複用或者參考 kubelet 的 checkpoint 功能，持久化容器業務資料到本地磁碟，網路斷連狀態下利用本地快取資料實現業務恢復。

該方案經過重構 kubelet，成功解決邊緣自治的需求，具備如下優點：

 

• 通過重構 kubelet，方便在 kubelet 中整合對端裝置的管理能力；

• 通過重構 kubelet，可以對 kubelet 進行輕量化改造。此優點但是也意味著原生 kubelet 功能缺失的問題。

 

但是也有如下不足：

• 可維護性差: 侵入式修改 kubelet core，跟隨社群版本升級非常困難，熟悉kubelet的同學都會有同感，kubelet 元件由於直接負責跟計算，儲存，網路互動，所以其程式碼結構和邏輯異常複雜。因此持續維護一個深度修改過的 kubelet 的工作量可想而知；

• 可擴充套件性差: 因為自治能力直接做到重構的 kubelet 元件中，這樣邊緣節點如果其他元件(如網路元件)想複用邊緣自治能力將面臨重複造輪子的境地；

• 場景耦合更深: 例如在 kubelet 重構中增加了 IOT 裝置管理，將可能使 kubelet 和 IOT 場景深度耦合。

解決方案 2 (OpenYurt 使用方案)：在邊緣節點上增加 web 快取及請求代理 hub(取名為 YurtHub，商業產品中名為 edge-hub)，邊緣側元件(kubelet)和雲端通訊將經由該元件。YurtHub 相當於帶有資料快取功能的”透明閘道器“，和雲端網路斷連狀態下，如果節點或者 kubelet 重啟，將從 YurtHub 中獲取到業務容器相關資料，有效解決邊緣自治的問題。

相比解決方案 1，有如下優勢:

• kubelet 零修改，意味原生 kubelet 能力天然具備，同時跟隨 Kubernetes 版本升級零負擔；

• 可擴充套件性強，節點其他元件輕鬆複用 YurtHub；

• 與 Kubernetes 設計理念契合，YurtHub 非常容易擴充套件出更多的能力。

當然 OpenYurt 的解決方案，也會面臨如下的問題：原生 kubelet 比較 high-weight，在資源緊張場景下應用會比較挑戰。目前商業產品中節點規格推薦 2U4G 起步。

問題 2 和 3 的解決方案

問題 2 和問題 3 的解決方案相比比較簡單，因此不展開做過多的方案說明和比較。

• 問題 2：原生雲端元件 kube-controller-manager 對 Pod 驅逐解決

該問題正是通過開源元件 yurt-controller-manager 中的 Node Controller 來解決的。如 github 主頁介紹所示：

• 問題 3: 網路恢復時，邊緣和雲端網路一致性

Kubernetes 系統中，使用者是通過雲端對邊緣進行管控的(如應用部署，升級，擴縮容等)，因此當邊緣和雲端網路斷聯時，邊緣節點將不會從雲端同步使用者對節點的管控操作，因此斷網期間，只要 YurtHub 保持本地快取資料和斷網時刻一致(即斷網期間邊緣快取資料不更新)，而網路恢復時，再從雲端同步最新資料即可。

後續展開

OpenYurt 剛剛開源，也意味這塊工作剛剛開始，相信我們更貼近雲原生的架構設計，會支援 OpenYurt 走的更遠。同時 OpenYurt 設計理念：Extending your native Kubernetes to edge，相信也會讓雲原生愛好者更為接受。

參考連結：gartner 報告連結

OpenYurt 專案地址：https://github.com/alibaba/openyurt

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/69975341/viewspace-2699324/，如需轉載，請註明出處，否則將追究法律責任。