邊緣計算場景下的邊緣自治

為什麼需要邊緣自治

在邊緣計算場景中，由於雲端與邊緣計算節點存在物理上的距離，那麼很有可能存在邊緣節點通過公網連線雲端的場景；從公網的不穩定性以及成本等因素考慮，邊緣要求斷網狀態或者弱網狀態下邊緣業務可以持續執行。

那麼傳統 K8s 的叢集中，架構如下：

因此在傳統 K8s 下，在雲邊網路異常時，存在如下問題：

問題 1：節點資料由 kubelet 從叢集獲取，節點異常或重啟時，記憶體資料丟失，網路斷連時容器無法恢復；

問題 2：網路長時間斷連時，雲端控制器認為主機故障而對業務容器進行驅逐；在驅逐後，恢復網路連線後，業務容器將不在預期邊緣節點部署；

邊緣業務恢復

kubeedge

kubeedge 對 kubelet 進行了功能的裁剪和修改，為 kubeedge 中的 Edged 元件；

邊緣節點通過 MetaManager 進行後設資料存取，過程如下：
Edged 獲取後設資料，判斷是否可以連線雲端，如果可以，則從雲端拉取後設資料，並更新到本地儲存 NodeLevel DataStore，如果無法連線到雲端，則直接從本地儲存獲取後設資料；當主機故障或重啟，不會由於拿不到雲端資料而影響業務恢復。

openyurt

openyurt 沒有侵入 K8s，在 kubelet 上加了 YurtHub 層；

kubelet 和雲端通訊將經由 YurtHub 元件，相當於具有資料快取功能的"透明閘道器"；同樣，在雲端網路斷連狀態下，節點重啟，將從本地獲取業務相關資料，解決邊緣自治問題。

業務資料恢復問題

這裡不對方案的優點進行比較，僅看解決業務資料恢復問題的方案和思路相差無幾，都是通過 kubelet(edged) 連線 k8s-apiserver 獲取資料時進行本地快取，在雲邊網路失連時都可以通過拿取本地後設資料來進行業務恢復，可以恢復到斷網時的業務狀態。

邊緣功能恢復

邊緣不止有計算功能：

Pod 需要對內或對外提供服務，邊緣節點網路恢復則是不容忽視的一個問題，例如原生 k8s 中節點重啟後：

• Pod IP 發生變化，雲邊資料不同的問題
• 路由資料丟失，無法訪問相同叢集內 pod
• IPVS 丟失，導致 Service 無法訪問

Pod 需要叢集管理的 Configmap 和 Secrets 資源，當節點重啟時：

• Pod 啟動時，獲取不到資源，啟動失敗

openyurt

openyurt 考慮此類資源同樣通過 Yurthub 儲存到本地儲存，通過從本地獲取來實現功能恢復。

kubeedge

待補充 kubeedge 方案

總結

綜上，在邊緣場景下，我們需要將叢集後設資料儲存到邊緣節點本地；雲邊網路失連時，當邊緣節點出現故障時，可以通過獲取本地後設資料恢復到斷網時的狀態，實現邊緣節點的自治。