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

時間 2021-01-19

標籤 node git github 緩存微信網絡架構分佈式學習測試欄目系統架構简体版

原文原文鏈接

導語

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

邊緣計算情境下，邊緣節點與雲端的網絡環境十分複雜，網絡質量沒法保證，容易出現 APIServer 和節點鏈接中斷的場景。若是不加改造直接使用原生 Kubernetes，節點狀態會常常出現異常，進而引發 Kubernetes 驅逐機制生效，致使 Pod 的驅逐和 Endpoint 的缺失，最終形成服務的中斷和波動。爲了解決這個問題，TKE 邊緣容器團隊在邊緣集羣弱網環境下提出了邊緣節點分佈式節點狀態斷定機制，能夠更好地識別驅逐時機。git

背景

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

以智慧工廠爲例，邊緣節點位於廠房倉庫和車間，控制端 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（默認關閉），若是須要爲節點分組，能夠繼續打開「開啓多地域」，而後給節點分組，分組方式爲編輯和添加節點相應的標籤；若是開啓多地域檢查後未給節點分組，默認是各個節點本身是一個組，不會檢查其餘節點。

在此特性開發過程當中，咱們也發現了一個 node taint 相關的 Kubernetes 社區 bug 並提出了修復方案。