導語：邊緣計算模式下，雲端的控制中心和邊緣端的裝置之間網路環境較複雜，網路質量差次不齊沒有保障。使用者往往希望在弱網環境下，邊緣容器能提供高可用的業務能力。TKE 邊緣容器團隊在弱網環境下提出了邊緣自治功能。本文著重介紹了邊緣容器在弱網環境下為了保證業務高可用而做的工作。

## 問題背景

邊緣計算使用的邊緣裝置數量龐大、分佈全國各地，網路環境複雜，因特網、乙太網、5G、WIFI 等形態均有可能。因此，雲端的控制中心和邊緣端的裝置之間網路環境較複雜，網路質量差次不齊沒有保障。

kubernetes 傳統工作模式是所有元件 list-watch kube-apiserver，然後 reconcile 各種資源到期望狀態。各節點的健康都強依賴於其與 kube-apiserver 通訊的穩定。kubernetes 在傳統的叢集環境上工作很完美，因為大多數叢集都能保證在一個區域網內。然而，在邊緣計算的業務場景下，有一個穩定的網路環境著實是一件奢侈的事情。

在這樣的背景下，如何保證邊緣叢集的業務高可用性以及服務高可用性？一直都是一個難題。為此我們騰訊雲邊緣容器團隊（TKE@EDGE）設計了兩個利器來專門啃下這塊硬骨頭，本篇將重點講第一個利器——邊緣自治。

（注：此文提到的網路環境，都是指節點與雲端的網路環境，而不是業務執行所在環境。）

## 需求舉例

我們來以一個常見的廠房模型來介紹一下使用者在弱網環境下使用傳統 kubernetes 遇到的問題以及 TKE 邊緣容器團隊在此類場景下提出的解決方案。

![廠房邊緣計算模型](https://main.qcloudimg.com/raw/59100c9622af295ed1f993843ce7556f.png)

如上圖所示，該案例採用的部署模式為：使用者在騰訊雲公有云上購買了幾臺 CVM 機器作為 master 節點，其上部署了 kube-apiserver、kube-controller-manager、kube-scheduler 三大元件。然後根據業務需求，為每一個廠房都建立多個邊緣 worker 節點，部署 kubelet 和 kube-proxy 以及 dockerd。同廠房節點之間可以互相訪問， 不同廠房節點網路不互通。比如兩個分佈在北京和廣州的廠房的邊緣節點雖然可以歸屬於同一個叢集，但是它們之間的網路是不互通的。每個廠房內所有節點會透過公網連線至雲端管控端，但是這個網路通道都屬於不可靠的弱網環境。

廠房A在北京地區，廠房B在廣州地區。二者之間是不能互通的。

使用者透過 kubernetes 管理平臺進行workload的管理，master 與 worker 節點所在的廠房之間的網路環境網路環境是不能保證的，可能弱網A斷網，網路B仍然正常。使用者在這樣的場景下，提出了幾個需求：

- 節點即使和 master 失聯，節點上的業務能繼續執行
- 保證如果業務容器異常退出或者掛掉，kubelet 能繼續拉起
- 保證節點**重啟**後，業務能繼續重新被拉起來
- 使用者在廠房內部署的是**微服務**，需要保證節點重啟後，同一個廠房內的微服務可以訪問

對於使用者來說，這些訴求是他們的基本需求，也是其業務上雲的關鍵因素。使用者想要既享受 kubernetes 帶來方便的管理運維，同時也要具備弱網環境下的容災能力。這對傳統標準 kubernentes 解決方案提出了挑戰。

## 標準kubernetes處理方式

我們來溫習一下標準的 kubernentes 下，如果節點斷網失聯並且發生異常重啟的行為後，會出現哪些現象呢？

- 失聯的節點狀態置為 NotReady 或者 Unknown 狀態
- 失聯的節點上的業務進場異常退出後，容器可以被拉起
- 失聯的節點上的 Pod IP 從 Endpoint 列表中摘除
- 失聯的節點發生點重啟後，容器全部消失不會被拉起

我們依次來看，首先，在傳統的模式下，節點是否健康取決於節點上 kubelet 元件的心跳或者續租。如果網路斷了，雲端元件當然會認為節點是不可用狀態。這個狀態可以提示使用者，該節點可能有異常，需要運維介入。同時，由於 kubelet 還在接管所有本機 Pod，即使業務容器異常退出，容器也是可以繼續被拉起的。失聯的節點上所有的 Pod ，它們的 IP 都會被從 Endpoint list 中摘除，導致微服務不能訪問到這個節點，在傳統 kubernentes 叢集中，這是一個高可用的措施。但是在邊緣叢集內，這個“節點不可用=服務不可用”等式是否還成立呢？這個地方是需要探討的，其實很多業務場景下，使用者希望節點即使和雲端斷網，該節點上的 Pod 也要能繼續對外提供服務。

因此我們團隊認為，在邊緣容器的場景下，單純與雲端網路失聯是不能被粗暴地認為“服務不可用”的。為此我們特意設計了第二件利器——“分散式節點健康檢查”外掛，來解決這個痛點，該功能會在後續文章進行詳細介紹。

下面重頭戲來了，斷網的節點重啟一下，容器還會在嗎？服務還可用嗎？回答是，容器當然不在嘍。而且容器不在了，服務肯定不能訪問了。使用者最關鍵的需求，顯然在傳統的 kubernentes 模式下，是不能滿足的。

那麼來看看我們邊緣計算的利器——邊緣自治功能能達到的效果吧。

## TKE 的邊緣自治效果

### TKE 的邊緣自治效果

- 節點會被置為 NotReady 或者 Unknown 狀態，但是服務仍然可用
- 多節點斷網情況下，Pod 業務正常執行，微服務能力正常提供
- 多節點斷網情況下並重啟後，Pod 會被重新拉起並正常執行
- 多節點斷網情況下並重啟後，所有的微服務可以被正常訪問

我們為了達到最符合使用者的效果，配合使用了分散式節點健康檢查外掛功能，來保證節點在斷網情況下即使節點被置為NotReady 狀態，但是服務還是繼續可用。同時該節點上的 Pod 也不會在新的節點上重新拉起新的 Pod 副本。

我們在極端網路環境下，將執行業務的多個節點手動執行重啟操作來模擬節點異常重啟場景。節點重啟之後，節點元件正常啟動，之前的 Pod 也會被自動被拉起，並且執行正常，處於 Running 狀態。

那服務以及網路呢？我們測試後發現，重啟多個節點之後，我們在節點手動請求 Pod ip，可以訪問成功；進入 Pod A 內部分別請求在同一個節點上的 Pod B 以及另一個節點上的 Pod C（需要同一個廠房環境），都可以訪問成功；在 Pod A 解析 同一廠房的 Service A， 可以解析併成功。最後，在外部對於該廠房內部的服務進行請求，訪問成功。

如此看來，邊緣自治功能，有效解決了傳統 kubernetes 在弱網環境下所不能解決的使用者痛點。

## 原理簡介

我們團隊為邊緣自治功能打磨了很久，涉及方面眾多，修改以及設計的地方比較多，本文不太介紹具體程式碼實現細節。有興趣的同學可以和TKE邊緣容器同學共同進行學習探討。在此我簡單分享一些設計原理。

### lite-apiserver機制

kubernetes 是典型的透過資料進行互動的架構。解決資料問題就能提供一個夯實的基礎。所以弱網環境的邊緣自治，首當其衝的，最最最需要解決的問題就是資料問題。

![兩者網路模式對比](https://main.qcloudimg.com/raw/8af8358638315a9248f11178ba891c7f.png)

考慮到弱網、斷網情況，需要保證節點的元件與雲端元件“通訊”，或者說讓節點認為此時還是可以“通訊”的。如上圖所示，我們在邊緣端加了一層映象 lite-apiserver 元件。邊緣節點上所有對 kube-apiserver 的請求都會發往 lite-apiserver，並由 lite-apiserver 轉發到 kube-apiserver。對於邊緣節點來說，lite-apiserver 提供的功能就是 kube-apiserver 一樣，但是一方面 lite-apiserver 只對本節點有效，另一方面相比較標準的 kube-apiserver，我們對於 lite-apiserver 進行了裁剪，大幅度降低了其資源佔用。我們在沒有修改原生 kube-apiserver 的情況下，實現了。在網路通暢的情況下，lite-apiserver 元件對於節點元件來說是透明的。當網路異常情況，lite-apiserver 元件會把本節點需要的資料返回給節點上元件，保證節點元件不會受網路異常情況影響。

### 網路快照機制

OK，lite-apiserver 機制保證了斷網情況下，節點也不會和“apiserver”失聯。既然節點可以拉取到本節點對應的資料，那麼業務 Pod 也就能夠被 kubelet 成功拉起來。下一步就是解決 Pod 之間的互相訪問的問題了。

在邊緣容器場景下，考慮到適配性以及易用性，我們採用了 flannel 元件的 vxlan 模式作為網路解決方案。flannel 元件保證了跨節點之前的網路訪問。節點上的flannel 以及每個 Pod 都有一些對應屬於自己的網路資訊，我們這裡採用了網路快照機制，將專屬於這些元件的網路資訊定期快照，從而保證了斷網環境下重啟後網路可用。並且實現了同節點、跨節點 Pod 之間的網路互通。

### DNS解決方案

使用者業務對外正常提供服務，以及叢集內微服務之間互相呼叫，這些問題都會涉及到域名解析。

![img](https://main.qcloudimg.com/raw/edc6fc3d2541dff59fb10a4326e7e1e7.png)
如上圖所示，在傳統 kubernetes上，透過在叢集中建立一個kube-dns deployment 來解決是來解決域名問題。但是邊緣計算叢集，所有節點可能是不在一個區域網，很可能是跨可用區的，各節點和 kube-dns 的訪問無法保證，一個 kube-dns 的 deployment 不能滿足邊緣容器的需求。

![img](https://main.qcloudimg.com/raw/76c26545392c17ef2749624a018cc283.png)

在邊緣容器場景下，採用 DaemonSet 方式部署kube-dns，保證每個節點都有可用的 kube-dns，同時修改每個節點上 kubelet 啟動引數`--cluster-dns`，將其指向本機IP。這樣就保證了，即使斷網情況下，也能解析 kubernetes service 的域名。

總結而言就是 lite-apiserver 機制為基礎， kube-proxy、flannel、kube-dns 以及網路快照機制保證了邊緣容器叢集在弱網環境下的網路可靠性。

## 適用場景

騰訊雲邊緣容器產品支援使用者在雲端透過 kubernetes 方式來管理邊緣節點，支援管控平臺與 work 節點網路環境分離，具備弱網環境下的容災能力，支援使用者自定義網路流量，並且所有核心元件都與開源 kubernentes 保持一致，目前已經支援 1.18 版本。

目前 TKE@EDGE 具備公有云和私有云兩種產品形態，歡迎來官網體驗使用邊緣容器公有云產品（ [https://console.cloud.tencent.com/tke2/edge](https://console.cloud.tencent.com/tke2/edge?rid=1) ），產品入口目前為白名單可見，請聯絡文章作者開通白名單。

## 後續計劃

後續我們還會有一系列工作，來加強在弱網環境下的工作穩定性。

- 外掛化改造。將邊緣自治的解決方案改造為外掛，提供給傳統 kubernetes 某些業務來按需使用
- 支援完全去中心化 lite-apiserver，來協助 kube-apiserver 在弱網環境下業務的管理

## 寫在最後

我們的解決方案對於原生使用 kubernetes 的方案和理念都有所不同，但是我個人認為緊跟業務腳步的產品以及技術才是最有價值的。個人技術能力有限，表達可能有疏漏，技術可能有錯誤，歡迎大家指出錯誤，共同進步。

這裡歡迎更多有業務場景需要、感興趣的同學使用、加入、體驗，提需求，共最佳化。歡迎掃碼加騰小云同學好友，一起進群討論。

【從0到1學習邊緣容器系列-3】應用容災之邊緣自治

相關文章