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一些方法,以下:

DownloadMetric(selectors []ResourceSelector, metricName string, cachedResources *CachedResources) MetricPromises

這個函數從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....