By Sun Jianbo (Tianyuan)
This article is a summary of the live broadcast about Open-Source GO: KubeVela, by Sun Jianbo (Tianyuan) from the Cloud-Native Application Platform Team of Alibaba Cloud, and one of the core designers of KubeVela. In the video, Sun Jianbo shared some stories, design ideas, and usage methods of open-source projects, focusing on KubeVela.
KubeVela is an open-source project based on Go and designed for cloud-native platforms. This project was officially released in November 2020. KubeVela is the core dependency of the unified cloud-native application platform kernel of Alibaba. KubeVela has been running in multiple Alibaba products for a long time, even though it was released publically two months ago. Currently, I am deeply involved in the kernel development of these products and projects. This kernel system was developed from the Kubernetes-based implementation of the Open Application Model (OAM), which was launched by Alibaba Cloud and Microsoft at the end of 2019. During the continuous evolution and iteration, OAM received a lot of feedback and contributions from the open-source community, especially from community members of Microsoft, ByteDance, 4Paradigm, Tencent, and Full Truck Alliance. In 2020, this kernel system was released in the open-source community as "Kubevela" at KubeCon NA. The KubeVela project has received continuous attention from the entire cloud-native ecosystem since its release. On the fourth day after its release, KubeVela ranked first in the open-source trend list of the Go language.
Figure 1: Rapid Growth of KubeVela GitHub Star
KubeVela is a platform developer-oriented, easy-to-use, and highly scalable build engine for cloud-native platforms.
KubeVela aims to enable any platform team to build a cloud-native platform quickly and efficiently in a Kubernetes-native manner. The platform applies to different business scenarios and directly faces users. This kind of platform includes application PaaS, database PaaS, AI PaaS, and continuous delivery systems.
Figure 2: The Workflow of "Concern Separation" in KubeVela
In terms of design, KubeVela exposes two core APIs to the Platform Team:
Users of the platform, such as business teams, can initialize their expected deployment clusters in one click with the environment template provided by the Platform Team. Then, they can assemble the capability templates as a complete application for direct application delivery and O&M in any Kubernetes cluster.
These capabilities and environments are abstracted through templates, so business teams don't have to learn the whole concepts and details of Kubernetes. After understanding the parameters exposed in the templates, business teams can use Kubernetes to do their job. The Platform Team has full control over the configuration items exposed by the templates, rendering way of templates, and rendering results of Kubernetes objects. These items, ways, and results can be adjusted and modified at any time.
The workflow above combines "the capability template provided by the Platform Team" with "the application declaration through templates assembled by the Business Team." This is also the embodiment of the "concern separation" idea advocated in OAM. In terms of specific template support, KubeVela supports the open-source CUELang template language of Google. In the future, KubeVela will directly support the Helm Chart packet.
After learning the background of KubeVela, let's talk about what KubeVela can do as a platform builder?
Building "abstractions" is the most basic and inevitable function of any cloud-native platform.
We know that Kubernetes exposes a set of declarative APIs. Abstractions are operational and configurable items for users, which are exposed by the platform based on the declarative APIs. For a Platform Team, the ultimate goal of providing "abstraction" is to simplify the usage and help the Business Team focus on important things. The "abstraction" needs to avoid the introduction of a large number of platform-layer details unrelated to the business, which may deter users from using the platform. Providing "abstractions" is the first step for any Platform Team to implement system-level and open-source projects, such as Kubernetes.
The most common abstraction method in the industry is to provide a graphical interface for users, such as a Console or a Dashboard. These interfaces only allow users to fill in specific field parameters to simplify the usage. The following figure shows the Console of an open-source Kubernetes PaaS project.
Figure 3: The Console of an Open-Source Kubernetes PaaS Project
Some other projects, such as Racher Rio provide a command line tool for users. The tool is similar to a graphical interface in functions, except that the parameters that can be specified are replaced by Command Line Interface (CLI) parameters.
For teams with higher technical levels, they will develop the upper-layer Custom Resource Definition (CRD) and Operator as "abstractions" based on Kubernetes. For example, Knative is an abstraction for Serverless scenarios. Pinterest has an Application CRD abstraction.
As the Platform Team, how do we determine the configurable parameters to be exposed to users? This involves the three basic modes of "abstractions." The more complex modes are the further combinations of the three modes listed below:
Figure 4: Common Abstraction Mode
These abstract modes are involved in many platform-level projects and products across the industry. However, it is very challenging to design abstraction and ensure that the abstraction can meet the usage requirements and habits of business users. The key point is that it is arduous to modify the "abstraction" for both the graphical interface and the CRD Operator once it is released. However, the requirements of users on the business side cannot remain unchanged. The requirements change rapidly and greatly.
As the Alibaba Platform Team, we have also encountered the challenge of designing "abstractions" while practicing the cloud-native application infrastructure on a large scale. After many attempts and summaries, we worked with the R&D Efficiency Team and finally chose the technology combination of GitOps and Infrastructure as Code (IaC) to solve this problem.
GitOps is more about the innovation of the delivery pipeline, while IaC aims to solve the "abstraction" problem. Specifically, the definition of "abstraction" in IaC is expressed through a "template." This means that an "abstraction" does not require complex server-side programming, such as CRD Operator. As a Platform Team, we only need to submit one template, and then the user "automatically" obtains abstracted fields. If we want to modify these abstracted fields, we only need to update the corresponding template, and the abstraction on the user side will change "automatically." The adjustment and update of this abstraction mode do not require any recompilation or launch, so we call this mode "client abstraction."
Figure 5: Relationships among Users, Abstractions, Templates, and Original Kubernetes APIs
In the specific implementation, Alibaba defines abstraction templates through CUELang, the template language developed by Google. This is why the CUE-based abstraction mechanism was first made open-source by KubeVela. The Platform Team can register (kubectl apply) the CUE template in the Kubernetes cluster according to the OAM specification. The OAM specification refers to WorkloadDefinition and TraitDefinition objects. Business users can use this abstraction immediately. The usage will be described in further detail later.
Google and Alibaba favor CUE because it provides comprehensive abstraction-layer implementation capabilities. For example, we have summarized the three modes of abstractions where "conversion abstraction" and "composition abstraction" can be performed easily when rendering template. They just change the field name and the generated content becomes multiple objects. However, splitting abstraction is difficult, involving the independent execution of capabilities after splitting and the patch-merge of the two capabilities.
The splitting is relatively simple with KubeVela. Take the definition process of decoupling business containers from Sidecar containers as an example. We want to split "defining business containers" and "defining Sidecar containers" into two different forms on the user side. First, the Platform Team only needs to register a WorkloadDefinition object (called worker) that carries the Deployment template of the business container. Then, the team registers a TraitDefinition object (called sidecar) only carrying the template of the Sidecar container. By doing so, KubeVela exposes two independent configuration items of the worker and sidecar to the user side. This allows users to specify the business container parameters in the worker during deployment. O&M can independently specify the sidecar configuration parameters during subsequent O&M without any modifications to users' worker parameters.
Figure 6: An Example of "Splitting" Kubernetes APIs by KubeVela
In addition to CUE, the abstraction mechanism above can also be implemented through Helm and seamlessly integrated with the GitOps pipeline. This function will be released as the next important KubeVela feature. We will share some cases and best practices about building a continuous delivery system based on KubeVela.
With the "abstractions" mentioned above, business teams can use these abstractions to deliver and manage applications. At this stage, KubeVela does not make any constraints. On the contrary, its goal is to display abstractions directly on the user interface (UI). In this way, after the platform team adjusts these abstractions, business users can immediately use the latest abstractions without making any updates or upgrades to the system.
In concrete execution, KubeVela automatically generates a JSON schema for the abstractions above. This JSON schema contains the list and types of parameters that the abstractions allow users to use. Therefore, users can use the JSON schema with a graphical interface or other UI to render the user form and generate the usage document. This is how the built-in Capability Usage Document of KubeVela is generated. In the preceding example where the Sidecar container definition is decoupled, KubeVela exposes two JSON schemas to users. One defines the parameter list of the business container, and the other defines the parameter list of the sidecar container. They can be rendered into two separate forms for users in the frontend.
The mechanism of IaC abstraction and automatic Schema generation mentioned above makes it simple and highly scalable to build user-oriented UI based on KubeVela. As long as the template behind these abstractions is modified by the platform administrator, new abstractions can be available immediately. No system upgrade or relaunch is required.
KubeVela has a simplified built-in graphical interface called Appfile. It displays the above schemas of abstractions in YAML, allowing users to modify and configure. The following example shows the process of transforming each "capability abstraction," such as route and autoscaler, into configurable items in the Appfile.
Figure 7: Use the Abstractions of KubeVela in Appfile
Figure 8: Use Vela Traits to View the Registered Capabilities
Figure 9: Use Vela Show to View Usage Documents of Capabilities (Automatically Generated)
Currently, Appfile is the main built-in UI of KubeVela that uses "abstraction." Besides, Dashboard and Restful APIs with the same mechanism will be released in the second quarter of 2021 in KubeVela. Thus, users can define and use this abstraction mechanism through a graphical interface and an API.
As the native platform build engine for Kubernetes, the abstraction mechanism of KubeVela and Appfile mentioned above are both implemented in Kubernetes through declarative APIs. The CRD corresponding to the Appfile is called an Application object. The Platform Team registers abstraction templates through Definition CRD, while users of the platform use the abstraction templates through Application CRD. The whole mechanism runs as a Kubernetes plug-in, providing the most native integration and scalability.
The mechanism of Definition and Application is the core of the OAM specification. With this mechanism, KubeVela can integrate more capability providers, such as Terraform, with unified APIs and the same user experience. Terraform is a well-known tool in the industry for creating cloud resources. Its rich ecosystem covers most cloud resources of all mainstream cloud vendors and is the best supplement to the insufficient management capabilities of Kubernetes cloud resources.
In KubeVela, it is very simple to define and pull up cloud resources using Terraform, as shown in the following figure:
Figure 10: KubeVela Uses Terraform to Pull up Cloud Resources
The Platform Team defines a WorkloadDefinition object named "aliyun-rds" and the Terraform-based template of Alibaba Cloud RDS cloud resources. In the above example, the Terraform configuration is also written through CUE. Terraform cloud resources can be described in JSON format, and CUE is a superset of JSON. Therefore, all Terraform capabilities can be used naturally. Moreover, we are also planning to use Terraform HCL syntax as another template language for KubeVela. In the CUE template, we reference Alibaba Cloud RDS definitions and abstract them into a small number of user fields (parameters), such as user and password.
Users only need to fill in Appfile with a new Service named sample-db. Its type is what we defined above, aliyun-rds. Then, users can define the user, password, and other parameters provided in the template.
Users can also define data binding in the express-server business application. Users can also add the configuration named sample-db and enter names of mapped environment variables.
After that, users only need to use the vela up command. KubeVela will pull up the business container and automatically transfer the link information returned by the Terraform-based Alibaba Cloud RDS to the business container. We can see that the application has started successfully in the last part of the figure above, and the connection information of the database is obtained. The data transmission and orchestration in this process are also the core built-in capabilities of KubeVela.
KubeVela is the first build engine for cloud-native platforms and the complete implementation of the OAM model in Kubernetes. The capabilities provided by KubeVela for platform builders are far more than those mentioned above. These capabilities include the unified application gray framework (will be open-source soon), multi-cluster and multi-environment component delivery, and lifecycle management of CRD Controller. They all are core features that KubeVela aims to build. Due to space limitations, we will not introduce these capabilities in detail. Everyone is welcome to use KubeVela, provide feedback, and learn more about the KubeVela community.
KubeVela is a project built by the community. In the early stage of the project, 38 contributors from dozens of different companies participated in the development. The KubeVela community is very open, and there are a lot of new KubeVela features in various planning and implementing stages. Everyone is welcome to contribute, use, and give feedback.
If you want to understand KubeVela better, you can go to the KubeVela Official Website for specific examples and the manual. If you are experienced in open-source projects, you can try to add plug-ins from the open-source community to KubeVela (blog in Chinese). You may have some wonderful ideas for expanding KubeVela, such as developing a cloud-native database PaaS or AI PaaS based on KubeVela. If so, you are welcome to discuss your ideas in the OAM community.
Guidelines for Transforming from a Monolithic Architecture to a Serverless Architecture
Configure a New Capability for Kubernetes PaaS in 20 Minutes
481 posts | 48 followers
FollowAlibaba Cloud Native Community - January 27, 2022
Alibaba Cloud Native Community - November 11, 2022
Alibaba Cloud Native Community - December 23, 2021
Alibaba Cloud Native Community - March 8, 2023
Alibaba Cloud Native Community - July 12, 2022
Alibaba Cloud Native Community - September 16, 2022
481 posts | 48 followers
Follow
Managed Service for Prometheus
Multi-source metrics are aggregated to monitor the status of your business and services in real time.
Learn More
Alibaba Cloud Flow
An enterprise-level continuous delivery tool.
Learn More
DevOps Solution
Accelerate software development and delivery by integrating DevOps with the cloud
Learn More
Cloud-Native Applications Management Solution
Accelerate and secure the development, deployment, and management of containerized applications cost-effectively.
Learn MoreMore Posts by Alibaba Cloud Native Community
