Skip to main content

2 posts tagged with "devops"

View All Tags

KubeVela v1.2 - Focused on Developer Experience, Simplified Multi-Cluster Application Delivery

As the cloud native technologies grows continuously, more and more infrastructure capabilities are becoming standardized PaaS or SaaS products. To build a product you don't need a whole team to do it nowadays. Because there are so many services that can take roles from software developing, testing to infrastructure operations. As driven the culture of agile development and cloud native technologies, more and more roles can be shifted left to developers, e.g. testing, monitoring, security. As emphasized by the DevOps concepts, it can be done in the development phase for the work of monitoring, security, and operations via open source projects and cloud services. Nonetheless, this also creates huge challenges to developers, as they might lack the control of diverse products and complex APIs. Not only do they have to make choices, but also they need to understand and coordinate the complex, heterogeneous infrastructure capabilities in order to satisfy the fast-changing requirements of the business.

This complexity and uncertainty has exacerbated the developer experience undoubtedly, reducing the delivery efficiency of business system, increasing the operational risks. The tenet of developer experience is simplicity and efficiency. Not only the developers but also the enterprises have to choose the better developer tools and platforms to achieve this goal. This is also the focus of KubeVela v1.2 and upcoming release that to build a modern platform based on cloud native technologies and covering development, delivery, and operations. We can see from the following diagram of KubeVela architecture that developers only need to focus on applications per se, and use differentiated operational and delivery capabilities around the applications.

image.png pic 1. KubeVela Architecture

OAM & KubeVela History#

Let's retrospect the history of OAM and KubeVela to understand how it is formed this way:

  • OAM(Open Application Model)birth and growth

To create simplicity in a complex world, the first problem we need to solve is how to make standard abstractions? OAM creatively proposes two ways of separation: separation between applications and resources, and separation between development and operation (in ideal world the operation can be fully automated). It is a cloud native application specification which provides everything-as-a-service, complete modularity design. The spec has been getting tractions among major vendors all over the world since it's been announced. Because we all share a common goal -- To reduce learning curve and provide application lego-style invention for developers.

  • v1.0 release of KubeVela, bringing the OAM spec implementation

With the application specification as the guidance, advanced community users can create their own tools to build practical solutions. But it is unaccessible to most developers though. KubeVela was born as the community standard implementation to solve this problem. It absorbs the good parts from latest Kubernetes community development. It provides automated, idempotent, reliable application rollout controllers. With its features, KubeVela can empower developers to quickly deploy OAM-compliant applications.

  • v1.1 release of KubeVela, provides delivery workflow, making multi-cluster rollout controlled and simplified

As more and more enterprises adopt the cloud, hybrid and distributed cloud will certainly become the future norm. KubeVela has been designed and built based on hybrid cloud infrastructure as a modern application management system. We anticipate that the architecture of modern enterprise applications will be heterogenous considering factors of availability, performance, data security, etc. In KubeVela 1.1, we adds new feature to achieve programmable delivery workflow. It natively fits the multi-cluster architecture to provide modern multi-cluster application rollout.

By the time of 2022, on the road to serve developers, KubeVela has gone to the fourth phase. It is going to empower developers to do multi-cluster rollout way more easily. In the following we will dissect its changes:

Core Features in v1.2 Release#

The new GUI project: VelaUX#

It is the best choice to reduce developer learning curve by providing an easy-to-use UI console. Since the inception, KubeVela community has been asking for UI. With the v1.2 release, it has finally come. Providing GUI will help developers organize and compose heterogeneous aplications in a standard way. This will help them analyze and discover business obstacles quicker.

VelaUX is the frontend project of KubeVela with extensible core design. It introduces low-code experience for users to drag-and-drop form that takes user input based on dynamic components. To achieve this we have designed the frontend description spec UISchema with X-Definition, and multi-dimensional query language VelaQL. This design makes the foundation for the heterogenous application delivery architecture of KubeVela.

From GUI, users can manage addons, connect Kubernetes clusters, distribute delivery targets, set up environments and deploy all kinds of apps, monitor runtime status, achieve full lifecycle management of application delivery.

image.png pic 2. KubeVela Application Dashboard

For the new terms in GUI, please refer to Core Concepts documentation to learn more details.

Unified Multi-Cluster Control#

KubeVela will manage N Kubernetes clusters, N cloud vendor services in a big unified infrastructure pool. From that our developers can set up different environments based on business requirements, workflow policies, team collaboration needs, etc. This will create separate environment workspaces from big infrastructure resource pool. One application can be deployed into multiple environments, and environments are isolated from each other in both management and runtime.

image.png pic 3. KubeVela Application Status

As shown above, an application can be deployed to default environments and other custom environments such as test or prod. Each environment can include multiple delivery targets. Each delivery target indicates an independent, separate Kubernetes cluster.

Heterogeneous Application Architecture#

In terms of cloud native technologies, we have many options to pick for build application delivery solutions. Based on Kubernetes, we can use mature technologies like Helm Chart to delivery middleware and third-party open source softwares. We can deliver enterprise business applications via container images. We can also use OpenYurt to deliver and mange edge applications. Based on the open technologies of cloud services, we can deliver database, message queues, cache, etc. middleware, including operational features like logging, monitoring.

With so many options, KubeVela adopts OAM as the standard application definition to manage heterogeneous application architecture uniformly. KubeVela provides highly extensible delivery core engine. Users can use built-in or install more plugins to extend the platform, and manage application deliveries in a consistent way. On top of KubeVela, what users see is the modular, everything-as-a-service control plane.

image.png pic 4. Cloud Resources Deploy

As shown above, we can tell that in the application management page users can conveniently deliver cloud resources. Developers can read the following docs to understand the full delivery process of heterogeneous application architecture:

  1. Deliver Docker Image
  2. Deliver Helm Chart
  3. Deliver Kubernetes Resources
  4. Deliver cloud resources

Extension System#

KubeVela has been designed as an extensible system from the very beginning. The aforementioned heterogeneous application architecture can be achieved via KubeVela's extension system. It can be extended via standard interfaces and plugin as many capabilities as you want. This will match the differentiated requirements of enterprises while reducing the cognitive burden incurred in learning new things. KubeVela's extension system includes component types, operational traits, workflow types, delivery policies, etc. In current release, we have the addon management system. An addon packages the extension capabilities for easy distribution.

image.png pic 5. KubeVela Addons

Currently we provide an official catalog with pre-packaged addons shown as above. Meanwhile in the experimental catalog repo we can collaborating with community users to create more capabilities.

By now, KubeVela has grown into an application delivery platform that serve developers directly. What enterprise scenarios can we use KubeVela for? In the following we list a couple of common scenarios:

Enterprise Software Delivery Solutions#

Multi-Cluster DevOps#

Today many enterprise software delivery looks like the following diagram. They use the compute resources from cloud vendors for both the demo and production environments. But they use their in-house server farm for the development or testing environments. If any business applications have multi-region disaster recovery requirements, then production environments can span multiple regions or even clouds.

image.png pic 6. DevOps Pipeline

For basic DevOps workflow, it includes code hosting, CI/CD process. KubeVela can provide support for CD process. To enterprises the following are the practical steps:

  1. Prepare local and cloud resources according to real needs. Make sure local and cloud resources are connected in the same network plane for unified resource management.
  2. Deploy KubeVela into the production environment and ensure its accessibility.
  3. Install DevOps toolchain like Gitlab, Jenkins, Sonar via KubeVela. Usually the accessability of code hosting and developer toolchain are critical and we must deploy them to production environments. Unless you local clusters can ensure accessibility, can hope the business code to exist in local environment, then you can deploy them to local clusters.
  4. Setup local development environments via KubeVela, deploy testing middleware in local. Setup cloud middleware in production environments.
  5. Setup business code CI piplines via Jenkins. Generates Docker image and send it to KubeVela to do multi-environment deployment. This will make up an end-to-end application delivery workflow.

Using KubeVela multi-cluster DevOps solution will provide the following advantages:

  1. Developers do not need to know any Kubernetes knowledge to achieve heterogeneous cloud-native application delivery.
  2. Unified multi-cluster, multi-environment management in a single control plane. Natively deploy multi-cluster applications.
  3. Unified application management mode, regardless of business applications or developer toolchain.
  4. Flexible workflow to help enterprises to glue various software delivery processes in a single workflow.

Unified Management of Heterogeneous Environments#

Different enterprises face different problems and requirements of infrastructure and business. On the infrastructure side, enterprises could build in-house private cloud, yet buy some public cloud resources, and own some edge devices. On the business side, the variance of scale and requirements will lead to multi-cloud, multi-region application architecture, while keeping some legacy systems. On the developer side, developing software will need various environments such as development, testing, staging, production. On the management side, different business teams need isolation from each other, while opening up connection between some business applications. ​

In the past, it was very easy to become fragmented between different business teams inside enterprises. This fragmentation exists in: toolchain, technical architecture, business management. We take this into account while being innovative in technologies. KubeVela brings a new solution that pursues unified management and extensible architecture with good compatibility.

  • On the infrastructure side, we support different API formats including Kubernetes API, cloud APIs, and custom APIs to model all kinds of the infrastructure.
  • On the business architecture side, the application model is open and platform agnostic. KubeVela provides the ability to connect and empower businesses.
  • On the Developer toolchain side, there might be different toolchain and artifacts in the enterprises. KubeVela provides the extension mechanism and standard models to combine different kinds of artifacts into a standardized delivery workflow. Surely, its standards are shifting left and empowering enterprises to unify toolchain management. You don't need to concern whether you are using Gitlab or Jenkins because KubeVela can integrate them both.
  • On the operations side, the operational capabilities and toolchain solutions can be unified under KubeVela standards in the enterprises. Moreover, the community operational capabilities can be shared and reused easily via KubeVela extensions.

Thus, KubeVela can be used to connect different stages inside the enterprises, and unify all capabilities in a single platform. It is a practical and future-proof solution.

Enterprise Internal Application Platform#

Many enterprises that has enough development power will choose to build internal application platforms. The main reason is that they can customize the platform to make it very easy for their use cases. In the past we can see there are many PaaS platforms born out of Cloud Foundry. We all know the stereotypes of application platforms will not satisfy all enterprises. If the application package format and delivery workflow can standardized inside enterprises, then all users need to do is to fill the image name. However, in traditional PaaS platforms developers have to understand a bunch of so-called general concepts. For example, if an enterprise want to deploy AI applications, and there is some difference for AI application architecture, then we have to create such AI PaaS, and enterprises have to pay more fees and learn more concepts.

Therefore, when general products couldn't satisfy the needs of enterprises, they will consider develop one on their own. But it takes so much resources to build an internal platform from scratch. Sometimes it even surpasses the investment of their core business. This is not a feasible solution.

With above introduction, are you more familiar with the motivations and history of KubeVela? There is no such a product to be the silver bullet. But our goal is to create a standardized model to empower more and more enterprises and developers to participate in the path towards building simple and efficient developer tools. KubeVela is still in early development phase. We still hope you can join us to develop it together. We want to thank the 100+ contributors who contributed to KubeVela.

Join the Community#

Collaborate on OAM Specification#

OAM spec is the cornerstone of modern application platform architecture. Currently, OAM spec is driven by implementation of KubeVela for future improvement while the spec didn't rely on KubeVela. We highly encourage cloud vendors, platform builders, and end users to join us to define OAM spec together. We highly appreciate that vendors like Tencent, China Telecom, China Unicom have supported OAM spec and started collaborative work. Every person and organization are welcome to share your ideas, suggestions, and thoughts.

Go the Community repo.

Collaborate on Addon ecosystem#

As mentioned above, we have created the addon extension system, and encourage community developers to contribute your tools, and share your thoughts.

Contribute Cloud Resources#

KubeVela integrated Terraform Module with Terraform controller to extend cloud resources. We have supported several cloud resources, and encourage community developers or cloud providers to contribute more.

Go to contribute cloud resource.

Provide Your Feedback#

We highly welcome everyone to participate in the KubeVela community discussion whether you want to know more or contribute code!

Go to Community repo.

KubeVela is a CNCF sandbox project. Learn more by reading the official documentation

KubeVela Releases 1.1, Reaching New Peaks in Cloud-Native Continuous Delivery


Initialized by Alibaba and currently a CNCF sandbox project, KubeVela is a modern application platform that focues on modeling the delivery workflow of micro-services on top of Kubernetes, Terraform, Flux Helm controller and beyond. This brings strong value added to the existing GitOps and IaC primitives with battle tested application delivery practices including deployment pipeline, across-environment promotion, manual approval, canary rollout and notification, etc.

This is the first open source project in CNCF that focuses on the full lifecycle continuous delivery experience from abstraction, rendering, orchestration to deployment. This reminds us of Spinnaker, but designed to be simpler, cloud native, can be used with any CI pipeline and easily extended.


Kubernetes has made it easy to build application deployment infrastructure, either on cloud, on-prem, or on IoT environments. But there are still two problems for developers to manage micro-service applications. First, developers just want to deploy, but delivering application with lower level infrastructure/orchestrator primitives is too much for them. It's very hard for developers to keep up with all these details and they need a simpler abstraction to "just deploy". Second, application delivery workflow is a basic need for "just deploy", but it is inherently out of scope of Kubernetes itself. The existing workflow addons/projects are too generic, they are way more than focusing on delivering applications only. These problems makes continuous delivery complex and unscalable even with the help of Kubernetes. GitOps can help in deploying phase, but lack the capabilities of abstracting, rendering, and orchestration. This results in low SDO (software delivery and operation) performance and burnout of DevOps engineers. In worst case, it could cause production outage if users make unsafe operations due to the complexity.

The latest DORA survey [1] shows that organizations adopting continuous delivery are more likely to have processes that are more high quality, low-risk, and cost-effective. Though the question is how we can make it more focused and easy to practice. Hence, KubeVela introduces Open Application Model (OAM), a higher level abstraction for modeling application delivery workflow with app-centric, consistent and declarative approach. This empowers developers to continuously verify and deploy their applications with confidence, standing on the shoulders of Kubernetes control theory, GitOps, IaC and beyond.

KubeVela latest 1.1 release is a major milestone bringing more continuous delivery features. It highlights:

  • Multi-environment, multi-cluster rollout: KubeVela allows users to define the environments and the clusters which application components to deploy to or to promote. This makes it easier for users to manage multi-stage application rollout. For example, users can deploy applicatons to test environment and then promote to production environment.
  • Canary rollout and approval gate: Application delivery is a procedural workflow that takes multiple steps. KubeVela provides such workflow on top of Kubernetes. By default, Users can use KubeVela to build canary rollout, approval gate, notification pipelines to deliver applications confidently. Moreover, the workflow model is declarative and extensible. Workflow steps can be stored in Git to simplify management.
  • Addon management: All KubeVela capabilities (e.g. Helm chart deployment) are pluggable. They are managed as addons [2]. KubeVela provides simple experience via CLI/UI to discover, install, uninstall addons. There is an official addon registry. Users can also bring their own addon registries.
  • Cloud Resource: Users can enable Terraform addon on KubeVela to deploy cloud resources using the same abstraction to deploy applications. This enables cooperative delivery of application and its dependencies. That includes databases, redis, message queues, etc. By using KubeVela, users don't need to switch over to another interface to manage middlewares. This provides unified experience and aligns better with the upcoming trends in CNCF Cooperative-Delivery Working Group [3].

That is the introduction about KubeVela 1.1 release. In the following, we will provide deep-dive and examples for the new features.

Multi-Environment, Multi-Cluster Rollout#

Users would need to deploy applications across clusters in different regions. Additionally, users would have test environment to run some automated tests first before deploying to production environment. However, it remains mysterious for many users how to do multi-environment, multi-cluster application rollout on Kubernetes.

KubeVela 1.1 introduces multi-environment, multi-cluster rollout. It integrates Open Cluster Management and Karmada projects to handle multi-cluster management. Based on that, it provides EnvBinding Policy to define per-environment config patch and placement decisions. Here is an example of EnvBinding policy:

- name: example-multi-env-policy
type: env-binding
- name: staging
placement: # selecting the cluster to deploy to
name: cluster-staging
selector: # selecting which component to use
- hello-world-server
- name: prod
name: cluster-prod
patch: # overlay patch on above components
- name: hello-world-server
type: webservice
- type: scaler
replicas: 3

Below is a demo for a multi-stage application rollout from Staging to Production. The local cluster serves as the control plane and the rest two are the runtime clusters.

Note that all the resources and statuses are aggregated and abstracted in the KubeVela Applications. Did any problems happen, it will pinpoint the problematic resources for users. This results in faster recovery time and more manageable delivery.

Canary Rollout, Approval, Notification#

Can you build a canary rollout pipeline in 5 minutes? Ask Kubernetes users and they would tell you it is not even enough to learn an Istio concept. We belive that as a developer you do not need to master Istio to build a canary rollout pipeline. KubeVela abstracts away the low level details and provides a simple solution as follows.

First, installing Istio is made easy via KubeVela addons:

vela addon enable istio

Then, users just need to define how many batches for the rollout:

- type: rollout
targetSize: 100
- replicas: 10
- replicas: 90

Finally, define the workflow of canary, approval, and notification:

- name: rollout-1st-batch
type: canary-rollout
# just upgrade first batch of component
batchPartition: 0
- revision: reviews-v1
weight: 90 # 90% to the old version
- revision: reviews-v2
weight: 10 # 10% to the new version
- name: approval-gate
type: suspend
- name: rollout-rest
type: canary-rollout
batchPartition: 1
- revision: reviews-v2
weight: 100 # 100% shift to new version
- name: send-msg
type: webhook-notification
url: <your slack webhook url>
text: "rollout finished"

Here is a full demo:

What Comes Next#

In this KubeVela release we have built the cornerstone for continuous delivery on Kubernetes. For the upcoming release our major theme will be improving user experience. We will release a dashboard that takes the user experience to another level. Besides that, we will keep improving our CLI tools, debuggability, observability. This will ensure our users can self serve to not only deploy and manage applications, but also debug and analyze the delivery pipelines.

For more project roadmap information, please see Kubevela RoadMap.

Join the Community#

KubeVela is a community-driven, open-source project. Dozens of leading enterprises have adopted KubeVela in production, including Alibaba, Tencent, ByteDance, XPeng Motors. You are welcome to join the community. Here are next steps:


(1) DORA full report: (2) KubeVela Addon: (3) Cooperative Delivery Charter: