KubeVela 1.4: Make application delivery safer, easier to get started, and more transparent

Authors: Sun Jianbo, Zeng Qingguo

KubeVela is a modern software delivery control plane that aims to make application deployment and operation simpler, agile, and reliable in today's hybrid multi-cloud environment. Since the release of version 1.1 , the KubeVela architecture has naturally solved the delivery problems of enterprises facing the hybrid multi-cloud environment, and has provided sufficient scalability around the OAM model, which has won the love of a large number of enterprise developers, which also makes KubeVela's iteration speed continue. accelerate.

In version 1.2 , we released an out-of-the-box visual console, which allows end users to publish and manage diverse workloads through the interface; the release of version 1.3 improved the OAM model-centric extension system and provided rich plug-in functions , and provides users with a large number of enterprise-level functions including LDAP authority authentication, and provides great convenience for enterprise integration. So far, you can get more than 30 plugins in the plugin center of the KubeVela community, including not only well-known CNCF projects such as argocd, istio, and traefik, but also database middleware such as flink, mysql, and hundreds of different cloud Vendor resources are available for immediate use.

In the 1.4 version released this time, we focus on the three cores of making application delivery safer, easier to get started, and more transparent in the process, adding cores including multi-cluster permission authentication and authorization, complex resource topology display, and one-click installation of the control plane. It comprehensively reinforces the delivery security in multi-tenant scenarios, improves the consistent experience of application development and delivery, and makes the application delivery process more transparent.

Interpretation of core functions

Out-of-the-box authentication and authorization, docking with Kubernetes RBAC, and natural support for multiple clusters

After comprehensively solving the challenges of architecture upgrade and scalability, we observed that the security of application delivery is an urgent problem that the entire industry needs to solve today. From the user cases we encountered, we found many security risks:

• In the process of using traditional CI/CD, a large number of users will directly embed the admin permissions of the production cluster into the CI environment variables, and only have a certain separation of permissions for the most basic clusters to which they are delivered. The CI system is usually intensively used for development and testing, and it is easy to introduce uncontrolled risks. With centralized management and coarse-grained permission control, once the CI system is attacked by hackers or some human misoperation occurs, it is easy to cause huge damage and the consequences are unimaginable.
• A large number of CRD controllers rely on admin privileges to operate on cluster resources without restricting access to APIs. Although Kubernetes itself has rich RBAC control capabilities, most users do not really care about the details because of the high threshold for learning permission management and have nothing to do with the implementation of specific functions, and usually just choose the default configuration and put it into production use. Controllers with high flexibility (such as the ability to distribute Helm Charts) are easy targets for hackers, such as embedding a YAML script in helm to steal keys from other namespaces.

KubeVela 1.4 has added authentication and authorization capabilities, and naturally supports multi-cluster hybrid environments . For each KubeVela platform administrator, they can not only customize any combination of API permissions in a fine-grained manner, but also connect to the Kubernetes RBAC system. The module is authorized to developer users, and their permissions are strictly limited; it is also possible to easily use the permission modules preset by the KubeVela platform, such as directly granting users a specific namespace permission of a cluster, granting a user "read-only" permission, etc. It greatly simplifies the learning cost and mental burden of users, and comprehensively strengthens the security of application delivery. For users using the UI, the system automatically completes the underlying authorization and strictly verifies the scope and types of resources available to the project, so that the RBAC permissions of the business layer and the underlying Kubernetes RBAC system can be connected and work together to achieve security from the outside to the inside. Any link expands the authority.

Specifically, after the platform administrator authorizes a user , the user's request will go through several stages as shown in the figure.

1. KubeVela's webhook first intercepts the user's request and sends the user's permission information (ServiceAccount) to the Application object.
2. When the KubeVela Controller executes the Application deployment plan, it will be converted into the permissions of the corresponding user based on the role-playing mechanism (impersonate) of Kubernetes.
3. The KubeVela multi-cluster module (ClusterGateway) will pass the corresponding permissions to the sub-cluster, and the Kubernetes APIServer of the sub-cluster will authenticate according to the permissions of the sub-cluster. Subcluster permissions are created by KubeVela's authorization process.

In short, KubeVela's multi-cluster authentication and authorization function ensures that the permissions of each end user are strictly constrained and will not be amplified by the delivery system. At the same time, KubeVela's own permissions are also minimized , and the entire user experience is very simple.

If you want to know more functions and the implementation principles behind them, you are welcome to read the official permission authentication and authorization documents to learn more about the operating mechanism behind them.

References

ACK One (Alibaba Cloud Distributed Cloud Container Platform) is an enterprise-level cloud-native platform launched by Alibaba Cloud for scenarios such as hybrid cloud, multi-cluster, distributed computing, and disaster recovery. The KubeVela multi-cluster control plane is the core implementation of ACK One. Based on this feature, ACK One implements role-playing-based application multi-cluster distribution.

Reference document: https://help.aliyun.com/document_detail/419336.html

Lightweight and convenient application development control plane, consistent experience for local development and production deployment

With the continuous prosperity of the ecology, we also see that more and more developers are beginning to pay attention to cloud-native technologies, but they often suffer from no good way to get started. The main reasons are as follows:

• The development environment of the application is inconsistent with the production environment , and the experience is very different. Cloud native is a technology trend that has gradually emerged in the past five or six years. Although it has developed rapidly, most companies are still used to developing a set of internal platforms to shield the underlying technology. This makes it difficult for ordinary business developers to practice in actual work even if they have learned cloud-native technologies. In the best case, they may have to re-connect the API and configuration, let alone a consistent experience.
• The deployment and use of cloud-native technologies with Kubernetes as the core is very complicated , and the cost of purchasing managed services from cloud vendors is very high if only for entry-level learning. Even if it takes a lot of effort to learn to deploy a set of available local environments, it is difficult to connect many cloud native technologies to complete the entire CI/CD process, which involves a lot of knowledge in the field of operation and maintenance, while ordinary development They usually don't need attention and are difficult to get in touch with.

We have also observed in the community that more and more companies are beginning to realize that their internal self-built platforms cannot keep up with the speed of community ecological development, and expect to provide a consistent experience through KubeVela and OAM models without losing ecological scalability. However, the control plane of KubeVela relies on Kubernetes, and the threshold for getting started is still not low. In response to this problem, the community has been thinking and looking for solutions. In the end, our conclusion is that we need a tool to meet the needs and have these characteristics:

• It can be deployed and run only by relying on the container environment (such as Docker), so that every developer can easily obtain and use it ;
• The local development and production environment experience is exactly the same , and the configuration is reusable, which can simulate a hybrid multi-cluster environment;
• A single binary package supports offline deployment , and the environment initialization time does not exceed the time for drinking a glass of water (3 minutes);

After months of hard work and incubation, we can finally officially release this tool in 1.4: VelaD , D stands for both Daemon and Developer, it can help KubeVela to run on a single machine, without relying on any existing Kubernetes cluster, and at the same time with KubeVela As a whole, it is a lightweight application development control plane, which helps developers obtain an integrated development, testing, and delivery experience, and simplifies the complexity of cloud-native application deployment and management.

You can install and try this tool through the Demo document to learn more about the implementation details. The installation and initialization only takes 3 minutes.

Display resource topology and status, making the delivery process transparent

Another big appeal in application delivery is the transparent management of the resource delivery process. For example, many users in the community like to use Helm Chart to package a lot of complex YAML, but once there is a deployment problem, such as the underlying storage If it is not provided normally, the associated resources are not created normally, the underlying configuration is incorrect, etc., even a small problem will be difficult to troubleshoot due to the overall black box. Especially in the modern hybrid multi-cluster hybrid environment, there are many types of resources and complex, how to obtain effective information and solve problems is a very big problem.

In version 1.4, we added the resource topology map query function to further improve KubeVela's application-centric delivery experience. Developers only need to care about simple and consistent APIs when initiating application delivery. When they need to troubleshoot problems or pay attention to the delivery process, they can use the resource topology function to quickly obtain the arrangement relationship of resources in different clusters, from the application to the running status of the Pod instance. Automatically obtain the relationship between resources, including complex and black-box Helm Charts .

Take the application shown in the above figure as an example. The user delivers a Redis cluster through the Helm Chart package. The first layer of the diagram is the application name, the second layer is the cluster, the third layer is the resources directly rendered by the application, and the following three layers , and the fourth layer is based on the subordinate associated resources tracked by different resources.

In the process of delivering the application, the user can observe the derived resources and status through the graph. When the node is abnormal, the node will be displayed in yellow or red status and the specific reason will be displayed. For example, the application shown in the figure below is a basic Webservice service delivered to two clusters. Developers can find that the application actually creates Deployment and Service resources in the two clusters, while the Deployment resource in the ask-hongkong cluster is displayed in yellow. , because the Pod instance has not been fully started.

This function also supports searching, filtering and querying through different clusters and different components, helping developers to quickly focus and find problems, and understand the delivery and operation status of the underlying application with a very low threshold.

If you want to know more functions and the implementation principles behind them, please read the official blog Tracking and Visualizing Multi-Cluster Kubernetes Resource Topology to gain an in-depth understanding of the operating mechanism behind it.

Other key changes

In addition to core functions and plug-in ecology, version 1.4 also enhances core functions such as workflow:

• Application state maintenance supports configuration field ignoring rules, enabling KubeVela to work with other controllers, such as HPA and Istio.
• Application resource recycling supports setting based on resource type, currently based on component name, component type, feature type and resource type.
• Workflow supports sub-step capabilities, and sub-steps support concurrent execution, accelerating resource delivery in multi-cluster high-availability scenarios.
• Workflow steps support pausing for a certain period of time, and automatically continue the workflow when the pause time is reached.
• The resource deployment and recycling support follows the component dependency rule settings, and supports the sequential deployment and sequential recycling of resources.
• Workflow steps support conditional judgment. Currently, if: always rule is supported, which means that the step is executed under any circumstances, thus supporting deployment failure notification.
• The operation and maintenance feature supports setting the deployment scope, which can realize the separation of the operation and maintenance feature and the component deployment state, and the operation and maintenance feature can be independently deployed in the management and control cluster.

Thanks for the continuous contributions from more than 30 organizations and individuals at home and abroad, including Alibaba Cloud, China Merchants Bank, and Napptive. Makes this iteration deliver so many great features to the community!

For more details on the changes, please refer to the Release notes .

Addon

With the improvement of the 1.3 plug-in system, our plug-in ecosystem is also rapidly expanding:

• Update fluxcd addon to support OCI registry, support to select different values files in chart during deployment.
• Added the cert-manager plugin to automate the management of Kubernetes certificates.
• Added the flink-kubernetes-operator plugin to deliver flink workloads.
• Added kruise-rollout plugin to support multiple release strategies such as grayscale release and canary release.
• Added pyroscope plugin to support continuous performance tuning.
• Added traefik plugin to support configuring API gateway.
• Added the vegeta plugin to support automated stress testing of workloads.
• Added argocd plugin to support ArgoCD-based Helm delivery and GitOps.
• A new dapr plug-in is added to support the operation and maintenance capabilities of Dapr subscription and publishing.
• Added istio plug-in to support Istio-based gateway capability and traffic grayscale.
• Added the mysql-operator plugin to support the deployment of a highly available distributed mysql database.

Developers are very welcome to participate in the community and make plugins to expand the system capabilities of KubeVela.

How to get involved in the community

KubeVela is a global top-level active open source project in the CNCF Foundation. There are more than 300 domestic and foreign contributors, more than 40 community members and maintainers here. From code, documentation to community communication, all are Chinese-English bilingual international operations way, there are more than 4000+ community members.

If you are interested in participating in the open source community, we very much welcome you to join the KubeVela community. You can learn more about the ways and methods of participating in the open source community through the developer documentation of the KubeVela community, and the engineers in the community will also be patient. guide you to get started.

near-term planning

KubeVela will continue to evolve around a two-month iteration cycle. In the next version, we will focus on these three dimensions:

• Observability, providing end-to-end rich application insight around log, metrics, tracing and other dimensions, laying a solid foundation for the stability and intelligence of application delivery.
• Workflow delivery capabilities provide richer frameworks and integration capabilities, including custom step timeouts, conditional judgments based on contextual information, and branch workflows, etc., connect CI/CD, and provide users with richer use cases and scenarios.
• Application (including plug-in) management capabilities, support application shutdown, restart, support application import, export, upload to the application (plug-in) market, etc.

If you want to know more about planning, become a contributor or partner, you can contact us by participating in community communication ( https://github.com/kubevela/community ), we look forward to your joining!

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

• Project repository: github.com/oam-dev/kubevela Welcome to Star/Watch/Fork!
• The official homepage and documentation of the project: kubevela.io, since version 1.1, Chinese and English documents have been provided, and developers are welcome to translate more language documents.
• Project DingTalk Group: 23310022; Slack: CNCF #kubevela Channel
• Join WeChat group: Please add the following maintainer WeChat account to indicate that you have entered the KubeVela user group:

Click " here " to view the official website of the KubeVela project.