這篇文章主要介紹了lite-apiserver怎么實(shí)現(xiàn)的相關(guān)知識(shí)，內(nèi)容詳細(xì)易懂，操作簡(jiǎn)單快捷，具有一定借鑒價(jià)值，相信大家閱讀完這篇lite-apiserver怎么實(shí)現(xiàn)文章都會(huì)有所收獲，下面我們一起來(lái)看看吧。

站在用戶的角度思考問(wèn)題，與客戶深入溝通，找到臨澧網(wǎng)站設(shè)計(jì)與臨澧網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗(yàn)，讓設(shè)計(jì)與互聯(lián)網(wǎng)技術(shù)結(jié)合，創(chuàng)造個(gè)性化、用戶體驗(yàn)好的作品，建站類型包括：成都做網(wǎng)站、成都網(wǎng)站設(shè)計(jì)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣、域名注冊(cè)、虛擬主機(jī)、企業(yè)郵箱。業(yè)務(wù)覆蓋臨澧地區(qū)。

引言

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

邊緣節(jié)點(diǎn)自治

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

1. 邊緣節(jié)點(diǎn)與云端斷連，但是它本身正常，上面運(yùn)行的業(yè)務(wù)容器應(yīng)該不被驅(qū)逐，也沒(méi)有新的業(yè)務(wù)容器調(diào)度到該節(jié)點(diǎn)上

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

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

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

SuperEdge 使用分布式節(jié)點(diǎn)健康檢查組件 edge-health 來(lái)處理場(chǎng)景1，使用 lite-apiserver 來(lái)應(yīng)對(duì)場(chǎng)景2、3、4。

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

lite-apiserver 設(shè)計(jì)特性

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

支持所有 Client 類型

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

支持緩存所有類型資源

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

安全

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

支持多種緩存存儲(chǔ)

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

下面我們將從 lite-apiserver 的架構(gòu)和關(guān)鍵技術(shù)方面，介紹其如何實(shí)現(xiàn)以上的功能需求和設(shè)計(jì)特性。

lite-apiserver 架構(gòu)與關(guān)鍵技術(shù)

架構(gòu)

lite-apiserver架構(gòu)如圖

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

• HTTPS Server監(jiān)聽(tīng) localhost 的端口（SurperEdge 中為51003）接受 Client 的 Https 請(qǐng)求。

• Cert Mgr && Transport MgrCert Mgr 負(fù)責(zé)管理連接 kube-apiserver 的 TLS 客戶端證書(shū)。它周期性加載配置的TLS證書(shū)，如果有更新，通知Transport Mgr創(chuàng)建或更新對(duì)應(yīng)的transport。 Transport Mgr負(fù)責(zé)管理transport。它接收Cert Mgr的通知，創(chuàng)建新的transport，或者關(guān)閉證書(shū)已更新的transport的舊連接。

• Proxy根據(jù) request mtls 證書(shū)中的 Common Name 選擇對(duì)應(yīng)的 ReverseProxy（如果 request 沒(méi)有 mtls 證書(shū)，則使用 default），將 request 轉(zhuǎn)發(fā)到 kube-apiserver。如果請(qǐng)求成功，則將結(jié)果直接給 Client 返回，并調(diào)用 Cache Mgr 緩存數(shù)據(jù)；如果請(qǐng)求失敗，則從 Cache Mgr 中讀取數(shù)據(jù)給 Client。

• Cache Mgr根據(jù) Client 的類型分別緩存 Get 和 List 的結(jié)果數(shù)據(jù)，并根據(jù) Watch 的返回值，更新對(duì)應(yīng)的 List 數(shù)據(jù)。

關(guān)鍵技術(shù)

1. HTTPS Server

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

2. 支持 InCluster 方式訪問(wèn)

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

3. 支持 Client 的 Bootstrap Token 和證書(shū)輪換

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

4. 緩存解析和更新

lite-apiserver 需要支持緩存所有類型的資源，緩存的解析和更新是 lite-apiserver 實(shí)現(xiàn)的關(guān)鍵之一。lite-apiserver 分別緩存每個(gè) Client 的對(duì)資源的 Get 和 List 請(qǐng)求，這樣雖然造成了一定的存儲(chǔ)空間的浪費(fèi)，但是也避免了復(fù)雜的資源版本轉(zhuǎn)換。對(duì)于 Watch 類型的請(qǐng)求結(jié)果，lite-apiserver 采用unstructured.UnstructuredJSONScheme 解析出資源的 meta 信息，進(jìn)而更新相應(yīng)的 List 數(shù)據(jù)。

關(guān)于“l(fā)ite-apiserver怎么實(shí)現(xiàn)”這篇文章的內(nèi)容就介紹到這里，感謝各位的閱讀！相信大家對(duì)“l(fā)ite-apiserver怎么實(shí)現(xiàn)”知識(shí)都有一定的了解，大家如果還想學(xué)習(xí)更多知識(shí)，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。

本文名稱：lite-apiserver怎么實(shí)現(xiàn)
文章位置：http://chinadenli.net/article16/jiiidg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供關(guān)鍵詞優(yōu)化、響應(yīng)式網(wǎng)站、商城網(wǎng)站、外貿(mào)網(wǎng)站建設(shè)、標(biāo)簽優(yōu)化、自適應(yīng)網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)