Skip to main content

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

· 7 min read
KubeVela Maintainers

Overview​

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.

Introduction​

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 community 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:

  policies:
    - name: example-multi-env-policy
      type: env-binding
      properties:
        envs:
          - name: staging
            placement: # selecting the cluster to deploy to
              clusterSelector:
                name: cluster-staging
            selector: # selecting which component to use
              components:
                - hello-world-server

          - name: prod
            placement:
              clusterSelector:
                name: cluster-prod
            patch: # overlay patch on above components
              components:
                - name: hello-world-server
                  type: webservice
                  traits:
                    - type: scaler
                      properties:
                        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:

traits:
  - type: rollout
    properties:
      targetSize: 100
      rolloutBatches:
        - replicas: 10
        - replicas: 90

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

  workflow:
    steps:
      - name: rollout-1st-batch
        type: canary-rollout
        properties:
          # just upgrade first batch of component
          batchPartition: 0
          traffic:
            weightedTargets:
              - 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
        properties:
          batchPartition: 1
          traffic:
            weightedTargets:
              - revision: reviews-v2
                weight: 100 # 100% shift to new version
                
      - name: send-msg
        type: webhook-notification
        properties:
          slack:
            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:

References​

(1) DORA full report: https://cloud.google.com/blog/products/devops-sre/announcing-dora-2021-accelerate-state-of-devops-report (2) KubeVela Addon: https://github.com/kubevela/catalog/tree/master/addons/example (3) Cooperative Delivery Charter: https://github.com/cncf/tag-app-delivery/blob/master/cooperative-delivery-wg/charter.md