Shulou(Shulou.com)05/31 Report--

This article introduces the relevant knowledge of "what are the differences between KubeVela and PaaS". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

First of all, let's come to the conclusion that KubeVela can bring users an experience very close to PaaS, but KubeVela is not PaaS.

Why is KubeVela not PaaS?

Most PaaS can provide complete application lifecycle management functions, but also focus on providing a simple and friendly user experience, as well as the improvement of R & D performance. At these points, KubeVela's goals and user experience are highly consistent with those of PaaS. But if you study the implementation details of KubeVela, it is not difficult to find that the overall design and implementation of KubeVela is actually very different from all kinds of PaaS projects. From the user's point of view, these differences are directly reflected in the "scalability" of the entire project.

Furthermore, the user experience of PaaS is good, but it is often not scalable. We can look directly at the relatively new Kubernetes PaaS, such as the Rancher Rio project. This project provides a good application deployment experience, such as Rio run to allow you to quickly deploy a containerized application, automatically assign domain names and access rules, and so on. But what if we want Rio to support more capabilities to meet different user demands?

For example:

Can you help me run a scheduled task?

Could you run a CloneSet workload of OpenKruise for me?

Could you run a MySQL Operator for me?

Can I expand the capacity horizontally according to my custom metrics?

Can you do progressive grayscale publishing for me based on Flagger and Istio?

Can you.

The key point here is that these capabilities are very common in the Kubernetes ecosystem, and some are even supported by Kubernetes built-in. But when it comes to PaaS, to support any of these capabilities, you have to do a round of development of PaaS, and because of some previous assumptions and designs, you may even need large-scale refactoring.

For example, I have a PaaS system, all its applications are executed through Deployment, then the PaaS release, expansion and other functions will be directly implemented in accordance with Deployment. But now, the user has put forward the request of upgrading in place, need to let this PaaS support CloneSet again, that whole system is likely to have to turn over and start all over again. When it comes to the operation and maintenance capability, this problem will be even more serious. For example, now that the PaaS supports blue-green publishing strategy, it needs a lot of interaction and integration with traffic management, monitoring system and other dependencies. Now that we're going to get PaaS to support a new strategy called Canary release, all this interaction and execution logic will basically have to be restructured, and the workload is huge.

Of course, not all PaaS is completely non-extensible. PaaS with strong engineering capabilities, such as Cloud Foundry and Heroku, provide their own plug-in capabilities and plug-in centers, opening certain plug-in capabilities on the premise of ensuring the controllability of the user experience and capabilities of the platform itself, such as allowing users to access their own databases, or developing some simple Feature. But no matter what this plug-in mechanism does, to put it bluntly, it can only be the closed small ecological ability of this PaaS. In the cloud native era, our open source community already has an almost "unlimited" capacity pool of Kubernetes ecology, in front of which any small ecology exclusive to PaaS is too pale.

The above problems can be collectively referred to as the "ability dilemma" of PaaS.

By contrast, KubeVela's goal from the beginning was to use the entire Kubernetes ecosystem as its "plug-in hub" and to "intentionally" design each of its built-in capabilities as independent, pluggable plug-ins. This highly scalable model actually has a sophisticated design and implementation. For example, how does KubeVela ensure that a completely independent Trait must be bound to some kind of Workload Type? How to check if there are conflicts between these independent Trait? These challenges are the key role of Open Application Model (OAM) as a KubeVela model layer, in a word: OAM is a highly scalable application definition and capability assembly model.

Moreover, any definition file of Workload Type and Trait is designed and produced, and as long as it is stored on GitHub, any KubeVela user in the world can use these capabilities in his own Appfile. For specific methods, please refer to the usage documentation of $vela cap (that is, plug-in capability management commands).

Therefore, KubeVela advocates a future-oriented cloud native platform architecture that believes that:

The architecture of the application platform itself is completely modular, and all its capabilities are pluggable, while the core framework of the platform provides standardized capability encapsulation and assembly process through the model layer.

This process can seamlessly integrate any application management capabilities in the cloud native ecology, making platform engineers fully focus on the research and development of capabilities themselves and the capability encapsulation process based on this model. It enables the platform team to respond quickly and agilely to the ever-changing application management demands of users while bringing easy-to-use platform-level abstraction to users.

The overall architecture and capability pluggable mechanism of KubeVela

The overall architecture of KubeVela is shown in the following figure:

In architecture, KubeVela has only one controller and runs on top of Kubernetes as a plug-in, which brings application-layer-oriented abstraction to Kubernetes and a user-oriented interface based on it, namely Appfile. The core behind the operation mechanism of Appfile and even KubeVela is its capability management model Open Application Model (OAM). Based on this model, KubeVela provides a set of capability assembly process based on registration and self-discovery for system administrators to connect any capabilities in the Kubernetes ecology to KubeVela, so as to adapt to various usage scenarios (such as AI PaaS, database PaaS, etc.) in the way of "a set of core framework with different capabilities".

In terms of operation, as system administrators or platform developers, the above capability assembly process allows them to register any Kubernetes API resources (including CRD) and the corresponding Controller as "capabilities" in KubeVela, and then encapsulate these capabilities into user-available abstractions (that is, become part of Appfile) through CUE template language.

Next, let's Demo how to insert the alarm mechanism in the kubewatch community directly into the KubeVela as an alarm Trait:

Step 1: register platform capabilities as OAM objects

First, you need to determine whether the capabilities represented by CRD correspond to a Workload Type or a Trait? The difference here is that Workload Type refers to how to run your code. Trait refers to how to operate, manage, or manipulate code instances that are already running.

As an alarm mechanism, KubeWatch is naturally used as Trait. At this point, we can register it by writing a TraitDefinition yaml:

KubeVela's built-in server-side Runtime recognizes monitored TraitDefinition registration events and then incorporates this capability into platform management.

After this step is completed, KubeVela is registered and available on the KubeVela platform. But then we need to expose it to users, so we need to define an external interface for this capability.

Step 2: write CUE template to encapsulate exposed interfaces

In fact, although most communities are powerful, they are complex for end users, and it is very difficult to learn and get started. So in KubeVela, it allows platform administrators to further encapsulate capabilities in order to expose easy-to-use interfaces to users, which are often sufficient with only a few parameters in most scenarios. In the step of capability encapsulation, KubeVela chooses the CUE template language to connect the user interface to the back-end capability object, and naturally supports fully dynamic template binding (that is, changing the template does not require restarting or redeploying the system). Here is an example of a template for KubeWatch Trait:

Put this template in the Definition file and $kubectl apply-f into Kubernetes, and KubeVela will automatically recognize and process the relevant input. At this point, users can directly declare the use of the newly added capabilities in Appfile, such as sending alarm messages to the specified Slack channel:

As you can see, the configuration of this kubewatch is a new capability that we extend through the three parties, and it is so simple and fast to manage Kubernetes extensions through the KubeVela platform. With KubeVela, platform developers can easily and quickly build a PaaS on Kubernetes, and can quickly encapsulate any Kubernetes capability into an upper-level abstraction for end users.

The above example is just the tip of the iceberg of KubeVela extensibility. In future articles, we will continue to detail more details of the KubeVela capability assembly process, such as:

How to define the conflict relationship and collaboration relationship between capabilities?

How to quickly define CUE template files?

How to define powerful "capability modules" based on CUE language, and then install these modules into KubeVela?

Wait a minute...

This is the end of the content of "what are the differences between KubeVela and PaaS". Thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.