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, 利用这些信息创建一个api 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....
