lite-apiserver怎么實現

這篇文章主要介紹了lite-apiserver怎么實現的相關知識，內容詳細易懂，操作簡單快捷，具有一定借鑒價值，相信大家閱讀完這篇lite-apiserver怎么實現文章都會有所收獲，下面我們一起來看看吧。

引言

在 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 數據。

關于“lite-apiserver怎么實現”這篇文章的內容就介紹到這里，感謝各位的閱讀！相信大家對“lite-apiserver怎么實現”知識都有一定的了解，大家如果還想學習更多知識，歡迎關注億速云行業資訊頻道。