Architecture

Kubernetes Dashboard project consists of two main components. They are called here the frontend and the backend.

The backend runs in a Kubernetes cluster as a Kubernetes service. Alternatively, it may run anywhere outside of the cluster, given that it can connect to the master. The backend is an HTTP server that proxies data requests to appropriate remote backends (e.g., Kubernetes API) or implements business logic. The backend implements business logic when remote backends APIs do not support required use case directly, e.g., “get a list of pods with their CPU usage metric timeline”. The figure below outlines the architecture of the project:

The rationale for having a backend that implements business logic:

• Clear separation between the presentation layer (frontend) and business logic layer (backend). This is because every action goes through well-defined API.
• Transactional actions are easier to implement on the backend than on the frontend. Examples of such actions: “create a replication controller and a service for it” or “do a rolling update”.
• Speed: getting composite data from backends is faster on the backend (if it runs close to the data sources). For example, getting a list of pods with their CPU utilization timeline requires at least two requests. Doing them on the backend shortens RTT.

• Written in Golang.
• Code and tests are stored in src/app/backend directory. Test file names start the same as sources, but they are with .
• Every API call hits apihandler.go which implements a series of handler functions to pass the results to resource-specific handlers.

Frontend

• Written in TypeScript.
• Using along with Angular Material for components like cards, buttons etc.
• Using .
• Code and the tests are stored in directory. Test file names start the same as sources, but they are with .spec.ts.