從 lite-apiserver 看 SuperEdge 邊緣節點自治

引言

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

邊緣節點自治

在雲邊協同的邊緣計算場景中，邊緣節點經過公網與雲端鏈接。邊緣節點衆多，網絡環境複雜，網絡質量良莠不齊。邊緣節點須要與雲端弱網或斷網狀況下，繼續正常工做，已運行的業務不受影響，達到邊緣節點自治的目的。
爲了實現邊緣節點自治，須要處理如下場景：

1. 邊緣節點與雲端斷連，可是它自己正常，上面運行的業務容器應該不被驅逐，也沒有新的業務容器調度到該節點上
2. 邊緣節點與雲端斷連時，邊緣節點上的 Kubernetes 組件和業務容器可繼續運行
3. 邊緣節點與雲端斷連時，邊緣節點重啓後，節點上的 Kubernetes 組件和業務容器可運行
4. 邊緣節點與雲端恢復後，邊緣節點上的數據與雲端保持一致

SuperEdge 使用分佈式節點健康檢查組件 edge-health 來處理場景1，使用 lite-apiserver 來應對場景二、三、4。

lite-apiserver 是運行在邊緣節點上的輕量級 apiserver，它代理節點上全部組件和業務容器訪問雲端 kube-apiserver 的請求，並對請求結果作高效緩存。在雲邊斷連的狀況下，利用這些緩存提供服務，實現邊緣自治的能力。

lite-apiserver 設計特性

lite-apiserver除了知足邊緣節點自治的功能需求外，還須要知足如下設計特性：

支持全部 Client 類型

做爲邊緣節點上訪問雲端 kube-apiserver 的惟一「出口」，lite-apiserver 須要支持全部類型的 Client ，包括以 bin （如 kubelet 等）或 pod （如 flannel\kube-proxy 等）形式運行的 Kubernetes 組件，以及以 InCluster 方式訪問 kube-apiserver 的業務容器。
更進一步，若是邊緣節點網絡環境特殊，須要以代理等方式才能訪問雲端 kube-apiserver時，只用給 lite-apiserver 設置代理，全部組件便可正常訪問雲端 kube-apiserver，不須要每一個組件作單獨的配置。

支持緩存全部類型資源

支持緩存全部類型資源，Kubernetes 內置資源和 Custom Resources。
邊緣節點上運行的 Kubernetes 組件和業務容器的請求 kube-apiserver 的資源多樣，若是隻緩存部分資源類型或僅支持 Kubernetes 內置資源類型，在雲邊斷連時，可能由於讀取不到對應的緩存致使組件或業務失敗，達不到邊緣節點自治的效果。固然，支持全部類型資源的緩存（尤爲是 Custom Resources ），也給數據的解析和處理帶來了不小挑戰。

安全

邊緣節點分佈普遍，環境複雜，更容易形成安全風險。安全問題也在邊緣計算和 Kubernetes 管理中愈來愈受重視。
給 lite-apiserver賦予一個訪問權限，其代理的全部請求扔掉自身的權限方式，都使用 lite-apiserver 的權限訪問雲端的 kube-apiserver，是一種常見的訪問控制方案。因爲 lite-apiserver 須要訪問和處理全部類型的資源，則該權限必然是一個「超級」權限。在這種情形下，某一個邊緣節點上的惡意程序就能夠經過 lite-apiserver 對集羣的全部資源進行操做，可能對整個集羣進行惡意破壞。
所以，從安全角度，lite-apiserver 從設計上不該擁有一個「超級」權限，可使用 Kubernetes 組件和業務容器原有的認證和鑑權方式，訪問雲端 kube-apiserver。

支持多種緩存存儲

根據 IDC 對邊緣計算分層的定義，邊緣分爲 Heavy Edge（邊緣數據中心）和 Light Edge（低功耗計算平臺）。針對不一樣的場景，lite-apiserver 能夠採用不一樣的緩存存儲策略來達到更優的效果。在 Light Edge 中，lite-apiserver 使用文件存儲緩存以下降其自己的系統開銷，提高通用性。在 Heavy Edge 中，lite-apiserver 可採用 KV 存儲等提高讀寫性能。

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

lite-apiserver 架構與關鍵技術

架構

lite-apiserver架構如圖

從總體上看，lite-apiserver 啓動一個 HTTPS Server 接受全部 Client 的請求（https request），並根據 request tls 證書中的 Common Name 選擇對應的 ReverseProxy（若是 request 沒有 mtls 證書，則使用 default），將 request 轉發到 kube-apiserver。當雲邊網絡正常時，將對應的返回結果（https response）返回給client，並按需將response異步存儲到緩存中；當雲邊斷連時，訪問kube-apiserver超時，從緩存中獲取已緩存的數據返回給client，達到邊緣自治的目的。

• HTTPS Server
  監聽 localhost 的端口（SurperEdge 中爲51003）接受 Client 的 Https 請求。
• Cert Mgr && Transport Mgr
  Cert Mgr 負責管理鏈接 kube-apiserver 的 TLS 客戶端證書。它週期性加載配置的TLS證書，若是有更新，通知Transport Mgr建立或更新對應的transport。
  Transport Mgr負責管理transport。它接收Cert Mgr的通知，建立新的transport，或者關閉證書已更新的transport的舊鏈接。
• Proxy
  根據 request mtls 證書中的 Common Name 選擇對應的 ReverseProxy（若是 request 沒有 mtls 證書，則使用 default），將 request 轉發到 kube-apiserver。若是請求成功，則將結果直接給 Client 返回，並調用 Cache Mgr 緩存數據；若是請求失敗，則從 Cache Mgr 中讀取數據給 Client。
• Cache Mgr
  根據 Client 的類型分別緩存 Get 和 List 的結果數據，並根據 Watch 的返回值，更新對應的 List 數據。

關鍵技術

1. HTTPS Server

在當前架構下，lite-apiserver 只處理本節點的全部請求，使用 HTTP Server 能夠知足性能和安全要求。然而，大部分組件和業務容器採用 client-go 庫訪問 kube-apiserver，若是使用 HTTP Server，Client 本身的認證和鑑權信息所有丟失，不符合權限管理的要求。所以必須採用 HTTPS Server。lite-apiserver 的 TLS Server 證書，需用 kube-apiserver 的 Server 證書相同的CA簽發。

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 的形式部署在每一個邊緣節點上，經過給 kube-proxy 只返回本區域內的 endpoints 來達到訪問在區域內閉環的目的。利用這個特性，application-grid-wrapper 把 kubernetes 這個 Service 的 endpoint 改成 lite-apiserver 的地址， 返回給本節點 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 簽發的證書默認時間是1年，lite-apiserver 加載 TLS 客戶端證書週期不宜太短。但若是證書加載週期時間過長，kubelet 使用 Bootstrap Token 的場景中會存在證書更新不及時的問題。爲了處理這些場景，lite-apiserver 採用一種「優雅」的證書加載策略：當加載證書出現錯誤或證書過時時，進入快速加載模式，週期是1s; 加載證書均成功時，進入普通加載模式，週期是30min。
當證書更新後，lite-apiserver 使用 client-go 提供的closeAll方法，關閉已存在的鏈接，以防認證鑑權失敗。

4. 緩存解析和更新

lite-apiserver 須要支持緩存全部類型的資源，緩存的解析和更新是 lite-apiserver 實現的關鍵之一。lite-apiserver 分別緩存每一個 Client 的對資源的 Get 和 List 請求，這樣雖然形成了必定的存儲空間的浪費，可是也避免了複雜的資源版本轉換。對於 Watch 類型的請求結果，lite-apiserver 採用unstructured.UnstructuredJSONScheme 解析出資源的 meta 信息，進而更新相應的 List 數據。

展望

SuperEdge 正式開源以來，獲得了普遍的關注。SuperEdge 在快速迭代開發中，lite-apiserver 也有很多可擴展點，歡迎你們積極參與，共同打造一個優秀的雲原生邊緣容器項目。

• 內存中緩存部分高頻更新的資源，提高性能
• 支持更多種類存儲
• 性能和內存優化，適應更普遍的邊緣場景