從 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 來應對場景2、3、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 也有不少可擴充點，歡迎大家積極參與，共同打造一個優秀的雲原生邊緣容器項目。

• 記憶體中緩存部分高頻更新的資源，提升性能
• 支援更多種類存儲
• 性能和記憶體優化，适應更廣泛的邊緣場景