導語：邊緣計算模式下，云端的控制中心和邊緣端的設備之間網路環境較復雜，網路質量差次不齊沒有保障，用戶往往希望在弱網環境下，邊緣容器能提供高可用的業務能力，TKE 邊緣容器團隊在弱網環境下提出了邊緣自治功能，本文著重介紹了邊緣容器在弱網環境下為了保證業務高可用而做的作業，
問題背景
邊緣計算使用的邊緣設備數量龐大、分布全國各地，網路環境復雜，因特網、以太網、5G、WIFI 等形態均有可能，因此，云端的控制中心和邊緣端的設備之間網路環境較復雜，網路質量差次不齊沒有保障，
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 的方案和理念都有所不同，但是我個人認為緊跟業務腳步的產品以及技術才是最有價值的，個人技術能力有限，表達可能有疏漏，技術可能有錯誤，歡迎大家指出錯誤，共同進步，
這里歡迎更多有業務場景需要、感興趣的同學使用、加入、體驗，提需求，共優化，歡迎掃碼加騰小云同學好友，一起進群討論，
【騰訊云原生】云說新品、云研新術、云游新活、云賞資訊，掃碼關注同名公眾號，及時獲取更多干貨！！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/50510.html
標籤：其他