Author: Zeng Qingguo (Yueda)

KubeVela 1.5 was officially released recently. This version brings more out-of-the-box application delivery capabilities to the community, including new system observables; new Cloud Shell terminal, moved Vela CLI to the browser; enhanced canary release; optimization Multi-environment application delivery workflow, etc. It further enhances and polishes KubeVela’s highly scalable experience as an application delivery platform. In addition, the community has officially started to promote the project to the CNCF Incubation stage, and at the same time listened to the practice sharing of several community benchmark users in multiple community meetings, which also proves the healthy development of the community. The maturity and adoption of the project have achieved phased results. This is thanks to the contributions of over 200 developers in the community.

KubeVela has released five major releases in the past year, and each iteration is a leap forward. The release of 1.1 brings the ability to connect multiple clusters, 1.2/1.3 brings an extended system and a more friendly developer experience, and 1.4 introduces a full-link security mechanism. Today’s 1.5 release brings us one step closer to KubeVela’s vision of “making application delivery and management easier”. Along the way, we have always followed the same design concept, built a platform that automatically handles the complexity of the underlying differentiated infrastructure without losing scalability, and helped application developers to upgrade from business development to cloud-native R&D at low cost. Technically, it focuses on the complete link from code to cloud, from application delivery to management, based on the Open Application Model (OAM) to refine the framework ability to connect the infrastructure. As shown in Figure 1, today’s KubeVela has covered the capabilities of application definition, delivery, operation and maintenance, and management of the entire link, and all these capabilities are based on OAM’s scalability (ie OAM Definition) plug-in connection to ecological projects accomplish.In essence, each Definition transforms the experience of using a specific capability into a reusable best practice module, which is packaged by plug-ins to achieve enterprise sharing or community sharing.

Figure 1 The core structure of KubeVela scalability

The blooming of atomic capabilities in the cloud native field is not only a valuable asset, but also raises the threshold for practitioners. Platform builders need to learn a large number of open source projects and aggregate experience in multiple fields. It often takes months or even longer to build an enterprise cloud-native support platform. Often, however, platforms are built that pass the complexity directly to the application developer, who also has to learn a lot of additional knowledge. KubeVela’s design concept and existing technical achievements may help you quickly enter the cloud-native world.The plug-in integration specification and unified application delivery experience that KubeVela focused on in version 1.5 and previous versions has effectively solved the problem of discrete atomic capabilities in the cloud native field.

Plug-in specification upgrade, more flexible definition method

Since the release of version 1.2 of KubeVela plugin mechanism, it has been widely loved by community users, and there are nearly 50 plugins in the community plugin repository. Nearly 50 developers have contributed to the plugin.

See:

https://github.com/kubevela/catalog

Starting from version 1.5, plugin developers can get a better experience. From plug-in definition, distribution to visual management have been comprehensively improved. In addition to using YAML to define plug-ins, developers can completely use CUE to define plug-ins if they want more flexible combination of resources included in plug-ins and more advanced parameter control. The current plug-in definition specification includes the following parts:

• template.cue or template.yaml combined with the resources directory to define the plugin’s runtime, such as extending a workload that needs to run behind an Operator, etc. This part is not necessary, for example some lightweight plugins can have no underlying runtime or reuse other runtimes. Most demand scenarios can be covered by the combination of YAML and CUE configuration.

• The definitions directory stores Definition definitions, which are the core part of the plug-in and define how the extended capabilities of the plug-in can be used by users.

• The schema directory is used to assist Definition and define custom rendering rules for related Definitions on the UI side.

• The views directory, which stores VelaQL syntax definitions, is used to extend VelaQL’s query capabilities.

• metadata.yaml and readme.md, plugin metadata definition files, describe the basic information and environment requirements of the plugin.

For specific specifications, see the documentation: http://kubevela.net/en/docs/platform-engineers/addon/intro

Here is an example of integrating the Helm Chart package delivery capability. Currently, projects like FluxCD or ArgoCD in the community provide the atomic capability of deploying Chart packages. Their implementation methods are different, and each has its own advantages. Then for KubeVela users, these two projects can be introduced through plugins. As shown in Figure 2, we need to define a standard API for end users, and expose necessary parameters to end users according to the actual situation of the enterprise.

Figure 2 The process of KubeVela extending the Helm Chart package

As shown in Figure 3, according to the standard API, the front-end UI can automatically generate the corresponding interactive page to help the end user complete the Helm Chart package deployment conveniently and simply. The platform side automatically generates the driver configuration of the underlying capabilities according to the user’s input parameters and plug-in definitions, and intelligently obtains relevant status feedback to the user. These are described based on plug-in specifications, such as integrating FluxCD. This project includes multiple controllers to provide different atomic capabilities. First, we define the deployment method of FluxCD through template.cue, and select and deploy different components based on different parameter inputs. . The user experience is then defined through the definitions and schema directories.

Detailed reference: https://github.com/kubevela/catalog/tree/master/addons/fluxcd

Figure 3 Interaction of KubeVela delivering Helm Chart package

Function Interpretation Based on Plug-in Extension

Telemetry integrated Prometheus + Grafana + Exporters support system observable

The application observable system is closely related to the application release. A good application observable system can make application reliability management easier.KubeVela community includes application observable as core feature. In version 1.5, the community first selected the observability of the KubeVela system itself as a case to develop system capabilities. The following points have been implemented so far:

1. The multi-cluster observable infrastructure is installed through one-click plug-ins. We first formed an observable plug-in set around the solution of Prometheus + Grafana + Exporters. Easy installation of basic capabilities for different basic environments.

2. Support one-click to open multi-cluster Metrics data aggregation, and use Thanos Query scheme to achieve multi-cluster metric aggregation query and visualization. A similar scheme will gradually cover the Logger and Tracing dimensions.

3. Grafana IaCization. The Grafana data source, large disk and other configurations are described through the application model, and the Grafana API can be transformed into a runtime that can be operated by KubeVela by innovatively using the extension API.

4. Grafana dashboards are automatically generated, and users can automatically generate KubeVela’s system observable dashboards by enabling the Grafana plug-in.

Figure 4 shows the broad market of the KubeVela system operating indicators. The market is automatically generated through the IaC system, and the user only needs to enable the corresponding plug-in.

Figure 4 KubeVela system observable market

Figure 5 shows the monitoring dashboard of the Kubernetes API Sserver service connected to KubeVela. The exporter is delivered to all subclusters through the plug-in, and the data is exposed to the Prometheus service of each cluster, and then aggregated to the management and control cluster for centralized visualization. Take one time to complete the monitoring data and large disk access of N clusters.

Figure 5 KubeVela multi-cluster API observation panel

In future releases, the community will gradually integrate the unified description and delivery of application observables into the application delivery process. Covers data acquisition, intermediate processing and transmission, storage and analysis, alarming and visualization of Metric, Logger and Tracing, as well as the entire chain of application publishing pipelines.

Reference documentation: http://kubevela.net/docs/platform-engineers/operations/observability

Integrate Cloud Shell to achieve CLI & UI collaborative application delivery

The advantages of controlling application delivery through the CLI black screen are convenience, batch size and easy replication, which developers especially like. It is more elegant to deliver application interaction through UI, and the process operation is conducive to reducing learning costs and achieving stricter enterprise security control. With a high degree of visualization, you can better grasp the application and perform related operations anytime, anywhere. In the past versions, KubeVela had big differences in the two dimensions of CLI and UI, and the data did not communicate with each other. If the two terminal methods can be effectively combined, application delivery and management will be smoother. In version 1.5, KubeVela introduced the CloudShell plug-in, which provides a Web Shell terminal for UI users. The unified entrance solves the problem of separation between CLI and UI, and brings more capabilities. The main changes to this process are as follows:

1. Out-of-the-box toolset; Unlike other platforms, it mainly provides Web Shell capability to enter the application runtime space. CloudShell generates a terminal environment for each user, including CLI tools such as Vela and Kubectl, and can manage multiple applications in the same environment.

2. Autocomplete authorization;Users don’t need to care about how to assign KubeConfig, the system automatically completes the authorization of the black screen environment according to the permissions possessed by the UI user, which realizes the consistency of the basic white screen and black screen permissions.

3. Environmental automatic recycling; The longest survival time of each user’s terminal environment is 1 hour, and it will be automatically recycled after expiration to prevent excessive resource consumption.

4. Enhanced Vela CLI capabilities;Reimplemented log, status, exec, port-forward and other operation commands for Debug applications, and achieved seamless compatibility for differentiated workloads under the application, allowing users to complete related operations without perception. Whether it’s a basic Deployment resource, a Helm-packaged workload resource set, or a custom Operator-driven workload. Vela can automatically discover the underlying operation objects related to the command.

5. Automatic data synchronization; The CLI can create an update application, and the changes are visualized on the synchronized UI until the user chooses to take over the application and subsequent releases through the UI.

Figure 6 KubeVela ClouShell operating terminal

Integrate OpenKruise Rollout to provide canary release capabilities

The Rollout project was incubated by the KubeVela community at an early stage. Similar to the implementation model of Argo Rollout, it works in the form of a new workload and mainly realizes the ability to release in batches. With the development of the community, KubeVela focuses more on the application of the global control layer and plug-in expansion capabilities. Therefore, the implementation of Rollout at the workload level has been transferred to the OpenKruise community. With the joint efforts of both parties, the canary release capability for various workloads such as native Deployment, StatefulSet and OpenKruise-extended workload CloneSet has been realized. At the same time, when coexisting with the Helm delivery mode in KubeVela, canary release can be achieved for Helm Chart package applications without any changes, which is innovative in the industry and very convenient for users. Kruise Rollout is integrated into the KubeVela ecosystem as a plugin. KubeVela users only need to enable the plugin to configure Rollout Trait in the application component. At the same time, it can cooperate with gateway rules such as Gateway and HTTPRoute of components. In summary, this implementation has the following advantages:

1. No intrusion, no binding;Introduce the Rollout capability by bypass, users do not need to make other changes to the existing application configuration, the introduction cost is low, and it can be removed at any time;

2. easy to use; Only need to simply configure traffic switching rules, combined with KubeVela’s UI visualization, you can effectively observe the changes in the number of copies in the Rollout process and the relationship between additional resources introduced;

3. good compatibility; No matter what workload the user uses to wrap (Helm or a custom operator), Rollout can find the underlying workload resource and work in a bypass mode.

Reference documentation: http://kubevela.net/docs/end-user/traits/rollout

VelaUX adds multi-environment differentiated visualization configuration

VelaUX has multi-environment deployment capabilities since its launch. Until version 1.5, it supports the differentiation of users’ visual editing in multiple environments, thus truly matching the needs of users for multi-environment application release. Users can add Override Policy configuration, which can differentiate multiple dimensions of environment, cluster or Namespace. Unified management of application base configuration and differentiated configuration.

As shown in Figure 7, the application policy Policy has built-in various options, including differentiated configuration; application of multi-cluster strategy; application of maintenance strategy and GC strategy, and so on. Through the guidance of the UI, it is convenient for users to configure corresponding policies as needed.

Figure 7 KubeVela Policy Add/Edit Window

In version 1.5, the following convenient functions have been added before and after deployment for different environments:

• DryRun (trial run) capability;Users can choose to perform DryRun before deploying an environment, and evaluate whether the application configuration meets the expectations through the results of UI feedback, so as to prevent the wrong configuration from affecting the stability of online services after deployment.

• Environmental Difference Insights; When switching to a different environment view, the local configuration and the deployment configuration are automatically compared. If there is a difference, the user will be prompted and the different configuration items will be displayed. Prevent configuration drift or configuration that is planned to go online forgetting to go online.

• Version details query and difference comparison; Through the version management page, you can view the rendering results of the application configuration of each version, and you can also compare the version configuration with the current running configuration or the latest local configuration. It is convenient for users to track the configuration change process.

Reference documentation: http://kubevela.net/docs/tutorials/multi-env

Application Engine Capability Improvement

In addition to the above-mentioned improvements in plug-in capabilities, a large number of updates have also been made in the application engine. Among them, the performance optimization has improved significantly, and the CPU consumption during workflow execution is reduced by 75%. The number of parallel executions increases significantly. The following important changes are listed below:

1. Workflow adds a new timeout control, configure the timeout time in the Workflow step, when the execution time is greater than the timeout time, the Workflow will end and become terminated.

2. Workflow adds a new conditional judgment, configure the If field in the Workflow step, and support reading data from status or input for judgment to determine whether the current step needs to be executed. It also supports the If Always mechanism, which supports scenarios where some steps need to be executed under any circumstances.

3. Workflow supports display switching mode, supports DAG or default StepByStep.

4. Added shared resource policy, different applications can describe the same resource, such as namespace or ConfigMap, if it is set to shared resource, there will be no conflict.

5. Optimized the application resource tree construction algorithm, improved the query efficiency in different scenarios, made it easier to expand custom rules, and added some default rules.

For more changes, please refer to: https://github.com/kubevela/kubevela/releases/tag/v1.5.0

Epilogue

Overall, with the release of version 1.5, KubeVela has made significant progress in product capabilities, community ecology, benchmark users and other dimensions. User cases include finance, intelligent manufacturing, Internet and other industries. We also look forward to more users sharing your practical experience to help the KubeVela community find a more accurate way forward. In the 1.6 version plan, it will bring more complete application observability capabilities; application-independent workflow capabilities, continuous release control of multiple applications and collaboration with observable systems. Developers with relevant needs and ideas can participate in community discussions at any time.

You can learn more details about KubeVela and the OAM project through the following materials:

• Project Repository: github.com/oam-dev/kubevela Welcome to Star/Watch/Fork!

• Project official homepage and documentation: kubevela.io has provided Chinese and English documents since version 1.1, and developers are welcome to translate more language documents.

Click here: Check out the official website of the KubeVela project!