refine concept and quick start
Signed-off-by: Jianbo Sun <jianbo.sjb@alibaba-inc.com>
This commit is contained in:
Jianbo Sun
parent
c602acfab9
commit
0848903867
|
|
@ -1,39 +1,76 @@
|
|||
---
|
||||
title: Core Concept
|
||||
title: Application
|
||||
---
|
||||
|
||||
KubeVela revolves around cloud-native application delivery and management scenarios. The application delivery model behind it is [Open Application Model](../platform-engineers/oam/oam-model), or OAM for short. It describes various components and operational traits required for application as a unified, and infrastructure-independent "deployment plan". As a result, we can achieve standardized and efficient application delivery in a multi-cloud/hybrid-cloud environment. KubeVela includes the following core concepts:
|
||||
KubeVela revolves around cloud-native application delivery scenarios. The application delivery model behind it is [Open Application Model](https://oam.dev/), or OAM for short.
|
||||
|
||||
## An Abstraction to Model Application Deployment Process
|
||||
|
||||
OAM allows end users to work with a simple artifact to capture the complete application deployment workflow with easier primitives. This provides a simpler path for on-boarding end users to the platform without leaking low level details in runtime infrastructure and allows users to fully focus on the application delivery itself.
|
||||
|
||||
|
||||
|
||||
Every application deployment plan can be composed by multiple components with attachable operational behaviors (traits), deployment policy and workflow. It works in the following format:
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: <name>
|
||||
spec:
|
||||
components:
|
||||
- name: <component name>
|
||||
type: <component type>
|
||||
properties:
|
||||
<parameter values>
|
||||
traits:
|
||||
- type: <trait type>
|
||||
properties:
|
||||
<traits parameter values>
|
||||
- name: <component name>
|
||||
type: <component type>
|
||||
properties:
|
||||
<parameter values>
|
||||
policies:
|
||||
- name: <policy name>
|
||||
type: <policy type>
|
||||
properties:
|
||||
<policy parameter values>
|
||||
workflow:
|
||||
- name: <step name>
|
||||
type: <step type>
|
||||
properties:
|
||||
<step parameter values>
|
||||
```
|
||||
|
||||
This `Application` entity will reference `component`, `trait`, `policy` and `workflow step` types which are essentially programmable modules that are maintained by platform team. Hence, this abstraction is highly extensible and can be customized in-place at ease.
|
||||
|
||||
* **Component**: A Component defines the delivery artifact (binary, Docker image, Helm Chart...) or cloud service included in one application. As we will regard an application as a microservice business unit, the best practice is to having one component as the core and the others are dependencies with a maximum number under control.
|
||||
|
||||
* **Trait**: Traits are management requirements of an artifact that can be declared with each Component. For example: scale and rollout strategy, persistent storage claim, gateway endpoint and so on.
|
||||
|
||||
* **Policy**: Policy defines a strategy of certain aspect for application as to multi-cluster topology, configuration overrides, security/firewall rules, SLO and etc. It's a bit similar with traits but take affects to the whole application instead of one component.
|
||||
|
||||
* **Workflow Step**: Workflow step allows you to define every steps in the delivery process, typical steps are manual approval, partial deploy, notification.
|
||||
|
||||
The modules that make up the application are all extensible, they are defined by a bunch of programmable configurations called [Definitions](../platform-engineers/oam/x-definition). Under the hood, KubeVela will glue and leverage Kubernetes API to drive the infrastructure capabilities. You can check the following picture to see their relationships:
|
||||
|
||||
|
||||
|
||||
## Application
|
||||
## Package for programmable capabilities
|
||||
|
||||
An application defines the delivery and management requirements of an artifact (binary, Docker image, Helm Chart...) or cloud service included in a microservice business unit. It consists of four parts: [Component](#component), [Trait](#trait), [Workflow](#workflow) and [Policy](#policy).
|
||||
A package of OAM Definitions and [Kubernetes CRD Controller](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) is called an `Addon`. KubeVela has a large and growing [catalog](https://github.com/kubevela/catalog) of addons to support modern application delivery, such as [terraform](https://github.com/kubevela/catalog/tree/master/addons/terraform) for cloud resource provisioning, [OCM](https://github.com/kubevela/catalog/tree/master/addons/ocm-hub-control-plane) for multi-cluster management, [fluxcd](https://github.com/kubevela/catalog/tree/master/addons/fluxcd) for gitops, and etc.
|
||||
|
||||
### Component
|
||||
With these addons, KubeVela provides a unified and good experience for developers to deliver modern application in a multi-cloud/hybrid-cloud environment.
|
||||
|
||||
Component defines the artifact of application，The best practice is to having one core component and subordinate components around it. Its type decided by [Component Definition](../platform-engineers/oam/x-definition#componentdefinition) .
|
||||
## No Configuration Drift
|
||||
|
||||
### Trait
|
||||
Despite the efficiency and extensibility in abstracting application deployment, programmable (Infrastructure-as-Code) approach may lead to an issue called *Infrastructure/Configuration Drift*, i.e. the rendered component instances are not in line with the expected configuration. This could be caused by incomplete coverage, less-than-perfect processes or emergency changes. This makes them can be barely used as a platform level building block.
|
||||
|
||||
Traits are plugable operations that can attach to Component, for example: scaler for replicas(manual and auto), PVC, gateway, DNS and so on. You can draw out-of-box Trait from the ecosystem or simply customize by [Trait Definition](../platform-engineers/oam/x-definition#traitdefinition).
|
||||
Hence, KubeVela is designed to maintain all these programmable capabilities with [Kubernetes Control Loop](https://kubernetes.io/docs/concepts/architecture/controller/) and leverage Kubernetes control plane to eliminate the issue of configuration drifting, while still keeps the flexibly and velocity enabled by IaC.
|
||||
|
||||
### Workflow
|
||||
|
||||
Workflow allows you to define critical step in the process of application delivery, typical steps will be manual approve, data passing, release across multi-cluster, notification and etc. Its type can be defined and customized by [Workflow Step Definition](../platform-engineers/oam/x-definition#workflowstepdefinition).
|
||||
|
||||
### Policy
|
||||
|
||||
Policy defines a strategy of certain aspect for application as to quality assurance, security, firewall rules, SLO and etc. Its type can be defined and customized by [Policy Definition](../platform-engineers/oam/x-definition#policydefinition).
|
||||
|
||||
## Cluster
|
||||
|
||||
Import and manage your Kubernetes cluster in KubeVela。Kubernetes cluster is one of the main way for KubeVela application delivery.
|
||||
|
||||
## Addon
|
||||
|
||||
Addon is where you can freely pull in third-party capability that fulfills your need. This relies on the highly scalable design pattern of KubeVela. Each Addon will have its own [X-Definition](../platform-engineers/oam/x-definition).
|
||||
|
||||
## Next Step
|
||||
|
||||
- Learn [Definition](./definition) concept to understand how the extension mechanism works.
|
||||
- View [Architecture](./architecture) to learn the overall architecture of KubeVela.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,36 @@
|
|||
---
|
||||
title: Definition
|
||||
---
|
||||
|
||||
Definition are the basic building block of the KubeVela platform. A definition encapsulates an arbitrarily complex automation as a lego style module that can be used to compose an Application, then safely shared, and repeatably executed by any KubeVela engine.
|
||||
|
||||
There're four types of Definition, they're `ComponentDefinition`, `TraitDefinition`, `PolicyDefinition` and `WorkflowStepDefinition`, corresponding to the application concepts.
|
||||
|
||||
## Sources of Definitions
|
||||
|
||||
There're two sources of definitions:
|
||||
|
||||
* Built-in definitions will be installed along with KubeVela helm chart. You can refer to the following links to learn more about built-in definitions.
|
||||
- [Component Definition](../end-user/components/references)
|
||||
- [Trait Definition](../end-user/traits/references)
|
||||
- [Policy Definition](../end-user/policies/references)
|
||||
- [Workflow Step Definition](../end-user/workflow/built-in-workflow-defs)
|
||||
* Installation of addons will install definitions if there're new capabilities contained. You can refer to [the official addon registry](../reference/addons/overview) for more details.
|
||||
|
||||
## Lifecycle of a Definition
|
||||
|
||||
A definition's lifecycle usually has 3 stages:
|
||||
|
||||
### Discovery
|
||||
|
||||
### Use
|
||||
|
||||
### Customize
|
||||
|
||||
> ⚠️ In most cases, you don't need to customize any definitions unless you're going to extend the capability of KubeVela. Before that, you should check the built-in definitions and addons to confirm if they can fit your needs.
|
||||
|
||||
A new definition is built in a declarative template in [CUE configuration language](https://cuelang.org/). If you're not familiar with CUE, you can refer to [CUE Basic](../platform-engineers/cue/basic) for some knowledge.
|
||||
|
||||
## Next Step
|
||||
|
||||
- View [Architecture](./architecture) to learn the overall architecture of KubeVela.
|
||||
|
|
@ -6,8 +6,7 @@ slug: /
|
|||
## What is KubeVela?
|
||||
|
||||
KubeVela is a modern software delivery platform that makes it easier and faster to deliver and manage applications across hybrid, multi-cloud environments.
|
||||
|
||||
Using KubeVela, software teams can build cloud native applications per needs as they grow, then deliver them anywhere.
|
||||
Applications created with KubeVela use the best practices of modern applications by default: they are able to scale with clouds, they use infrastructure as code, they are observable, and they are secure.
|
||||
|
||||
|
||||
|
||||
|
|
@ -16,15 +15,23 @@ Using KubeVela, software teams can build cloud native applications per needs as
|
|||
|
||||
* **Unified Application Delivery Experience**
|
||||
|
||||
KubeVela introduces a [unified and cross-platform delivery model(OAM)](https://oam.dev/) that allows you to deploy any workload type, including containers, databases, or even VM instances to any cloud or Kubernetes clusters. It helps you to just write application once, and deliver it the same everywhere, no more re-writing everything from scratch for any new delivery target.
|
||||
KubeVela introduces a [unified and extensible model (OAM)](https://oam.dev/) that can glue and orchestrate all of your IaC based infrastructure configuration. As a result, KubeVela provides simple user experience for modern application delivery.
|
||||
|
||||
* **Automated Deployment across Clusters**
|
||||
|
||||
KubeVela natively supports rich continuous delivery strategies in various multi-cluster/hybrid-cloud scenarios or mixed environments. These strategies provides efficiency and safety to the distributed delivery process. The centralized management reduces the burden of looking over each clusters and gives unified experience across platforms. With KubeVela, you don't need to have any Ph.D. degree in Kubernetes to run automatic deployments.
|
||||
KubeVela natively supports multi-cluster/hybrid-cloud scenarios such as promotion across clusters, high availability between clusters, automated cloud infrastructure provision.
|
||||
|
||||
* **Enterprise-Grade Security**
|
||||
|
||||
KubeVela provides enterprise-grade security with fine-grained and custom RBAC, multi-cluster authorization, and first-class LDAP integrations.
|
||||
|
||||
* **Centralized Management and Observability**
|
||||
|
||||
KubeVela provides a unified control plane for modeling, provisioning, and deploying applications. The centralized management reduces the burden of looking over each clusters and gives unified experience across platforms. It greatly improve efficiency around troubleshooting and debugging when things go wrong.
|
||||
|
||||
* **Declarative and Highly Extensible Workflow**
|
||||
|
||||
The application delivery process is driven by declarative workflow. Executed by reconciliation loops with limited privileges, the workflow is both robust and secure enough to prevent any unexpected configuration drifts. Users can also make arbitrary reusable customizations to the workflow through writing CUE definitions. The extensibility will always satisfy your growing business demands while keeping your production safe with continuous enforcement at the same time.
|
||||
KubeVela drives the delivery process with a declarative workflow, it provides automated canary and blue-green deployments with verification and rollback. After the workflow finished, it keeps the reconciliation loops to prevent any unexpected configuration drifts.
|
||||
|
||||
|
||||
## KubeVela vs. Other Software
|
||||
|
|
|
|||
|
|
@ -2,53 +2,4 @@
|
|||
title: Introduction
|
||||
---
|
||||
|
||||
This and next documentation will explain Open Application Model (OAM) and how to extend this model in detail.
|
||||
|
||||
## An Abstraction to Model Application Deployment Process
|
||||
|
||||
OAM allows end users to work with a simple artifact to capture the complete application deployment workflow with easier primitives. This provides a simpler path for on-boarding end users to the platform without leaking low level details in runtime infrastructure and allows users to fully focus on the application delivery itself.
|
||||
|
||||
|
||||
|
||||
Every application deployment plan can be composed by multiple components with attachable operational behaviors (traits), the deployment policy and workflow. For example:
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: <name>
|
||||
spec:
|
||||
components:
|
||||
- name: <component name>
|
||||
type: <component type>
|
||||
properties:
|
||||
<parameter values>
|
||||
traits:
|
||||
- type: <trait type>
|
||||
properties:
|
||||
<traits parameter values>
|
||||
- name: <component name>
|
||||
type: <component type>
|
||||
properties:
|
||||
<parameter values>
|
||||
policies:
|
||||
- name: <policy name>
|
||||
type: <policy type>
|
||||
properties:
|
||||
<policy parameter values>
|
||||
workflow:
|
||||
- name: <step name>
|
||||
type: <step type>
|
||||
properties:
|
||||
<step parameter values>
|
||||
```
|
||||
|
||||
This `Application` entity will reference component, trait, policy and workflow step types which are essentially programmable modules that are maintained by platform team. Hence, this abstraction is highly extensible and can be customized in-place at ease.
|
||||
|
||||
Please check the next section ([X-Definition](./x-definition.md)) to learn how this programmable capability is achieved.
|
||||
|
||||
## No Configuration Drift
|
||||
|
||||
Despite the efficiency and extensibility in abstracting application deployment, programmable (Infrastructure-as-Code) approach may lead to an issue called *Infrastructure/Configuration Drift*, i.e. the rendered component instances are not in line with the expected configuration. This could be caused by incomplete coverage, less-than-perfect processes or emergency changes. This makes them can be barely used as a platform level building block.
|
||||
|
||||
Hence, KubeVela is designed to maintain all these programmable capabilities with [Kubernetes Control Loop](https://kubernetes.io/docs/concepts/architecture/controller/) and leverage Kubernetes control plane to eliminate the issue of configuration drifting, while still keeps the flexibly and velocity enabled by IaC.
|
||||
This doc has been migrated, please refer to [Application Concept](../../getting-started/core-concept).
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
---
|
||||
title: X-Definition
|
||||
title: Definition Protocol
|
||||
---
|
||||
|
||||
KubeVela is fully programmable via [CUE](https://cuelang.org).
|
||||
|
||||
This is achieved by implementing its [application model][1] as programmable entities (named `X-Definition`) include `ComponentDefinition`, `TraitDefinition`, `PolicyDefinition` and `WorkflowStepDefinition` etc as shown below.
|
||||
This is achieved by implementing its [application model][1] as programmable entities (named `Definition`) include `ComponentDefinition`, `TraitDefinition`, `PolicyDefinition` and `WorkflowStepDefinition` as shown below.
|
||||
|
||||
## ComponentDefinition
|
||||
|
||||
|
|
@ -365,9 +365,9 @@ Once the application is created, KubeVela will tag the created resources with a
|
|||
| `trait.oam.dev/resource` | `outputs.\<resource type\>`in Trait |
|
||||
| `app.oam.dev/appRevision` | Application Revision Name |
|
||||
|
||||
## X-Definition Runtime Context
|
||||
## Definition Runtime Context
|
||||
|
||||
In the X-Definition, some runtime context information can be obtained through the `context` variable. The specific list is as follows, where the scope indicates which module definitions the Context variable can be used in:
|
||||
In the Definition, some runtime context information can be obtained through the `context` variable. The specific list is as follows, where the scope indicates which module definitions the Context variable can be used in:
|
||||
|
||||
| Context Variable | Description | Scope |
|
||||
| :------------------------------: | :------------------------------------------------------------------------------: | :----------------------------------: |
|
||||
|
|
@ -391,7 +391,7 @@ At the same time, in the Workflow system, because the `context` has to act on th
|
|||
| `context.annotations` | The annotations of the current instance of the application | WorkflowStepDefinition |
|
||||
|
||||
|
||||
Please note that all the X-Definition concepts introduced in this section only need to be understood by the platform administrator when they want to expand the functions of KubeVela. The end users will learn the schema of above definitions with visualized forms (or the JSON schema of parameters if they prefer) and reference them in application deployment plan. Please check the [Generate Forms from Definitions](../openapi-v3-json-schema) section about how this is achieved.
|
||||
Please note that all the Definition concepts introduced in this section only need to be understood by the platform administrator when they want to expand the functions of KubeVela. The end users will learn the schema of above definitions with visualized forms (or the JSON schema of parameters if they prefer) and reference them in application deployment plan. Please check the [Generate Forms from Definitions](../openapi-v3-json-schema) section about how this is achieved.
|
||||
|
||||
[1]: ./oam-model
|
||||
[2]: ../cue/basic
|
||||
|
|
|
|||
|
|
@ -209,5 +209,5 @@ That's it! You succeed at the first application delivery. Congratulation!
|
|||
|
||||
## Next Step
|
||||
|
||||
- View [Core Concepts](./getting-started/core-concept) to look on more concepts.
|
||||
- View [Core Concepts](./getting-started/core-concept) to learn more about how it works.
|
||||
- View [User Guide](./tutorials/webservice) to look on more of what you can achieve with KubeVela.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,9 @@
|
|||
---
|
||||
title: Built-in Addons
|
||||
title: Overview
|
||||
---
|
||||
|
||||
There's an official addon registry (https://addons.kubevela.net) maintained by KubeVela team. It contains following addons:
|
||||
|
||||
* [VelaUX](./velaux): The KubeVela User Experience (UX ) addon. It will launch a dashboard and an APIServer for better user experience.
|
||||
* [Addon Cloud Resources](./terraform): Provide a bunch of addons to provision cloud resources for different cloud providers.
|
||||
* [Machine Learning Addon](./ai): Machine learning addon is divided into model-training addon and model-serving addon.
|
||||
|
|
|
|||
|
|
@ -211,8 +211,8 @@
|
|||
"message": "资源管理",
|
||||
"description": "管理集群和交付目标等资源"
|
||||
},
|
||||
"sidebar.docs.category.Built-in Addons": {
|
||||
"message": "内置插件",
|
||||
"sidebar.docs.category.Official Addons": {
|
||||
"message": "官方插件",
|
||||
"description": "内置插件说明"
|
||||
},
|
||||
"sidebar.docs.category.Cloud Resources": {
|
||||
|
|
@ -251,8 +251,8 @@
|
|||
"message": "其他高级功能",
|
||||
"description": "其他高级功能"
|
||||
},
|
||||
"sidebar.docs.category.Basics": {
|
||||
"message": "基本概念",
|
||||
"sidebar.docs.category.Core Concepts": {
|
||||
"message": "核心概念",
|
||||
"description": "Basic information"
|
||||
},
|
||||
"sidebar.docs.category.Artifacts": {
|
||||
|
|
|
|||
|
|
@ -251,8 +251,8 @@
|
|||
"message": "其他高级功能",
|
||||
"description": "其他高级功能"
|
||||
},
|
||||
"sidebar.docs.category.Basics": {
|
||||
"message": "基础内容",
|
||||
"sidebar.docs.category.Core Concepts": {
|
||||
"message": "核心概念",
|
||||
"description": "Basic information"
|
||||
},
|
||||
"sidebar.docs.category.Deploy with more workload type": {
|
||||
|
|
|
|||
28
sidebars.js
28
sidebars.js
|
|
@ -10,9 +10,13 @@ module.exports = {
|
|||
},
|
||||
{
|
||||
type: 'category',
|
||||
label: 'Basics',
|
||||
label: 'Core Concepts',
|
||||
collapsed: true,
|
||||
items: ['getting-started/core-concept', 'getting-started/architecture'],
|
||||
items: [
|
||||
'getting-started/core-concept',
|
||||
'getting-started/definition',
|
||||
'getting-started/architecture',
|
||||
],
|
||||
},
|
||||
{
|
||||
type: 'category',
|
||||
|
|
@ -124,15 +128,6 @@ module.exports = {
|
|||
label: 'Extension',
|
||||
collapsed: true,
|
||||
items: [
|
||||
{
|
||||
type: 'category',
|
||||
label: 'Learning OAM',
|
||||
collapsed: false,
|
||||
items: [
|
||||
'platform-engineers/oam/oam-model',
|
||||
'platform-engineers/oam/x-definition',
|
||||
],
|
||||
},
|
||||
{
|
||||
'Learning CUE': [
|
||||
'platform-engineers/cue/basic',
|
||||
|
|
@ -181,9 +176,14 @@ module.exports = {
|
|||
label: 'References',
|
||||
items: [
|
||||
'cli/vela',
|
||||
'platform-engineers/oam/x-definition',
|
||||
'end-user/components/references',
|
||||
'end-user/traits/references',
|
||||
'end-user/policies/references',
|
||||
'end-user/workflow/built-in-workflow-defs',
|
||||
{
|
||||
type: 'category',
|
||||
label: 'Built-in Addons',
|
||||
label: 'Official Addons',
|
||||
items: [
|
||||
'reference/addons/overview',
|
||||
'reference/addons/velaux',
|
||||
|
|
@ -193,10 +193,6 @@ module.exports = {
|
|||
],
|
||||
},
|
||||
'end-user/components/cloud-services/cloud-resources-list',
|
||||
'end-user/components/references',
|
||||
'end-user/traits/references',
|
||||
'end-user/policies/references',
|
||||
'end-user/workflow/built-in-workflow-defs',
|
||||
'reference/ui-schema',
|
||||
'reference/user-improvement-plan',
|
||||
{
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@
|
|||
{
|
||||
"collapsed": true,
|
||||
"type": "category",
|
||||
"label": "Basics",
|
||||
"label": "Core Concepts",
|
||||
"items": [
|
||||
{
|
||||
"type": "doc",
|
||||
|
|
@ -539,4 +539,4 @@
|
|||
"id": "version-v1.3/developers/references/devex/faq"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
Loading…
Reference in New Issue