Today, we present the KubeSphere project in three aspects: an overview, a front-end architecture, and a vision for the future.

1

An overview of the

What is KubeSphere Console?

KubeSphere Console is a Web UI management platform for KubeSphere cluster, which provides a visual way to manage K8s cluster resources.

What does KubeSphere Console mean to users?

It helps users quickly view the current operating status of a cluster, such as CPU consumption, memory consumption, and health status of each node. Provides a visual way to help users quickly create K8s resources. Real-time status updates and detailed data presentation make platform resources more transparent to users. Built-in App store to help developers quickly deploy some commonly used apps in the development process.

KubeSphere offers much more than that. This is the current front end of KubeSphere. In addition to the basic resource management functions of K8s, there are DevOps, logging, monitoring, micro-services, gray publishing and other functions.

In terms of project development, as of 2.1.0, KubeSphere Console has experienced 6 major releases, 12 major function points, 3,365 Git Commits, and 11 code contributors. KubeSphere Console is now open source on GitHub.

Why open source? One is to answer the community’s call, and the other is for developers to participate in KubeSphere, which we encourage and welcome. I hope to work with the community to make KubeSphere stronger.

2

The front-end architecture

Next, I’ll introduce you to the front-end architecture of KubeSphere Console. We mainly use front-end Server and Web UI architecture in two parts. Front-end Server is based on Node.js and koa.js development, mainly responsible for API forwarding, login logic control, configuration file writing, etc. The Web side is a standard SPA application.

Why choose front-end Server instead of Nginx hosting like most of the Web?

Front-end Server in the completion of static page hosting, API forwarding functions and the premise, but also can complete other functions. With the front-end Server, the page output from the front-end Server can dynamically inject information, such as configuration files, runtime, configuration code, and user login information, without you in the page, it can be written in advance, the UI loading process is more smooth.

Some logins, like verification codes, login error messages, such as verification codes, are better done on the front end than on the back end. For example, some complex applications need some data. These data are not simply written in JS in the Server, but in the form of API. Using API form can enable us to have better customization ability, which is different in different environments.

Next, I’ll talk about technology at the Web layer, which is divided into four parts: technology stack, component-based UI, state management, and testing.

The technology stack is commonly used with React+ mobx.js. Componentized UIs are data-driven. Why choose this technology stack? Life is too short to do the easiest thing. React+ mobx. js is lightweight and easy to learn in our project, enabling us to focus more on business development.

In the Web UI, we take a componentized approach to building, following principles and design methods. What is a principled design approach? A lot of people know about it, and I’ll give you a brief introduction. For example, the basic tags are the atoms of the UI, and when you put those tags together to form a simple component like a button or something like that, these are molecules, and we add business logic on top of those molecules, and we recombine those things to form templates, add data to form pages.

KubeSphere Console implements a set of technical components and some more complex business components. Like our styles, buttons, and container forms, these are componentized practices in KubeSphere. This is the function of the group to increase our development cycle.

This is the container group business component, which is characterized by high cohesion and low coupling. It just needs a labelSelector to filter it. After filtering, you can output associations, data, and container information in Porter, as well as related monitoring data, listen to Websockets, and refresh the list in real time. Such components can be deployed in many places with replica sets that are easily and easily reused.

What is state management?

Unify state management between components and pages. Why do you want this state management? The state of the application affects the distribution across many components, and in large applications, this distribution can make your business logic look messy. Specialized management makes the flow of data clear and makes the data business logic easier to reuse. KubeSphere Console is divided into four layers of state management, global UI management in the global Store, Websocket instances, routing instances, etc.

Module management, which is initialized when a module enters and destroyed when it exits. In front of KubeSphere Console, we split the business into DevOps, projects, enterprise space, etc., and state management is loaded individually as each module comes in. Hierarchical design can make the page data flow more clear, design cycle is simpler.

Next, KubeSphere Console is tested.

Why are there tests? Testing is the guarantee of functional interaction techniques. For unit testing, we use the Jest+Enzyme framework to ensure that technical components and business components function properly. We focused on testing boundary cases and covering related Bug Reports. Then there is end-to-end testing, the main purpose of which is to ensure that UI functional interactions and presentation effects work. In the end-to-end test, we interact with the real client, which can ensure the normal function of the whole business plate.

3

Looking forward to

Let’s take a look at the future of KubeSphere Console. How will KubeSphere Console grow? We considered three aspects: scalability, monitoring, and business abstraction.

What is scalability? Simply put, it is plug-in, why do it. As business functions continue to grow, whether front-end or back-end, the size of your code or your application will become enormous. The transformation of differentiation should keep core modules and core business. Other business functions are loaded as plug-ins to ensure that the main function is lightweight enough. Different users can customize their own plug-ins for their specific business scenarios. At deployment time, the entire system appears to have fewer redundant functional barriers.

Front-end page monitoring system, why do such a function? Because we found many users in the actual front-end page running scenarios often occur some errors, we are difficult to help solve the recurrence. The monitoring system can help record the occurrence of errors and make it easier for us to Debug. It mainly includes abnormal monitoring, resource request monitoring and page loading performance monitoring, and uploads monitoring information and error information to a specific server. There is a special place to control the front-end abnormal feedback, which is easier to help us Debug.

Next comes business abstraction. We learned that many users were not familiar with the basic concepts of K8s, such as Pods or Workload controllers, Depolyment, StatfulSet, etc., and did not know how to make choices. With this in mind, we are going to create a layer of abstraction for the underlying resources in KubeSphere Console, so that some users don’t have to know exactly what the underlying resources are using, but what resources it needs. The user needs a service, makes some configuration choices, and we decide what the underlying resource implementation is. This will make It easier for some users to use KubeSphere.

Scan the code to see the KubeSphere project