Kubernetes Dashboard Backend Source code analysis

The dashboard architecture consists primarily of an API handler and five manager:
API handler is used to process HTTP requests from customers, different path routes to different handler processing, using the Go-restful library,
Five manager is Clienmanager, AuthManager, Settingmanager, Systembannermanager, Integrationmanager, respectively responsible for authentication, system setup, Cue bars and integration of other component components, and each manager is separate from a package, consisting of the manager and a handler, the manager is responsible for data processing, and handler is used to respond to the respective HTTP request.

client packageAccording to the front-end user request from the Api-server to obtain the corresponding data, each HTTP request will carry the user's authinfo, use this information to create an API server client, to obtain the user's required data, When the system starts, it initializes a insecureclient to do some user-independent requests, such as getting the k8s cluster version, initializing the Heapster component, and so on.
auth packageIncludes all the certification aspects of processing, certification is actually entrusted to K8s Apiserver responsible, dashboard just based on user login information generated Authinfo object, encrypted as token carried in the browser, that is Jwe protocol, Jwe Sub-package is the implementation of the JWE protocol, where Keyholder (Rsakeyholder concrete Class) manages the key pair used by Jwe and stores the secret key in Kubernetes-dashboard-key-holder Secrets object, Synchronize between different dashboard instances in real time,TokenManager(Jwetokenmanager concrete Class) is used to manage tokens, decrypt or generate tokens for authorization, and login in AuthManager Method will obtain the Authinfo information (Authenticator) based on the information returned from the login front page, and then healthcheck determine whether it is legal, and finally use Tokenmanager to generate Jwe token to return to the user. Token's payload is the K8s Authinfo object.
sync packageis used to monitor k8s resources, periodically poll the specified resources, if the resource changes will call the user registered callback function, and responsible for the curd operation of the resource, currently only implements the monitoring secret, The above mentioned Kubernetes-dashboard-key-holder Secrets is synchronized between different dashboard through sync, poll secrets information is responsible for Secretpoller, he is regular get The Secrets object (getsecretevent), which returns different event depending on the situation, is implemented through the Pollwatcher (watch. Interface) Channle is transferred to Secretsynchronizer, and then Secretsynchronizer performs different callback functions based on the event.
In addition, there is a Overwatch object in the sync package that monitors the Synchronizer object registered to it, and its basic implementation is to obtain Synchronizer error information through Channle and restart it based on the restart policy.
Viewing dashboard's deploy file will find that Kubernetes-dashboard-minimal's role resource has been created and bound to the deployment of dashboard. The resourcenames of role is kubernetes-dashboard-key-holder and other objects, all of which need to be set when the system is initialized, which is actually done by the insecureclient above.
setting packageis a basic set of settings, including ClusterName, ItemsPerPage, Autorefreshtimeinterval and other information, stored in the Kubernetes-dashboard-settings this config map, The user can set up the page to update the CONFIGMAP.
systemBanner packageis used to display a banner on the page to remind the user of some information.
integration packageUsed to integrate display of other information, such as heapster monitoring information, each integrated object is called a integration, and has a integration Id corresponding to it, Integrationmanager is actually handed over to Metricmanager to manage integration, Metricmanager will create a corresponding integration for each metricclient to get the data, Heapsterclient is the implementation of the above Metricclient interface, through the heapster provided by the data model to access the information in the Heapster.
Metricsclient some methods, as follows:

string, cachedResources *CachedResources) MetricPromises

This function obtains data from Heapster, but encapsulates the comparison abstraction, where Resourceselector represents a particular request object, such as a request deployment where some deployment metadata are saved. Metricname represents a resource type such as Cpu/memory, cachedresources is used to represent sub-objects of some high-level objects, such as the deployment above, because heapster resources are not monitored directly in deployment, Only the pod is monitored, so the resource usage information for all pods under a deployment is his resource usage information, where cachedresources means that deployment contains those pod arrays, the return value The metricpromises contains two channel, respectively, for obtaining metric data and error data, and provides a getmetrics for obtaining metric data from the channel. (if looking directly at Heapster is still more abstract, it is best to go through the handler of a resource request and see how it is implemented after it is used.)
In some handler, a request for a resource is performed asynchronously, and a groutine is initiated, where the client-go request Api-server is invoked, and then returned to the main thread via the channel, and summarized back to the browser in the main thread.
Resoutce/dataselect for filtering, sorting, paging, etc. of the data obtained

In general, the technical points in Dashborad include but are not limited to: Jwe, AutoGenerate certification, Wathchover, Synchronizer, heapster integration, go-restful, Client-go, csrf ....

Kubernetes Dashboard Backend Source code analysis