邊緣計算模式下，雲端的控制中心和邊緣端的設備之間網絡環境較複雜，網絡質量差次不齊沒有保障。用戶往往希望在弱網環境下，邊緣容器能提供高可用的業務能力。TKE 邊緣容器團隊在弱網環境下提出了邊緣自治功能。本文着重介紹了邊緣容器在弱網環境下爲了保證業務高可用而做的工作。
1問題背景
邊緣計算使用的邊緣設備數量龐大、分佈全國各地，網絡環境複雜，因特網、以太網、5G、WIFI 等形態均有可能。因此，雲端的控制中心和邊緣端的設備之間網絡環境較複雜，網絡質量差次不齊沒有保障。
kubernetes 傳統工作模式是所有組件 list-watch kube-apiserver，然後 reconcile 各種資源到期望狀態。各節點的健康都強依賴於其與 kube-apiserver 通信的穩定。kubernetes 在傳統的集羣環境上工作很完美，因爲大多數集羣都能保證在一個局域網內。然而，在邊緣計算的業務場景下，有一個穩定的網絡環境着實是一件奢侈的事情。
在這樣的背景下，如何保證邊緣集羣的業務高可用性以及服務高可用性？一直都是一個難題。爲此我們騰訊雲邊緣容器團隊（TKE@EDGE）設計了兩個利器來專門啃下這塊硬骨頭，本篇將重點講第一個利器——邊緣自治。
（注：此文提到的網絡環境，都是指節點與雲端的網絡環境，而不是業務運行所在環境。）
2需求舉例
我們來以一個常見的廠房模型來介紹一下用戶在弱網環境下使用傳統 kubernetes 遇到的問題以及 TKE 邊緣容器團隊在此類場景下提出的解決方案。
廠房邊緣計算模型
如上圖所示，該案例採用的部署模式爲：用戶在騰訊雲公有云上購買了幾臺 CVM 機器作爲 master 節點，其上部署了 kube-apiserver、kube-controller-manager、kube-scheduler 三大組件。然後根據業務需求，爲每一個廠房都創建多個邊緣 worker 節點，部署 kubelet 和 kube-proxy 以及 dockerd。同廠房節點之間可以互相訪問， 不同廠房節點網絡不互通。比如兩個分佈在北京和廣州的廠房的邊緣節點雖然可以歸屬於同一個集羣，但是它們之間的網絡是不互通的。每個廠房內所有節點會通過公網連接至雲端管控端，但是網絡環境是不可靠的。
用戶通過 kubernetes 管理平臺進行workload的管理，master 與 worker 節點所在的廠房之間的網絡環境網絡環境是不能保證的，可能弱網A斷網，網絡B仍然正常。用戶在這樣的場景下，提出了幾個需求：
•節點即使和 master 失聯，節點上的業務能繼續運行
•保證如果業務容器異常退出或者掛掉，kubelet 能繼續拉起
•保證節點重啓後，業務能繼續重新被拉起來
•用戶在廠房內部署的是微服務，需要保證節點重啓後，同一個廠房內的微服務可以訪問
對於用戶來說，這些訴求是他們的基本需求，也是其業務上雲的關鍵因素。用戶想要既享受 kubernetes 帶來方便的管理運維，同時也要具備弱網環境下的容災能力。這對傳統標準 kubernentes 解決方案提出了挑戰。
3標準 kubernetes 處理方式
我們來溫習一下標準的 kubernentes 下，如果節點斷網失聯並且發生異常重啓的行爲後，會出現哪些現象呢？
•失聯的節點狀態置爲 NotReady 或者 Unknown 狀態
•失聯的節點上的業務進場異常退出後，容器可以被拉起
•失聯的節點上的 Pod IP 從 Endpoint 列表中摘除
•失聯的節點發生點重啓後，容器全部消失不會被拉起
我們依次來看，首先，在傳統的模式下，節點是否健康取決於節點上 kubelet 組件的心跳或者續租。如果網絡斷了，雲端組件當然會認爲節點是不可用狀態。這個狀態可以提示用戶，該節點可能有異常，需要運維介入。
同時，由於 kubelet 還在接管所有本機 Pod，即使業務容器異常退出，容器也是可以繼續被拉起的。失聯的節點上所有的 Pod ，它們的 IP 都會被從 Endpoint list 中摘除，導致微服務不能訪問到這個節點，在傳統 kubernentes 集羣中，這是一個高可用的措施。但是在邊緣集羣內，這個“節點不可用=服務不可用”等式是否還成立呢？這個地方是需要探討的，其實很多業務場景下，用戶希望節點即使和雲端斷網，該節點上的 Pod 也要能繼續對外提供服務。
因此我們團隊認爲，在邊緣容器的場景下，單純與雲端網絡失聯是不能被粗暴地認爲“服務不可用”的。爲此我們特意設計了第二件利器——“分佈式節點健康檢查”插件，來解決這個痛點，該功能會在後續文章進行詳細介紹。
下面重頭戲來了，斷網的節點重啓一下，容器還會在嗎？服務還可用嗎？回答是，容器當然不在嘍。而且容器不在了，服務肯定不能訪問了。用戶最關鍵的需求，顯然在傳統的 kubernentes 模式下，是不能滿足的。
那麼來看看我們邊緣計算的利器——邊緣自治功能能達到的效果吧。
4TKE@EDGE 的邊緣自治
•節點會被置爲 NotReady 或者 Unknown 狀態，但是服務仍然可用
•多節點斷網情況下，Pod 業務正常運行，微服務能力正常提供
•多節點斷網情況下並重啓後，Pod 會被重新拉起並正常運行
•多節點斷網情況下並重啓後，所有的微服務可以被正常訪問
我們爲了達到最符合用戶的效果，配合使用了分佈式節點健康檢查插件功能，來保證節點在斷網情況下即使節點被置爲NotReady 狀態，但是該節點上的 Pod 的 IP 仍然在 Endpoint 列表中，所以該節點的 Pod 仍然可以被訪問到，對外服務繼續可用。
我們在極端網絡環境下，將運行業務的多個節點手動執行重啓操作來模擬節點異常重啓場景。節點重啓之後，節點組件正常啓動，之前的 Pod 也會被自動被拉起，並且運行正常，處於 Running 狀態。
那服務以及網絡呢？我們測試後發現，重啓多個節點之後，我們在節點手動請求 Pod IP，可以訪問成功；進入 Pod A 內部分別請求在同一個節點上的 Pod B 以及另一個節點上的 Pod C（需要同一個廠房環境），都可以訪問成功；在 Pod A 解析 同一廠房的 Service A， 可以解析併成功。最後，在外部對於該廠房內部的服務進行請求，訪問成功。
如此看來，邊緣自治功能，有效解決了傳統 kubernetes 在弱網環境下所不能解決的用戶痛點。
5原理簡介
我們團隊爲邊緣自治功能打磨了很久，涉及方面衆多，修改以及設計的地方比較多，本文不具體介紹代碼實現細節。有興趣的同學可以和 TKE@EDGE 邊緣容器同學共同進行學習探討。在此我簡單分享一些設計原理。
lite-apiserver機制
kubernetes 是典型的通過數據進行交互的架構。解決數據問題就能提供一個夯實的基礎。所以弱網環境的邊緣自治，首當其衝的，最最最需要解決的問題就是數據問題。
兩者網絡模式對比
考慮到弱網、斷網情況，需要保證節點的組件與雲端組件“通信”，或者說讓節點認爲此時還是可以“通信”的。如上圖所示，我們在邊緣端加了一層鏡像 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解決方案
用戶業務對外正常提供服務，以及集羣內微服務之間互相調用，這些問題都會涉及到域名解析。
如上圖所示，在傳統 kubernetes上，通過在集羣中創建一個kube-dns Deployment 來解決域名問題。但是邊緣計算集羣，所有節點可能是不在一個局域網，很可能是跨可用區的，各節點對於 kube-dns 服務的訪問無法保證成功，kube-dns 的 Deployment 部署方式不能滿足邊緣容器的需求。
在邊緣容器場景下，採用 DaemonSet 方式部署 kube-dns，保證每個節點都有獨立且可用的 kube-dns 容器，同時修改每個節點上 kubelet 啓動參數 --cluster-dns，將其指向本機 IP。這樣就保證了，即使斷網情況下，也能解析 kubernetes service 的域名。
總結而言就是以 lite-apiserver 機制爲基礎，kube-proxy、flannel、kube-dns 以及網絡快照機制相配合，共同保證了邊緣容器集羣在弱網環境下的網絡可靠性。
6適用場景
騰訊雲邊緣容器產品支持用戶在雲端通過 kubernetes 方式來管理邊緣節點，支持管控平臺與 work 節點網絡環境分離，具備弱網環境下的容災能力，支持用戶自定義網絡流量，並且所有核心組件都與開源 kubernentes 保持一致，目前已經支持 1.18 版本。
目前 TKE@EDGE 具備公有云和私有云兩種產品形態，歡迎來官網體驗使用邊緣容器公有云產品（ https://console.cloud.tencent.com/tke2/edge ），產品入口目前爲白名單可見，請聯繫文章作者開通白名單。
7後續計劃
後續我們還會有一系列工作，來加強在弱網環境下的工作穩定性。
•插件化改造。將邊緣自治的解決方案改造爲插件，提供給傳統 kubernetes 某些業務來按需使用
•支持完全去中心化 lite-apiserver，來協助 kube-apiserver 在弱網環境下業務的管理
8寫在最後
我們的解決方案對於原生使用 kubernetes 的方案和理念都有所不同，但是我個人認爲緊跟業務腳步的產品以及技術纔是最有價值的。個人技術能力有限，表達可能有疏漏，技術可能有錯誤，歡迎大家指出錯誤，共同進步。