導語：邊緣計算模式下，雲端的控制中心和邊緣端的設備之間網絡環境較複雜，網絡質量差次不齊沒有保障。用戶每每但願在弱網環境下，邊緣容器能提供高可用的業務能力。TKE 邊緣容器團隊在弱網環境下提出了邊緣自治功能。本文着重介紹了邊緣容器在弱網環境下爲了保證業務高可用而作的工做。docker
問題背景
邊緣計算使用的邊緣設備數量龐大、分佈全國各地，網絡環境複雜，因特網、以太網、5G、WIFI 等形態均有可能。所以，雲端的控制中心和邊緣端的設備之間網絡環境較複雜，網絡質量差次不齊沒有保障。api
kubernetes 傳統工做模式是全部組件 list-watch kube-apiserver，而後 reconcile 各類資源到指望狀態。各節點的健康都強依賴於其與 kube-apiserver 通訊的穩定。kubernetes 在傳統的集羣環境上工做很完美，由於大多數集羣都能保證在一個局域網內。然而，在邊緣計算的業務場景下，有一個穩定的網絡環境着實是一件奢侈的事情。網絡
在這樣的背景下，如何保證邊緣集羣的業務高可用性以及服務高可用性？一直都是一個難題。爲此咱們騰訊雲邊緣容器團隊（TKE@EDGE）設計了兩個利器來專門啃下這塊硬骨頭，本篇將重點講第一個利器——邊緣自治。架構
（注：此文提到的網絡環境，都是指節點與雲端的網絡環境，而不是業務運行所在環境。）運維
需求舉例
咱們來以一個常見的廠房模型來介紹一下用戶在弱網環境下使用傳統 kubernetes 遇到的問題以及 TKE 邊緣容器團隊在此類場景下提出的解決方案。分佈式
如上圖所示，該案例採用的部署模式爲：用戶在騰訊雲公有云上購買了幾臺 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 是典型的經過數據進行交互的架構。解決數據問題就能提供一個夯實的基礎。因此弱網環境的邊緣自治，首當其衝的，最最最須要解決的問題就是數據問題。
考慮到弱網、斷網狀況，須要保證節點的組件與雲端組件「通訊」，或者說讓節點認爲此時仍是能夠「通訊」的。如上圖所示，咱們在邊緣端加了一層鏡像 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 以及網絡快照機制保證了邊緣容器集羣在弱網環境下的網絡可靠性。
適用場景
騰訊雲邊緣容器產品支持用戶在雲端經過 kubernetes 方式來管理邊緣節點，支持管控平臺與 work 節點網絡環境分離，具有弱網環境下的容災能力，支持用戶自定義網絡流量，而且全部核心組件都與開源 kubernentes 保持一致，目前已經支持 1.18 版本。
目前 TKE@EDGE 具有公有云和私有云兩種產品形態，歡迎來官網體驗使用邊緣容器公有云產品（ https://console.cloud.tencent.com/tke2/edge ），產品入口目前爲白名單可見，請聯繫文章做者開通白名單。
後續計劃
後續咱們還會有一系列工做，來增強在弱網環境下的工做穩定性。
- 插件化改造。將邊緣自治的解決方案改造爲插件，提供給傳統 kubernetes 某些業務來按需使用
- 支持徹底去中心化 lite-apiserver，來協助 kube-apiserver 在弱網環境下業務的管理
寫在最後
咱們的解決方案對於原生使用 kubernetes 的方案和理念都有所不一樣，可是我我的認爲緊跟業務腳步的產品以及技術纔是最有價值的。我的技術能力有限，表達可能有疏漏，技術可能有錯誤，歡迎你們指出錯誤，共同進步。
這裏歡迎更多有業務場景須要、感興趣的同窗使用、加入、體驗，提需求，共優化。歡迎掃碼加騰小云同窗好友，一塊兒進羣討論。
【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊，掃碼關注同名公衆號，及時獲取更多幹貨！！