mirror of
https://github.com/kubevela/kubevela.git
synced 2026-08-18 03:56:36 +00:00
Update concepts and readme to reflect recent change
This commit is contained in:
Harry Zhang
@@ -9,13 +9,13 @@
|
||||
|
||||
|
||||
|
||||
*Shipping apps with joy, building platforms with smile.*
|
||||
*Make shipping applications more enjoyable.*
|
||||
|
||||
# KubeVela
|
||||
|
||||
For developers, KubeVela serves as an easy-to-use yet extensible platform that enables them to describe and ship applications to Kubernetes with minimal effort.
|
||||
For developers, KubeVela is an easy-to-use yet extensible platform that enables them to design and ship applications with minimal effort.
|
||||
|
||||
For platform builders, KubeVela is the engine that empowers them to create such platforms at scale.
|
||||
For platform builders, KubeVela is the core engine that empowers them to create above platform with ease.
|
||||
|
||||
## Community
|
||||
|
||||
@@ -24,13 +24,17 @@ For platform builders, KubeVela is the engine that empowers them to create such
|
||||
|
||||
> NOTE: KubeVela is still in early stage and iterating quickly. It's currently under preview release.
|
||||
|
||||
## User Guide
|
||||
## How It Works?
|
||||
|
||||
|
||||
|
||||
## Quick Start
|
||||
|
||||
Quick start guides for developers are available on [this section](https://kubevela.io/#/en/quick-start).
|
||||
|
||||
## Platform Builder Guide
|
||||
|
||||
Tutorials for platform builders are available on [this section](https://kubevela.io/#/en/platform-engineers/overview).
|
||||
Detailed guides for platform teams are available on [this section](https://kubevela.io/#/en/platform-engineers/overview).
|
||||
|
||||
## Documentation
|
||||
|
||||
|
||||
+14
-5
@@ -4,19 +4,28 @@
|
||||
|
||||
# KubeVela
|
||||
|
||||
For developers, KubeVela is an easy-to-use tool that enables them to describe and ship their applications to Kubernetes with minimal effort.
|
||||
For developers, KubeVela is an easy-to-use yet extensible platform that enables them to design and ship applications with minimal effort.
|
||||
|
||||
For platform builders, KubeVela serves as a framework that empowers them to create developer facing yet highly extensible platforms at ease.
|
||||
For platform builders, KubeVela is the core engine that empowers them to create above platform with ease.
|
||||
|
||||
- Slack: [Discuss](https://cloud-native.slack.com/archives/C01BLQ3HTJA)
|
||||
- Gitter: [Community](https://gitter.im/oam-dev/community)
|
||||
## Community
|
||||
|
||||
- Slack: [CNCF Slack](https://slack.cncf.io/) #kubevela channel
|
||||
- Gitter: [Discussion](https://gitter.im/oam-dev/community)
|
||||
|
||||
> NOTE: KubeVela is still in early stage and iterating quickly. It's currently under preview release.
|
||||
|
||||
## How It Works?
|
||||
|
||||
|
||||
|
||||
## Quick Start
|
||||
|
||||
Quick start guides are available on [this section](/en/quick-start).
|
||||
Quick start tutorials for developers are available on [this section](/en/quick-start).
|
||||
|
||||
## Platform Builder Guide
|
||||
|
||||
Detailed guides for platform teams are available on [this section](/en/platform-engineers/overview).
|
||||
|
||||
## Contributing
|
||||
Check out [CONTRIBUTING](https://github.com/oam-dev/kubevela/blob/master/CONTRIBUTING.md) to see how to develop with KubeVela.
|
||||
|
||||
+7
-7
@@ -1,8 +1,14 @@
|
||||
- Overview
|
||||
- [Introduction](/en/introduction.md)
|
||||
- [Getting Started](/en/quick-start.md)
|
||||
- [Concepts and Glossaries](/en/concepts.md)
|
||||
|
||||
- User Guide
|
||||
- Platform Team Guide
|
||||
- [Register Workload Type](/en/platform-engineers/workload-type.md)
|
||||
- [Register Trait](/en/platform-engineers/trait.md)
|
||||
- [Register Cloud Services](/en/platform-engineers/cloud-services.md)
|
||||
|
||||
- End User Guide
|
||||
- Appfile
|
||||
- [Learning Appfile](/en/developers/learn-appfile.md)
|
||||
- Operating
|
||||
@@ -21,16 +27,10 @@
|
||||
- [Configuring data/env in Application](/en/developers/config-app.md)
|
||||
- [Alternative Commands](/en/developers/alternative-cmd.md)
|
||||
|
||||
- Platform Builder Guide
|
||||
- [Add Workload Type](/en/platform-engineers/workload-type.md)
|
||||
- [Add Trait](/en/platform-engineers/trait.md)
|
||||
- [Add Cloud Services](/en/platform-engineers/cloud-services.md)
|
||||
|
||||
- Roadmap
|
||||
- [KubeVela Roadmap](/en/roadmap.md)
|
||||
|
||||
- References
|
||||
- [Concepts and Glossaries](/en/concepts.md)
|
||||
- [Appfile](/en/developers/references/devex/appfile.md)
|
||||
- Capabilities
|
||||
- Workload Types
|
||||
|
||||
+87
-19
@@ -1,35 +1,103 @@
|
||||
# Concepts and Glossaries
|
||||
|
||||
This document explains some technical terms that are widely used in KubeVela, such as `application`, `service`, `workload type`, `trait` etc., from user's perspective. The goal is to clarify them in the context of KubeVela.
|
||||
This document explains some technical terms that are widely used in KubeVela, such as `application`, `appfile`, `workload types` and `traits`. The goal is to clarify them for platform builders in the context of KubeVela.
|
||||
|
||||
## Overview
|
||||
|
||||
|
||||
|
||||
## Workload Type & Trait
|
||||
The core KubeVela APIs are built based on Open Application Model (OAM). Hence, the `workload type` and `trait` concepts are inherited from OAM.
|
||||
|
||||
A [workload type](https://github.com/oam-dev/spec/blob/master/4.workload_definitions.md) declares the characteristics that runtime infrastructure should take into account in application management. A typical workload type could be a "long running service", or a "one-time off task" that can be instantiated as part of your application.
|
||||
|
||||
A [trait](https://github.com/oam-dev/spec/blob/master/6.traits.md) represents an optional configuration that attaches to an instance of workload type. Traits augment a workload type instance with operational features such as load balancing policy, network ingress routing, circuit breaking, rate limiting, auto-scaling policies, upgrade strategies, and many more.
|
||||
|
||||
## Capability
|
||||
A capability is a functionality provided by the runtime infrastructure (i.e. Kubernetes) that can support your application management requirements. Both `workload type` and `trait` are capabilities defined in KubeVela.
|
||||
|
||||
## Service
|
||||
A service represents the runtime configurations (i.e., workload type and traits) needed to run your application in Kubernetes. Service is the descriptor of a basic deployable unit in KubeVela.
|
||||
|
||||
## Application
|
||||
An application in KubeVela is a collection of services which describes what a developer tries to build and ship from high level. An example could be an "website" application which is composed of two services "frontend" and "backend", or a "wordpress" application which is composed of "php-server" and "database".
|
||||
An application in KubeVela is composed by a collection of components named "services". For instance, a "website" application which is composed of two services: "frontend" and "backend".
|
||||
|
||||
An application is defined by an `Appfile` (named `vela.yaml` by default) in KubeVela. Please check its full schema in the [Appfile reference documentation](developers/references/devex/appfile.md).
|
||||
Under the hood, KubeVela introduced a Kubernetes [Custom Resource Definition (CRD)](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) named `Application` to capture all needed information to define an app. A simple `application-sample` is as below:
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1alpha2
|
||||
kind: Application
|
||||
metadata:
|
||||
name: application-sample
|
||||
spec:
|
||||
components: # defines two services in this app
|
||||
- name: backend # 1st service
|
||||
type: worker
|
||||
settings:
|
||||
image: "busybox"
|
||||
cmd:
|
||||
- sleep
|
||||
- "1000"
|
||||
traits:
|
||||
- name: autoscaler
|
||||
properties:
|
||||
min: 1
|
||||
max: 10
|
||||
- name: frontend # 2nd service
|
||||
type: webservice
|
||||
settings:
|
||||
image: "nginx"
|
||||
```
|
||||
|
||||
### Why Application?
|
||||
|
||||
- Provide a single source of truth of the application description.
|
||||
- The `Application` object allows developers to work with a single artifact to capture the application definition. It simplifies administrative tasks and also serves as an anchor to avoid configuration drifts during operation. This is extremely useful in application delivery workflow as well as GitOps.
|
||||
- Lower the learning curve of developers.
|
||||
- The `Application` as a abstraction layer provides a much simpler path for on-boarding Kubernetes capabilities without relying on low level details. For instance, a developer will be able to model the auto-scaling requirements without referring to the underlying [KEDA ScaleObject](https://keda.sh/docs/2.0/concepts/scaling-deployments/#scaledobject-spec).
|
||||
|
||||
### Workload & Trait
|
||||
Each service in the application is modeled by two sections: workload settings and trait properties.
|
||||
|
||||
The workload settings section represents the characteristics that runtime infrastructure should take into account to instantiated and deploy this service. Typical workload types including "long running service" and "one-time off task".
|
||||
|
||||
The trait properties section represents optional configurations that attaches to an instance of given workload type. Traits augment a workload instance with operational features such as load balancing policy, network ingress routing, circuit breaking, rate limiting, auto-scaling policies, upgrade strategies, and many more.
|
||||
|
||||
Note that the schema of both workload settings and trait properties are enforced by modularized capability providers, not by the schema of `Application` CRD. This will be detailed explained in `Capability Modules` section.
|
||||
|
||||
## Appfile
|
||||
|
||||
KubeVela provided a client-side tool named `Appfile` to help developers design and describe an application with ease. A simple `Appfile` sample is as below:
|
||||
|
||||
```yaml
|
||||
name: testapp
|
||||
|
||||
services:
|
||||
frontend: # 1st service
|
||||
image: oamdev/testapp:v1
|
||||
|
||||
build:
|
||||
docker:
|
||||
file: Dockerfile
|
||||
context: .
|
||||
|
||||
cmd: ["node", "server.js"]
|
||||
port: 8080
|
||||
|
||||
route: # a route trait
|
||||
domain: example.com
|
||||
rules:
|
||||
- path: /testapp
|
||||
rewriteTarget: /
|
||||
|
||||
backend: # 2nd service
|
||||
type: task
|
||||
image: perl
|
||||
cmd: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
|
||||
```
|
||||
|
||||
It's by design that `Appfile` is a developer facing tool to render `Application` as well as any other needed Kubernetes resources to ship this app, for example `Secret` and `ConfigMap`. This also means `Appfile` is a superset of `Application`, for example, developers can define a `build` section in `Appfile` which is not part of `Application` CRD.
|
||||
|
||||
For full schema of `Appfile`, please check its [ reference documentation](developers/references/devex/appfile.md) for more detail.
|
||||
|
||||
## Capability Modules
|
||||
A capability is a functionality provided by the runtime infrastructure (i.e. Kubernetes) that can support your application management requirements. Both `workload types` and `traits` are common capabilities used in KubeVela.
|
||||
|
||||
The capabilities are designed as pluggable modules named "capability definitions", for example, [workload definition](https://github.com/oam-dev/spec/blob/master/4.workload_definitions.md) and [trait definition](https://github.com/oam-dev/spec/blob/master/6.traits.md). KubeVela as the platform builder tool will be responsible for registering, discovering and managing these capabilities following OAM specification.
|
||||
|
||||
## Environment
|
||||
Before releasing an application to production, it's important to test the code in testing/staging workspaces. In KubeVela, we describe these workspaces as "deployment environments" or "environments" for short. Each environment has its own configuration (e.g., domain, Kubernetes namespace, configuration data, access control policy etc.) to allow user to create different deployment environments such as "test" and "production".
|
||||
Before releasing an application to production, it's important to test the code in testing/staging workspaces. In KubeVela, we describe these workspaces as "deployment environments" or "environments" for short. Each environment has its own configuration (e.g., domain, Kubernetes cluster and namespace, configuration data, access control policy etc.) to allow user to create different deployment environments such as "test" and "production".
|
||||
|
||||
## What's Next
|
||||
|
||||
Now that you have grasped the core ideas of KubeVela. Here are some recommended next steps:
|
||||
|
||||
- Continue to try out [more tutorials](developers/learn-appfile.md)
|
||||
- Learn how to build platforms with KubeVela following its [platform builder guide](platform-engineers/overview.md)
|
||||
- Learn more about KubeVela through its [platform builder guide](platform-engineers/overview.md)
|
||||
- Continue to try out [end user tutorials](developers/learn-appfile.md) to experience what KubeVela can be used to build
|
||||
+4
-5
@@ -86,11 +86,10 @@ Keywords: _self-service_, _on-demand_, _fast-feedback_
|
||||
|
||||
In the server side, KubeVela components are essentially the [Control Plane Objects](https://github.com/oam-dev/spec/blob/master/2.overview_and_terminology.md#control-plane-objects) defined in OAM specification. On top of those, KubeVela creates a lightweight user facing layer with the following goals:
|
||||
|
||||
- Lower the learning curve of new developers. Most of the capabilities in Kubernetes are developed by
|
||||
companies that run complex workloads. The Kubevela user facing layer provides a much simpler path for on-boarding these capabilities.
|
||||
- Developers can describe their applications and the behaviors of their components without relying on Kubernetes APIs. For instance, a developer will be able to model the auto-scaling requirements without referring to the underline auto-scaler CRD.
|
||||
- Provide a single source of truth of the application description. The user facing layer allows developers to work with a single artifact to capture the application definition. It simplifies administrative tasks and also serves as an anchor to avoid configuration drifts during operation.
|
||||
- To be highly extensible. For example, when a new workload type or trait is installed, the end users could access this new capability directly from the user interface layer, no recompilation or redeployment of KubeVela is required.
|
||||
- Provide a single source of truth of the application description.
|
||||
- Lower the learning curve of new developers.
|
||||
- With abstraction, i.e. developers can describe their applications and the behaviors of their components without relying on Kubernetes APIs.
|
||||
- No abstraction lock.
|
||||
|
||||
#### Solution
|
||||
|
||||
|
||||
+15
-17
@@ -4,41 +4,39 @@
|
||||
|
||||
## Motivation
|
||||
|
||||
The trend of cloud-native technology is moving towards pursuing consistent application delivery across clouds and on-premises infrastructures using Kubernetes as the common abstraction layer. Kubernetes, although excellent in abstracting low-level infrastructure details, does introduce extra complexity to application developers, namely understanding the concepts of pods, port exposing, privilege escalation, resource claims, CRD, and so on. We’ve seen the nontrivial learning curve and the lack of developer-facing abstraction have impacted user experiences, slowed down productivity, led to unexpected errors or misconfigurations in production. People start to question the value of this revolution: "why am I bothered with these many YAML files?".
|
||||
The trend of cloud-native technology is moving towards pursuing consistent application delivery across clouds and on-premises infrastructures using Kubernetes as the common abstraction layer. Kubernetes, although excellent in abstracting low-level infrastructure details, does introduce extra complexity to application developers, namely understanding the concepts of pods, port exposing, privilege escalation, resource claims, CRD, and so on. We’ve seen the nontrivial learning curve and the lack of developer-facing abstraction have impacted user experiences, slowed down productivity, led to unexpected errors or misconfigurations in production. People start to question the value of this revolution: "why am I bothered with all these details?".
|
||||
|
||||
On the other hand, abstracting Kubernetes to serve developers' requirements is a highly opinionated process, and the resultant abstractions would only make sense had the decision makers been the platform builders. Unfortunately, the platform builders today face the following dilemma:
|
||||
|
||||
*There is no tool or framework for them to easily extend the abstractions if any*.
|
||||
*There is no tool or framework for them to easily build user friendly yet highly extensible platforms*.
|
||||
|
||||
Thus, many platforms today introduce restricted abstractions and add-on mechanisms despite the extensibility of Kubernetes. This makes extending such platforms for developers' requirements or to wider scenarios almost impossible, not to mention taking the full advantage of the rich Kubernetes ecosystems.
|
||||
Thus, many platforms today are essentially restricted abstractions with in-house add-on mechanisms despite the extensibility of Kubernetes. This makes extending such platforms for developers' requirements or to wider scenarios almost impossible, not to mention taking the full advantage of the rich Kubernetes ecosystems.
|
||||
|
||||
In the end, developers complain those platforms are too rigid and slow in response to feature requests or improvements. The platform builders do want to help but the engineering effort is daunting: any simple API change in the platform could easily become a marathon negotiation around the opinionated abstraction design.
|
||||
|
||||
## What is KubeVela?
|
||||
|
||||
For developers, KubeVela itself is an easy-to-use tool that enables them to describe and ship their applications to Kubernetes with minimal effort. Instead of managing a handful Kubernetes YAML files, a simple docker-compose style [Appfile](/en/developers/learn-appfile.md) is all they need, following an application-centric workflow that can be easily integrated with any CI/CD pipeline.
|
||||
For platform builders, KubeVela serves as a framework that empowers them to create user friendly yet highly extensible platforms at ease. In details, KubeVela relieves the pains of building such platforms by doing the following:
|
||||
|
||||
The above experience cannot be achieved without KubeVela's innovative offerings to the platform builders.
|
||||
|
||||
For platform builders, KubeVela serves as a framework that empowers them to create developer facing yet highly extensible platforms at ease. In details, KubeVela relieves the pains of building such platforms by doing the following:
|
||||
|
||||
- Application Centric. Behind the Appfile, KubeVela enforces an **application** concept as its main API and **ALL** KubeVela's capabilities serve for the applications' requirements only. This is achieved by adopting the [Open Application Model](https://github.com/oam-dev/spec) as the core API for KubeVela.
|
||||
- Application Centric. KubeVela enforces an **application** concept as its main API and **ALL** KubeVela's capabilities serve for the applications' requirements only. This is achieved by adopting the [Open Application Model](https://github.com/oam-dev/spec) as the core API for KubeVela.
|
||||
|
||||
- Extending Natively. An application in KubeVela is composed of various pluggable workload types and operation features (i.e. traits). Capabilities from Kubernetes ecosystem can be added to KubeVela as new workload types or traits through Kubernetes CRD registry mechanism at any time.
|
||||
- Extending Natively. An application in KubeVela is composed of various modularized components (named: services). Capabilities from Kubernetes ecosystem can be added to KubeVela as new workload types or traits through Kubernetes CRD registry mechanism at any time.
|
||||
|
||||
- Simple yet Extensible Abstraction Mechanism. KubeVela's main user interfaces （i.e. Appfile and CLI) are built using a [CUELang](https://github.com/cuelang/cue) based abstraction engine which translates the user-facing schemas to the underline Kubernetes resources. KubeVela provides a set of built-in abstractions to start with and the platform builders are free to modify them at any time. Abstraction changes take effect at runtime, neither recompilation nor redeployment of KubeVela is required.
|
||||
- Simple yet Extensible Abstraction Mechanism. KubeVela introduced a templating engine (supports [CUELang](https://github.com/cuelang/cue) and more) to abstract user-facing schemas from the underline Kubernetes resources. KubeVela provides a set of built-in abstractions to start with and the platform builders are free to modify them at any time. Abstraction changes take effect at runtime, neither recompilation nor redeployment of KubeVela is required.
|
||||
|
||||
With KubeVela, platform builders now finally have the tooling support to design and ship any new capabilities to their end-users with high confidence and low turn around time.
|
||||
|
||||
For developers, such platforms built with KubeVela will enable them to design and ship their applications to Kubernetes with minimal effort. Instead of managing a handful infrastructure details, a simple application definition is all they need, following an developer centric workflow that can be easily integrated with any CI/CD pipeline.
|
||||
|
||||
## Comparisons
|
||||
|
||||
### Platform-as-a-Service (PaaS)
|
||||
|
||||
The typical examples are Heroku and Cloud Foundry. They provides full application management capabilities and aim to improve developer experience and efficiency. KubeVela shares the same goal but its built-in features are much lighter and easier to maintain compared to most of the existing PaaS offerings. KubeVela core components are nothing but a set of Kubernetes controllers/plugins.
|
||||
The typical examples are Heroku and Cloud Foundry. They provides full application management capabilities and aim to improve developer experience and efficiency. In this context, KubeVela can provide similar experience but its built-in features are much lighter and easier to maintain compared to most of the existing PaaS offerings. KubeVela core components are nothing but a set of Kubernetes controllers/plugins.
|
||||
|
||||
Though the biggest difference lies in the extensibility.
|
||||
Though the biggest difference lies KubeVela positions itself as the engine to build "PaaS-like" systems, not a PaaS offering.
|
||||
|
||||
Most PaaS systems enforce constraints in the type of supported applications and the supported capabilities. They are either inextensible or create their own addon systems maintained by the their own communities. In contrast, KubeVela is designed to fully leverage the Kubernetes ecosystem as its capability pool. Hence, there's no additional addon system is introduced in this project. A new capability can be installed in KubeVela at any time by simply registering the CRD and providing a CUElang template.
|
||||
KubeVela is designed as a core engine whose primary goal is to enable platform team to create "PaaS-like" experience by simply registering CRD and defining templates. Comparing to this experience, most existing PaaS systems are either inextensible or have their own addon systems. Hence it's common for them to enforce constraints in the type of supported applications and the supported capabilities which will not happen in KubeVela based experience.
|
||||
|
||||
### Serverless platforms
|
||||
|
||||
@@ -54,10 +52,10 @@ KubeVela can be integrated into Waypoint like any other supported platforms. In
|
||||
|
||||
### Helm, etc.
|
||||
|
||||
Helm is a package manager for Kubernetes that provides package, install, and upgrade a set of YAML files for Kubernetes as a unit.
|
||||
Helm is a package manager for Kubernetes that provides package, install, and upgrade a set of YAML files for Kubernetes as a unit. KubeVela leverages Helm heavily as the package format for capabilities and dependencies.
|
||||
|
||||
KubeVela is not a package manager. Developers are expected to use KubeVela's Appfile to describe how to build and deploy application and that Appfile is not Kubernetes YAML format. However, the server side API object behind Appfile (i.e. `Application Configuration`) is indeed a Kubernetes CRD, it could be packaged and distributed by Helm at ease.
|
||||
Though KubeVela itself is not a package manager, it's a core engine for platform builders to create upper layer platforms in easy and repeatable approach.
|
||||
|
||||
### Kubernetes
|
||||
|
||||
KubeVela is a Kubernetes plugin for building application-centric abstractions. It leverages the native Kubernetes extensibility and capabilities to resolve a hard problem - making application management enjoyable on Kubernetes.
|
||||
KubeVela is a Kubernetes plugin for building upper layer platforms. It leverages the native Kubernetes extensibility and capabilities to resolve a hard problem - making shipping applications enjoyable on Kubernetes.
|
||||
|
||||
@@ -0,0 +1,3 @@
|
||||
# KubeVela for Platform Builders
|
||||
|
||||
TBD: this documentation is still work in progress.
|
||||
@@ -73,8 +73,8 @@ Hello World
|
||||
|
||||
Congratulations! You have just deployed an app using KubeVela. Here are some recommended next steps:
|
||||
|
||||
- Try out more [tutorials](developers/learn-appfile.md)
|
||||
- Learn about KubeVela's [core concepts](https://kubevela.io/#/en/concepts) in detail
|
||||
- Join our community [Slack](https://cloud-native.slack.com/archives/C01BLQ3HTJA) and/or [Gitter](https://gitter.im/oam-dev/community)
|
||||
- Try out more [end user guides](developers/learn-appfile.md)
|
||||
- Learn about KubeVela in detail starting from its [core concepts](concepts)
|
||||
- Join `#kubevela` channel in CNCF [Slack](https://cloud-native.slack.com) and/or [Gitter](https://gitter.im/oam-dev/community)
|
||||
|
||||
Welcome onboard and sail Vela!
|
||||
|
||||
@@ -47,5 +47,6 @@ services:
|
||||
# timezone: "America/Los_Angeles"
|
||||
|
||||
# pi:
|
||||
# type: task
|
||||
# image: perl
|
||||
# cmd: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 190 KiB |
Reference in New Issue
Block a user