【從0到1學習邊緣容器系列-4】弱網環境利器之分散式節點狀態判定機制

騰訊雲原生發表於2021-01-18

導語

邊緣場景下網路常常不可靠，容易誤觸發 Kubernetes 驅逐機制，引起不符合預期的 Pod 驅逐動作，TKE Edge 首創分散式節點狀態判定機制，該機制可以更好地識別驅逐時機，保障系統在弱網路下正常運轉，避免服務中斷和波動。

邊緣計算情境下，邊緣節點與雲端的網路環境十分複雜，網路質量無法保證，容易出現 APIServer 和節點連線中斷的場景。如果不加改造直接使用原生 Kubernetes，節點狀態會經常出現異常，進而引起 Kubernetes 驅逐機制生效，導致 Pod 的驅逐和 Endpoint 的缺失，最終造成服務的中斷和波動。為了解決這個問題，TKE 邊緣容器團隊在邊緣叢集弱網環境下提出了邊緣節點分散式節點狀態判定機制，可以更好地識別驅逐時機。

背景

不同於中心雲，邊緣場景下，首先要面對雲邊弱網路的環境，邊緣裝置常常位於邊緣雲機房、移動邊緣站點，與雲端連線的網路環境十分複雜，不像中心雲那麼可靠。這其中既包含雲端(控制端)和邊緣端的網路環境不可靠，也包含邊緣節點之間的網路環境不可靠，即使是同一區域不同機房之間也無法假設節點之間網路質量良好。

以智慧工廠為例，邊緣節點位於廠房倉庫和車間，控制端 Master 節點在騰訊雲的中心機房內。

倉庫和車間內的邊緣裝置同雲端叢集之間的網路較複雜，因特網、5G、WIFI 等形態均有可能，網路質量差次不齊沒有保障；但是，相比於和雲端的網路環境，由於倉庫和車間內的邊緣裝置之間是本地網路，因此網路質量肯定要優於同雲端叢集之間的連線，相對而言更加可靠。

造成的挑戰

原生 Kubernetes 處理方式

雲邊弱網路帶來的問題是影響執行在邊緣節點上的 kubelet 與雲端 APIServer 之間通訊，雲端 APIServer 無法收到 kubelet 的心跳或者續租，無法準確獲取該節點和節點上pod的執行情況，如果持續時間超過設定的閾值，APIServer 會認為該節點不可用，並做出如下一些動作：

失聯的節點狀態被置為 NotReady 或者 Unknown 狀態，並被新增 NoSchedule 和 NoExecute 的 taints
失聯的節點上的 Pod 被驅逐，並在其他節點上進行重建
失聯的節點上的 Pod 從 Service 的 Endpoint 列表中移除

需求場景

再看一個音視訊拉流場景，音視訊服務是邊緣計算的一個重要應用場景，如圖所示：

考慮到使用者體驗及公司成本，音視訊拉流經常需要提高邊緣快取命中率減少回源，將使用者請求的同一檔案排程到同一個服務例項以及服務例項快取檔案均是常見的做法。

然而，在原生 Kubernetes 的情況下，如果 Pod 因為網路波動而頻繁重建，一方面會影響服務例項快取效果，另一方面會引起排程系統將使用者請求排程到其他服務例項。無疑，這兩點都會對 CDN 效果造成極大的影響，甚至不能接受。

事實上，邊緣節點完全執行正常，Pod 驅逐或重建其實是完全不必要的。為了克服這個問題，保持服務的持續可用，TKE 邊緣容器團隊提出了分散式節點狀態判定機制。

解決方案

設計原則

顯然，在邊緣計算場景中，僅僅依賴邊緣端和 APIServer 的連線情況來判斷節點是否正常並不合理，為了讓系統更健壯，需要引入額外的判斷機制。

相較於雲端和邊緣端，邊緣端節點之間的網路更穩定，如何利用更穩定的基礎設施來提高準確性呢？我們首創了邊緣健康分散式節點狀態判定機制，除了考慮節點與 APIServer 的連線情況，還引入了邊緣節點作為評估因子，以便對節點進行更全面的狀態判斷。經過測試及大量的實踐證明，該機制在雲邊弱網路情況下大大提高系統在節點狀態判斷上的準確性，為服務穩定執行保駕護航。

該機制的主要原理：

每個節點定期探測其他節點健康狀態
叢集內所有節點定期投票決定各節點的狀態
雲端和邊緣端節點共同決定節點狀態

首先，節點內部之間進行探測和投票，共同決定具體某個節點是否存在狀態異常，保證大多數節點的一致判斷才能決定節點的具體狀態；另外，雖說節點之間的網路狀態一般情況下要優於雲邊網路，但同時應該注意到，邊緣節點之間網路情況也十分複雜，它們之間的網路也不是100%可靠。

因此，也不能完全信賴節點之間的網路，節點的狀態不能只由節點自行決定，雲邊共同決定才更為可靠。基於這個考慮，我們做出瞭如下的設計：

方案特性

需要注意的是，當雲端判定節點異常，但是其他節點認為節點正常的時候，雖然不會驅逐已有 Pod，但是為了確保增量服務的穩定性，不會再將新的 Pod 排程到該節點上，存量的正常執行也得益於邊緣叢集的邊緣自治能力；

另外，由於邊緣網路和拓撲的特殊性，常常會存在節點組之間網路單點故障的問題，比如廠房的例子中，倉庫和車間雖然都屬於廠房這個地域內，但是可能二者之間的網路連線依靠一條關鍵鏈路，一旦這條鏈路發生中斷，就會造成節點組之間的分裂，我們的方案能夠確保兩個分裂的節點組失聯後互相判定時始終保持多數的一方節點不會被判定為異常，避免被判定為異常造成 Pod 只能被排程到少部分的節點上，造成節點負載過高的情況。

除此之外，邊緣裝置很有可能位於不同的地區、相互不通，讓網路不通的節點之間相互檢查顯然就不合適了。為了應對這種情況，我們的方案也支援對節點進行分組，各個分組內的節點之間相互檢測狀態。考慮到有可能對節點重新分組，機制也支援實時對節點變更分組而無需重新部署檢測元件或重新初始化。

檢測機制預設關閉，如果需要操作可進入基本資訊-開啟 Edge Health（預設關閉），如果需要為節點分組，可以繼續開啟“開啟多地域”，然後給節點分組，分組方式為編輯和新增節點相應的標籤；如果開啟多地域檢查後未給節點分組，預設是各個節點自己是一個組，不會檢查其他節點。