kubernetes dashboard backend源码剖析
dashboard架構主要由一個API handler 和 五個manager構成:
API handler用來處理來自客戶的http請求,不同的path路由到不同的的handler處理,使用的是go-restful庫,
五個manager是ClienManager, AuthManager, SettingManager, SystemBannerManager, IntegrationManager, 分別負責認證,系統設置, 提示條和集成其他組件,并且每個manager獨立于一個package中, 由manager和handler兩部分組成, manager負責數據處理, handler用來響應各自負責的http request.
client package 根據前端用戶請求從api-server獲取相應數據, 每個http request中都會攜帶用戶的authinfo, 用于創建a對應的pi server client, 獲取用戶所需數據, 系統啟動時會初始化一個insecureClient用來做一些用戶無關的請求,例如獲取k8s集群版本,初始化heapster組件等.
auth package中包括所有的認證方面的處理,認證其實是交給K8S apiServer負責的,dashboard只是根據用戶登錄信息生成authInfo對象,加密后作為token攜帶在瀏覽器中, 即jwe協議, jwe子包是JWE協議的實現, 其中KeyHolder(rsaKeyHolder concrete class)用來管理jwe用到的密鑰對, 將秘鑰存放在kubernetes-dashboard-key-holder secrets對象中, 實時在不同dashboard實例間同步,TokenManager(jweTokenManager concrete class)用來管理token, 根據秘鑰解密或生成token來進行權限驗證, authManager 中的login method會根據login前端頁面返回的信息獲取到authInfo信息(Authenticator),然后healthCheck判斷是否合法,最后利用tokenManager生成jwe token返回給用戶,token的payload保存的就是k8s AuthInfo對象.
sync package 是用來監視k8s資源,會定期poll指定的資源,如果資源發生變化會調用用戶注冊的回調函數,并且負責對資源的CURD操作, 目前只實現了監控secret, 上面提到的kubernetes-dashboard-key-holder secrets就是通過sync在不同dashboard間同步, poll secrets信息由SecretPoller負責, 他是會定期Get secrets對象(getSecretEvent),根據不同情況返回不同的Event,通過PollWatcher(實現了watch.Interface)中的channle傳輸到secretSynchronizer中,然后secretSynchronizer根據Event執行不同的回調函數.
此外sync package中有個Overwatch對象用來監視注冊到其中的synchronizer對象,它的基本實現就是通過channle來獲取synchronizer的錯誤信息, 然后根據重啟策略進行重啟.
查看dashboard的deploy文件會發現創建了kubernetes-dashboard-minimal的Role資源并綁定到了dashboard這個deployment上, Role的resourceNames為kubernetes-dashboard-key-holder及其他對象,這些對象都需要在系統初始化的時候設置完畢, 其實就是由上面的insecureClient進行的
setting package是一些基本的設置,包括ClusterName, ItemsPerPage, AutoRefreshTimeInterval 等信息,保存在kubernetes-dashboard-settings 這個config map中,用戶可以通過頁面來設置,更新這個configMap.
systemBanner package是用來在頁面上顯示一條banner, 用來提醒用戶一些信息的.
integration package用來集成顯示其他信息,例如heapster的監控信息, 每個被集成的對象被稱為一個integration, 并有一個integration Id 與之對應, integrationManager其實是交給metricManager來管理integration的, metricManager會為每個integration創建一個對應的MetricClient獲取數據, heapsterClient就是實現了上述MetricClient接口, 通過heapster提供的data model來訪問heapster內的數據.
metricsClient一些方法,如下:
這個函數從heapster獲取數據,但是封裝的比較抽象, 其中ResourceSelector表示某個特定的請求對象,例如請求deployment則其中保存了一些deployment metadata. metricName表示cpu/memory等資源類型, CachedResources用來表示一些高級對象的子對象,例如上面的deployment,因為在heapster沒有直接對deployment資源的監控,只有對pod的監控, 所以一個deployment下所有pod的資源使用信息之和就是他的資源使用信息, 此處cachedResources就表示deployment中包含那些pod數組,返回值 MetricPromises包含兩個Channel,分別用于獲取metric數據和error數據,同時提供了一個GetMetrics用于從channel中獲取metric數據.(如果直接看heapster還是比較抽象的,最好從一個資源請求的handler中進去,明白其如何使用之后在看其實現.)
在某些handler中對資源的請求是異步進行的,會啟動一個groutine,在其中調用client-go請求api-server,然后再通過channel返回到主線程中,在主線程中進行匯總返回給瀏覽器.
resoutce/dataselect用于對獲取的數據進行過濾,排序,分頁等
總的來說dashborad中的技術點包括但不限于: jwe, autogenerate certification, wathchover, synchronizer, heapster integration, go-restful, client-go, csrf....
轉載于:https://www.cnblogs.com/gaorong/p/8576168.html
總結
以上是生活随笔為你收集整理的kubernetes dashboard backend源码剖析的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 英佩臻游联手发力《全球使命VR》突显未来
- 下一篇: 4-曲线拐点模型分析