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

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....浏览器

相关文章
相关标签/搜索