騰訊云：從lite-apiserver看SuperEdge邊緣節(jié)點自治

引言

在SuperEdge 0.2.0版本中，lite-apiserver進行了重大的架構升級和功能增強。本文將從lite-apiserver實現(xiàn)及其與其它SuperEdge組件協(xié)同的角度，分析SuperEdge的邊緣自治能力，給大家的研究和選型提供參考。

邊緣節(jié)點自治

在云邊協(xié)同的邊緣計算場景中，邊緣節(jié)點通過公網(wǎng)與云端連接。邊緣節(jié)點眾多，網(wǎng)絡環(huán)境復雜，網(wǎng)絡質量參差不齊。邊緣節(jié)點需要與云端弱網(wǎng)或斷網(wǎng)情況下，繼續(xù)正常工作，已運行的業(yè)務不受影響，達到邊緣節(jié)點自治的目的。為了實現(xiàn)邊緣節(jié)點自治，需要處理以下場景：

1.邊緣節(jié)點與云端斷連，但是它本身正常，上面運行的業(yè)務容器應該不被驅逐，也沒有新的業(yè)務容器調度到該節(jié)點上

2.邊緣節(jié)點與云端斷連時，邊緣節(jié)點上的Kubernetes組件和業(yè)務容器可繼續(xù)運行

3.邊緣節(jié)點與云端斷連時，邊緣節(jié)點重啟后，節(jié)點上的Kubernetes組件和業(yè)務容器可運行

4.邊緣節(jié)點與云端恢復后，邊緣節(jié)點上的數(shù)據(jù)與云端保持一致

SuperEdge使用分布式節(jié)點健康檢查組件edge-health來處理場景1，使用lite-apiserver來應對場景2、3、4。

lite-apiserver是運行在邊緣節(jié)點上的輕量級apiserver，它代理節(jié)點上所有組件和業(yè)務容器訪問云端kube-apiserver的請求，并對請求結果做高效緩存。在云邊斷連的情況下，利用這些緩存提供服務，實現(xiàn)邊緣自治的能力。

lite-apiserver設計特性

lite-apiserver除了滿足邊緣節(jié)點自治的功能需求外，還需要滿足以下設計特性：

支持所有Client類型

作為邊緣節(jié)點上訪問云端kube-apiserver的唯一“出口”，lite-apiserver需要支持所有類型的Client，包括以bin（如kubelet等）或pod（如flannelkube-proxy等）形式運行的Kubernetes組件，以及以InCluster方式訪問kube-apiserver的業(yè)務容器。更進一步，如果邊緣節(jié)點網(wǎng)絡環(huán)境特殊，需要以代理等方式才能訪問云端kube-apiserver時，只用給lite-apiserver設置代理，所有組件即可正常訪問云端kube-apiserver，不需要每個組件做單獨的配置。

支持緩存所有類型資源

支持緩存所有類型資源，Kubernetes內置資源和Custom Resources。邊緣節(jié)點上運行的Kubernetes組件和業(yè)務容器的請求kube-apiserver的資源多樣，如果只緩存部分資源類型或僅支持Kubernetes內置資源類型，在云邊斷連時，可能因為讀取不到對應的緩存導致組件或業(yè)務失敗，達不到邊緣節(jié)點自治的效果。當然，支持所有類型資源的緩存（尤其是Custom Resources），也給數(shù)據(jù)的解析和處理帶來了不小挑戰(zhàn)。

安全

邊緣節(jié)點分布廣泛，環(huán)境復雜，更容易造成安全風險。安全問題也在邊緣計算和Kubernetes管理中越來越受重視。給lite-apiserver賦予一個訪問權限，其代理的所有請求扔掉自身的權限方式，都使用lite-apiserver的權限訪問云端的kube-apiserver，是一種常見的訪問控制方案。由于lite-apiserver需要訪問和處理所有類型的資源，則該權限必然是一個“超級”權限。在這種情形下，某一個邊緣節(jié)點上的惡意程序就可以通過lite-apiserver對集群的所有資源進行操作，可能對整個集群進行惡意破壞。因此，從安全角度，lite-apiserver從設計上不應擁有一個“超級”權限，可以使用Kubernetes組件和業(yè)務容器原有的認證和鑒權方式，訪問云端kube-apiserver。

支持多種緩存存儲

根據(jù)IDC對邊緣計算分層的定義，邊緣分為Heavy Edge（邊緣數(shù)據(jù)中心）和Light Edge（低功耗計算平臺）。針對不同的場景，lite-apiserver可以采用不同的緩存存儲策略來達到更優(yōu)的效果。在Light Edge中，lite-apiserver使用文件存儲緩存以降低其本身的系統(tǒng)開銷，提升通用性。在Heavy Edge中，lite-apiserver可采用KV存儲等提升讀寫性能。

下面我們將從lite-apiserver的架構和關鍵技術方面，介紹其如何實現(xiàn)以上的功能需求和設計特性。

lite-apiserver架構與關鍵技術

架構

lite-apiserver架構如圖

從整體上看，lite-apiserver啟動一個HTTPS Server接受所有Client的請求（https request），并根據(jù)request tls證書中的Common Name選擇對應的ReverseProxy（如果request沒有mtls證書，則使用default），將request轉發(fā)到kube-apiserver。當云邊網(wǎng)絡正常時，將對應的返回結果（https response）返回給client，并按需將response異步存儲到緩存中；當云邊斷連時，訪問kube-apiserver超時，從緩存中獲取已緩存的數(shù)據(jù)返回給client，達到邊緣自治的目的。

·HTTPS Server監(jiān)聽localhost的端口（SurperEdge中為51003）接受Client的Https請求。

·Cert Mgr&&Transport Mgr Cert Mgr負責管理連接kube-apiserver的TLS客戶端證書。它周期性加載配置的TLS證書，如果有更新，通知Transport Mgr創(chuàng)建或更新對應的transport。Transport Mgr負責管理transport。它接收Cert Mgr的通知，創(chuàng)建新的transport，或者關閉證書已更新的transport的舊連接。

·Proxy根據(jù)request mtls證書中的Common Name選擇對應的ReverseProxy（如果request沒有mtls證書，則使用default），將request轉發(fā)到kube-apiserver。如果請求成功，則將結果直接給Client返回，并調用Cache Mgr緩存數(shù)據(jù)；如果請求失敗，則從Cache Mgr中讀取數(shù)據(jù)給Client。

·Cache Mgr根據(jù)Client的類型分別緩存Get和List的結果數(shù)據(jù)，并根據(jù)Watch的返回值，更新對應的List數(shù)據(jù)。

關鍵技術

1.HTTPS Server

在當前架構下，lite-apiserver只處理本節(jié)點的所有請求，使用HTTP Server可以滿足性能和安全要求。然而，大部分組件和業(yè)務容器采用client-go庫訪問kube-apiserver，如果使用HTTP Server，Client自己的認證和鑒權信息全部丟失，不符合權限管理的要求。因此必須采用HTTPS Server。lite-apiserver的TLS Server證書，需用kube-apiserver的Server證書相同的CA簽發(fā)。

2.支持InCluster方式訪問

一般的Client通過指定kube-apiserver的URL訪問kube-apiserver，使用lite-apiserver時，只需將原來kube-apiserver的URL替換為lite-apiserver的地址即可。在Pod中訪問kube-apiserver的推薦方式是通過kubernetes.default.svc這個DNS名稱，該名稱將會解析為服務IP，然后服務IP將會路由到kube-apiserver。在這種場景下使用lite-apiserver需要一些小小的"魔法"。在SuperEdge中，application-grid-wrapper以DaemonSet的形式部署在每個邊緣節(jié)點上，通過給kube-proxy只返回本區(qū)域內的endpoints來達到訪問在區(qū)域內閉環(huán)的目的。利用這個特性，application-grid-wrapper把kubernetes這個Service的endpoint改為lite-apiserver的地址，返回給本節(jié)點kube-proxy，即可支持InCluster方式訪問。

3.支持Client的Bootstrap Token和證書輪換

lite-apiserver使用Client自己的認證和鑒權方式，訪問云端的kube-apiserver。對于static token、bootstrap token、service account等方式，lite-apiserver只需透傳Http Request的Header中包含的認證鑒權信息即可。對于TLS客戶端證書的認證方式，lite-apiserver通過讀取配置文件，加載所有Client用到的TLS客戶端證書，使用這些證書構造對應的HTTPS請求kube-apiserver。為了支持Client的Bootstrap Token和證書輪換，lite-apiserver需要周期性的加載和更新這些證書。kube-controller-manager簽發(fā)的證書默認時間是1年，lite-apiserver加載TLS客戶端證書周期不宜過短。但如果證書加載周期時間過長，kubelet使用Bootstrap Token的場景中會存在證書更新不及時的問題。為了處理這些場景，lite-apiserver采用一種“優(yōu)雅”的證書加載策略：當加載證書出現(xiàn)錯誤或證書過期時，進入快速加載模式，周期是1s;加載證書均成功時，進入普通加載模式，周期是30min。當證書更新后，lite-apiserver使用client-go[1]提供的closeAll方法，關閉已存在的連接，以防認證鑒權失敗。

4.緩存解析和更新

lite-apiserver需要支持緩存所有類型的資源，緩存的解析和更新是lite-apiserver實現(xiàn)的關鍵之一。lite-apiserver分別緩存每個Client對資源的Get和List請求，這樣雖然造成了一定的存儲空間的浪費，但是可以支持緩存所有資源類型，尤其是用戶自定義資源，并且天然具有資源版本兼容能力，能夠處理同一資源存在多個版本的情況。對于Watch類型的請求結果，lite-apiserver采用unstructured.UnstructuredJSONScheme解析出資源的meta信息，進而更新相應的List數(shù)據(jù)。

展望

SuperEdge正式開源以來，得到了廣泛的關注。SuperEdge在快速迭代開發(fā)中，lite-apiserver也有不少可擴展點，歡迎大家積極參與，共同打造一個優(yōu)秀的云原生邊緣容器項目。

·內存中緩存部分高頻更新的資源，提升性能

·支持更多種類存儲

·性能和內存優(yōu)化，適應更廣泛的邊緣場景

參考資料

[1] client-go:https://github.com/kubernetes/client-go/blob/master/util/connrotation/connrotation.go#L20