Fix en docs next (#313)
This commit is contained in:
Lei Zhang (Harry)
GitHub
parent
e204a7d8f3
commit
21ab5091e7
|
|
@ -1,12 +1,12 @@
|
|||
---
|
||||
title: Application
|
||||
title: The Application Model
|
||||
---
|
||||
|
||||
KubeVela takes Application as the basis of modeling, uses Components and Traits to complete a set of application deployment plans. After you are familiar with these core concepts, you can develop in accordance with the user manual and administrator manual according to your needs.
|
||||
KubeVela introduces Open Application Model (OAM) to capture a full deployment of micro-services application across hybrid environments.
|
||||
|
||||
## Application
|
||||
|
||||
In modeling, the YAML file is the bearer of the application deployment plan. A typical YAML example is as follows:
|
||||
With this model, a typical deployment plan in KubeVela looks as below:
|
||||
|
||||
```yaml
|
||||
# sample.yaml
|
||||
|
|
@ -72,21 +72,9 @@ spec:
|
|||
env: prod
|
||||
```
|
||||
|
||||
|
||||
The fields here correspond to:
|
||||
|
||||
- apiVersion: The OAM API version used.
|
||||
- kind: of CRD Resourse Type. The one we use most often is Pod.
|
||||
- metadata: business-related information. For example, this time I want to create a website.
|
||||
- Spec: Describe what we need to deliver and tell Kubernetes what to make. Here we put the `components`, `policies` and `workflow` of KubeVela.
|
||||
- components: KubeVela's component system.
|
||||
- Traits: KubeVela's operation and maintenance feature system, works in component level.
|
||||
- Policies: KubeVela's application level policy.
|
||||
- Workflow: KubeVela's application level deployment workflow, you can custom every deployment step with it.
|
||||
|
||||
## Components
|
||||
|
||||
KubeVela has some built-in component types, you can find them by using [KubeVela CLI](../install#3-get-kubevela-cli):
|
||||
An application could be composed by multiple components. KubeVela already built-in with several widely used components definitions to help you model an application deployment, you can list them by using [KubeVela CLI](../install#3-get-kubevela-cli):
|
||||
|
||||
```
|
||||
vela components
|
||||
|
|
@ -112,14 +100,9 @@ alibaba-oss vela-system configurations.terraform.core.oam.dev Terraform configu
|
|||
alibaba-rds vela-system configurations.terraform.core.oam.dev Terraform configuration for Alibaba Cloud RDS object
|
||||
```
|
||||
|
||||
You can continue to use [Helm](../end-user/components/helm) and [Kustomize](../end-user/components/kustomize) components to deploy your application, an application is a deployment plan.
|
||||
|
||||
If you're a platform builder who's familiar with Kubernetes, you can learn to [define your custom component](../platform-engineers/components/custom-component) to extend every kind of component in KubeVela. Especially, [Terraform Components](../platform-engineers/components/component-terraform) is one of the best practice.
|
||||
|
||||
|
||||
## Traits
|
||||
|
||||
KubeVela also has many built-in traits, search them by using [KubeVela CLI](../install#3-get-kubevela-cli):
|
||||
Traits are operational behaviors that you can attach to component. KubeVela also has built-in traits installed, search them by using [KubeVela CLI](../install#3-get-kubevela-cli):
|
||||
|
||||
```
|
||||
vela traits
|
||||
|
|
@ -137,29 +120,20 @@ scaler vela-system webservice,worker false Manually
|
|||
sidecar vela-system deployments.apps true Inject a sidecar container to the component.
|
||||
```
|
||||
|
||||
You can learn how to bind trait by these detail docs, such as [ingress trait](../end-user/traits/ingress).
|
||||
|
||||
If you're a platform builder who's familiar with Kubernetes, you can learn to [define your custom trait](../platform-engineers/traits/customize-trait) to extend any operational capability for your users.
|
||||
|
||||
## Policy
|
||||
|
||||
Policy allows you to define application level capabilities, such as health check, security group, fire wall, SLO and so on.
|
||||
|
||||
Policy is similar to trait, but trait works for component while policy works for the whole application.
|
||||
Policy enforces deployment process of the application, such as quality gates, security groups, placement strategy, fire walls, SLO targets and so on.
|
||||
|
||||
## Workflow
|
||||
|
||||
In KubeVela, Workflow allows user to glue various operation and maintenance tasks into one process, and achieve automated and rapid delivery of cloud-native applications to any hybrid environment. From the design point of view, the Workflow is to customize the control logic: not only simply apply all resources, but also to provide some process-oriented flexibility. For example, the use of Workflow can help us implement complex operations such as pause, manual verification, waiting state, data flow transmission, multi-environment grayscale, and A/B testing.
|
||||
Workflow allows you to assemble components, operation and task steps into a DAG, and it is process-oriented. Typical workflow steps includes pause, manual verification, waiting state, data flow transmission, multi-environment rollout, and A/B testing, etc.
|
||||
|
||||
The Workflow is based on modular design. Each Workflow module is defined by a Definition CRD and provided to users for operation through K8s API. As a "super glue", the Workflow module can combine any of your tools and processes through the CUE language. This allows you to create your own modules through a powerful declarative language and cloud-native APIs.
|
||||
Each workflow step is a independent capability entity that is fully plugable, KubeVela allows you to create your own step through CUE.
|
||||
|
||||
> Especially, workflow works in application level, if you specify workflow, the resources won't be deployed if you don't specify any step to deploy it.
|
||||
|
||||
If you're a platform builder who's familiar with Kubernetes, you can learn to [define your own workflow step by using CUE](../platform-engineers/workflow/workflow).
|
||||
|
||||
## What's Next
|
||||
|
||||
Here are some recommended next steps:
|
||||
|
||||
- Learn KubeVela's user guide to know how to deploy component, let's start from [helm component](../end-user/components/helm).
|
||||
- Learn KubeVela's admin guide to learn more about [the OAM model](../platform-engineers/oam/oam-model).
|
||||
- Start using KubeVela from deploying [Helm component](../end-user/components/helm).
|
||||
- Learn more about [Open Application Model](../platform-engineers/oam/oam-model).
|
||||
|
|
|
|||
|
|
@ -6,59 +6,34 @@ The overall architecture of KubeVela is shown as below:
|
|||
|
||||
|
||||
|
||||
## KubeVela is a Control Plane System
|
||||
|
||||
## API
|
||||
KubeVela orchestrates application components, cloud resources and pipeline over multiple clusters and hybrid environments. It is designed to be an application delivery and management control plane instead of a runtime plugin.
|
||||
|
||||
The API layer provides KubeVela APIs exposed to users for building application delivery platform and solutions.
|
||||
KubeVela APIs are declarative and application centric.
|
||||
It is based on Kubernetes CRDs to natively fit into the Kubernetes ecosystem.
|
||||
For easy integration with upstream CI pipelines and GitOps tools, KubeVela API (i.e. Open Application Model) are designed as declarative and application-centric, including:
|
||||
|
||||
The APIs can be categorized for two purposes:
|
||||
`Application` for designing application deployment plan.
|
||||
|
||||
- For **end users** to compose final application manifest to deploy.
|
||||
- Usually this contains only user-concerned config and hides infrastructure details.
|
||||
- Users will normally write the manifest in yaml format.
|
||||
- This currently includes Application only. But we may add more user-facing APIs, e.g. ApplicationSet to define multiple Applications.
|
||||
- For **platform admins** to define capability definitions to handle actual operations.
|
||||
- Each definition glues operational tasks using CUE and exposes user-concerned config only.
|
||||
- Admins will normally write the manifest in yaml + CUE format.
|
||||
- This currently includes Component, Trait, Policy, and Workflow definition types.
|
||||
`X-Definitions` for managing the abstraction and capabilities of KubeVela with CUE.
|
||||
- e.g. `ComponentDefinition`, `TraitDefinition`, etc.
|
||||
|
||||
The APIs are served by the control plane.
|
||||
Because it is so important that we put a separate section to talk about it.
|
||||
In implementation, KubeVela relies on a dedicated Kubernetes cluster to achieve above goals. We chose to rely on Kubernetes as the control plane implementation because this approach is battle tested and brings determinism, convergence and automation to application management at scale. In detail, KubeVela is composed by several parts:
|
||||
|
||||
## Control Plane
|
||||
- *Plugin Registry* that registers and manages `X-Definitions`.
|
||||
- *Core Controller* that provides the core control logic of the entire system. For example, handling KubeVela API resources, orchestrating workflow, storing revisions, parsing and executing CUE code, garbage collecting, etc.
|
||||
- *Addon Controllers* that register and manage built-in addons that KubeVela needed to work. For example, Flux and Terraform controller.
|
||||
|
||||
The control plane layers is where KubeVela puts the components central to the entire system.
|
||||
It is the first entry to handle user API requests, the central place to register plugins,
|
||||
and central processor to manage global states and dispatches tasks/resources.
|
||||
This control plane Kubernetes cluster will be referenced as the "control plane cluster" in the following documentation.
|
||||
|
||||
The control plane contains three major parts:
|
||||
### Runtime Infrastructure
|
||||
|
||||
- **Plugin registry** stores and manages X-Definitions.
|
||||
X-Definitions are CRDs that users can apply and get via kubectl.
|
||||
There are additional backend functions to store and manage multiple versions of X-Definitions.
|
||||
- **Core Control** provides the core control logic to the entire system.
|
||||
It consists of the core components that are hanlding Application, X-Definition API requests,
|
||||
orchestrating Workflows, storing revisions of Applications and Components,
|
||||
parsing and executing CUE fields, garbage collecting unused resources.
|
||||
- **Builtin Controllers** registers builtin plugins and provides the backing controllers for the resources
|
||||
created by X-Definitions. These are core to the KubeVela ecosystem that we believe everyone will use.
|
||||
The runtime infrastructure is where the applications are actually running on.
|
||||
KubeVela itself is fully runtime infrastructure agnostic and hence allows you to deploy application to both Kubernetes based infrastructure and non-Kubernetes environments such as cloud platforms and edge devices.
|
||||
|
||||
The control plane (including API layer) is KubeVela per se.
|
||||
Technically speaking, KubeVela is a control plane to manage applications over multiple clusters, hybrid environments.
|
||||
## KubeVela is Programmable
|
||||
|
||||
## Execution
|
||||
In real world, application deployment tends to be complex and varies from teams, environments and scenarios. Hence, KubeVela introduced a fully programmable approach to implement its deployment model so it can adapt to every need of your application delivery use case in-place.
|
||||
|
||||
The execution layer is where the applications are actually running on.
|
||||
KubeVela allows you to deploy and manage application resources in a consistent workflow onto both
|
||||
Kubernetes cluster (e.g. local, managed offerings, IoT/edge, on-prem)
|
||||
and non-Kubernetes environments on clouds.
|
||||
KubeVela itself does not run on the execution infrastructures, but manage them instead.
|
||||
|
||||
|
||||
## What's Next
|
||||
|
||||
Here are some recommended next steps:
|
||||
|
||||
- Learn KubeVela's Application to know the basics of how to building App Delivery, let's start from [Application](./application).
|
||||
- Learn KubeVela's admin guide to learn more about [the OAM model](../platform-engineers/oam/oam-model).
|
||||
For learning how to program KubeVela in detail, please check the `Administrator Manuals` in the documentation site.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Raw
|
||||
title: Raw Template
|
||||
---
|
||||
|
||||
Use raw Kubernetes resources directly. For example, a Job.
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ KubeVela's `kustomize` component meets the needs of users to directly connect Ya
|
|||
Let's take the YAML folder component from the OSS bucket registry as an example to explain the usage. In the `Application` this time, I hope to deliver a component named bucket-comp. The deployment file corresponding to the component is stored in the cloud storage OSS bucket, and the corresponding bucket name is definition-registry. `kustomize.yaml` comes from this address of oss-cn-beijing.aliyuncs.com and the path is `./app/prod/`.
|
||||
|
||||
|
||||
1. (Opentional) If your OSS bucket needs identity verification, create a Secret:
|
||||
1. (Optional) If your OSS bucket needs identity verification, create a Secret:
|
||||
|
||||
```shell
|
||||
$ kubectl create secret generic bucket-secret --from-literal=accesskey=<your-ak> --from-literal=secretkey=<your-sk>
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Want More？
|
||||
title: Needs More？
|
||||
---
|
||||
|
||||
## 1. Get from capability registry
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Multi-Environment Deployment
|
||||
title: Multi-Environment Policy
|
||||
---
|
||||
|
||||
This documentation will introduce how to use env-binding to automate multi-stage application rollout across multiple environments.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Health Status Check
|
||||
title: Health Check Policy
|
||||
---
|
||||
|
||||
This documentation will introduce how to use `health` policy to apply periodical
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Want More?
|
||||
title: Needs More?
|
||||
---
|
||||
|
||||
## 1. Get from capability registry
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Version Control
|
||||
title: Revisioning
|
||||
---
|
||||
|
||||
## Component Revision
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: Built-in Steps
|
||||
---
|
||||
|
||||
KubeVela provides some built-in workflow step definitions for better experience.
|
||||
This documentation will walk through the built-in workflow steps that you can use to design an application deployment process.
|
||||
|
||||
## apply-application
|
||||
|
||||
|
|
@ -15,13 +15,10 @@ Today the application teams are eager to find a platform that can simplify the a
|
|||
|
||||
## What is KubeVela?
|
||||
|
||||
KubeVela is a modern application platform that makes it easier and faster to deliver and manage applications across hybrid, multi-cloud environments. At the mean time, it is highly extensible and programmable, which can adapt to your needs as they grow. This is achieved by doing the following:
|
||||
KubeVela is a modern application platform that makes it easier and faster to deliver and manage applications across hybrid, multi-cloud environments. At the mean time, it is highly extensible and programmable, which can adapt to your needs as they grow.
|
||||
|
||||
**Application Centric** - KubeVela introduces [Open Application Model (OAM)](https://oam.dev/) as the consistent and application-focused API to capture a full deployment of microservices on top of hybrid environments. Placement strategy, traffic shifting and rolling update are declared at the perspective of application developers. No infrastructure level concern, only application level concepts.
|
||||
|
||||
|
||||
**Programmable Workflow** - KubeVela leverages [CUE](https://cuelang.org/) as the implementation engine behind the model layer. This allows you to compose deployment workflow in a modular and declarative API, and automates any operational tasks in a programmable manner. No restrictions, natively extensible.
|
||||
|
||||
**Runtime Agnostic** - KubeVela works as an application delivery control plane that is fully runtime agnostic. It can deploy and manage any application components including containers, cloud functions, databases, or even EC2 instances across hybrid environments, following the workflow you defined.
|
||||
|
||||
## Who should use KubeVela?
|
||||
|
||||
|
|
@ -74,6 +71,6 @@ Welcome onboard and sail Vela!
|
|||
Here are some recommended next steps:
|
||||
|
||||
- Start to [install KubeVela](./install).
|
||||
- Learn KubeVela's [Core Concepts](core-concepts/application).
|
||||
- Learn KubeVela's [Architecture](core-concepts/architecture).
|
||||
- Learn KubeVela's [core concepts](core-concepts/application).
|
||||
- Learn KubeVela's [architecture](core-concepts/architecture).
|
||||
|
||||
|
|
|
|||
|
|
@ -4,43 +4,46 @@ title: Deploy First Application
|
|||
|
||||
Welcome to KubeVela! In this guide, we'll walk you through how to install KubeVela, and deploy your first simple application.
|
||||
|
||||
## Step 1: Install
|
||||
## Installation
|
||||
|
||||
Make sure you have finished and verified the installation following [this guide](install).
|
||||
Make sure you have finished and verified KubeVela installation following [this guide](install).
|
||||
|
||||
## Step 2: Deploy Your First Application
|
||||
## A Simple Application
|
||||
|
||||
Run the following command:
|
||||
A simple deployment definition in KubeVela looks as below:
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: first-vela-app
|
||||
spec:
|
||||
components:
|
||||
- name: express-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
traits:
|
||||
- type: ingress-1-20
|
||||
properties:
|
||||
domain: testsvc.example.com
|
||||
http:
|
||||
"/": 8000
|
||||
```
|
||||
|
||||
Now deploy it to KubeVela:
|
||||
|
||||
```bash
|
||||
kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/docs/examples/vela-app.yaml
|
||||
```
|
||||
|
||||
This will apply an application to KubeVela and let it distribute the application to proper runtime infrastructure.
|
||||
This command will deploy a web service component to target environment, which in our case is the Kubernetes cluster that KubeVela itself is installed.
|
||||
|
||||
Check the status until we see `status` is `running` and services are `healthy`:
|
||||
|
||||
```bash
|
||||
$ kubectl get application first-vela-app -o yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
...
|
||||
status:
|
||||
...
|
||||
services:
|
||||
- healthy: true
|
||||
name: express-server
|
||||
traits:
|
||||
- healthy: true
|
||||
message: 'Visiting URL: testsvc.example.com, IP: your ip address'
|
||||
type: ingress
|
||||
status: running
|
||||
```
|
||||
|
||||
You can now directly visit the application (regardless of where it is running).
|
||||
After deployed, you can now directly visit this application as it already attached with a `ingress` trait (assume your cluster has Ingress enabled).
|
||||
|
||||
```
|
||||
$ curl -H "Host:testsvc.example.com" http://<your ip address>/
|
||||
$ curl -H "Host:testsvc.example.com" http://<some ip address>/
|
||||
<xmp>
|
||||
Hello World
|
||||
|
||||
|
|
@ -55,11 +58,195 @@ Hello World
|
|||
`'--.._\..--''
|
||||
</xmp>
|
||||
```
|
||||
**Voila!** You are all set to go.
|
||||
|
||||
## Deploy More Components
|
||||
|
||||
KubeVela allows you to deploy diverse components types. In above example, the `Web Service` component is actually a predefined [CUE](https://cuelang.org/) module.
|
||||
|
||||
You can also try:
|
||||
|
||||
### Helm components
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: app-delivering-chart
|
||||
spec:
|
||||
components:
|
||||
- name: redis-comp
|
||||
type: helm
|
||||
properties:
|
||||
chart: redis-cluster
|
||||
version: 6.2.7
|
||||
url: https://charts.bitnami.com/bitnami
|
||||
repoType: helm
|
||||
```
|
||||
|
||||
### Terraform components
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: rds-cloud-source
|
||||
spec:
|
||||
components:
|
||||
- name: sample-db
|
||||
type: alibaba-rds
|
||||
properties:
|
||||
instance_name: sample-db
|
||||
account_name: oamtest
|
||||
password: U34rfwefwefffaked
|
||||
writeConnectionSecretToRef:
|
||||
name: db-conn
|
||||
```
|
||||
|
||||
### Components from Git repository
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: git-app
|
||||
spec:
|
||||
components:
|
||||
- name: git-comp
|
||||
type: kustomize
|
||||
properties:
|
||||
repoType: git
|
||||
url: https://github.com/<path>/<to>/<repo>
|
||||
git:
|
||||
branch: master
|
||||
path: ./app/dev/
|
||||
```
|
||||
|
||||
... and many many more. Please check the `Deploying Components` section under `User Manuals` for all supported types, and even go ahead to add your own.
|
||||
|
||||
## Attach Operational Behaviors
|
||||
|
||||
KubeVela is not just about deploy. It allows you to attach predefined operational behaviors (named `Traits`) to your components in-place. For example, let's assign a batch rollout strategy to our web service:
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: rollout-trait-test
|
||||
spec:
|
||||
components:
|
||||
- name: express-server
|
||||
type: webservice
|
||||
externalRevision: express-server-v1
|
||||
properties:
|
||||
image: stefanprodan/podinfo:4.0.3
|
||||
traits:
|
||||
- type: rollout
|
||||
properties:
|
||||
targetSize: 5
|
||||
rolloutBatches:
|
||||
- replicas: 2
|
||||
- replicas: 3
|
||||
```
|
||||
|
||||
Now whenever the image version is updated in above YAML file, the `express-server` component will rollout following strategy defined in `rolloutBatches`.
|
||||
|
||||
For all supported traits in KubeVela, please check `Attaching Traits` section under `User Manuals`. Not surprisingly, you can also add your own traits to KubeVela with just minimal effort.
|
||||
|
||||
## Define Policies and Workflow
|
||||
|
||||
Components and traits are just the beginning of your vela sail. KubeVela is by design a full functional Continuous Delivery (CD) platform with fine grained support for hybrid/multi-cloud/multi-cluster deployment.
|
||||
|
||||
Let's say:
|
||||
|
||||
> I want to deploy an micro-services application with two components, firstly to staging cluster with only 1 instance, then pause and wait for manual approval. If approved, then deploy it to production cluster but with instances scaled to 3.
|
||||
|
||||
Oops, imagine how many add-hoc scripts and glue code are needed in your CI/CD pipeline to achieve automation and deployment success rate in above process.
|
||||
|
||||
While with KubeVela, above process can be easily modeled as a declarative deployment plan as below:
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: example-app
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: hello-world-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
traits:
|
||||
- type: scaler
|
||||
properties:
|
||||
replicas: 1
|
||||
- name: data-worker
|
||||
type: worker
|
||||
properties:
|
||||
image: busybox
|
||||
cmd:
|
||||
- sleep
|
||||
- '1000000'
|
||||
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
|
||||
|
||||
- name: health-policy-demo
|
||||
type: health
|
||||
properties:
|
||||
probeInterval: 5
|
||||
probeTimeout: 10
|
||||
|
||||
workflow:
|
||||
steps:
|
||||
# deploy to staging env
|
||||
- name: deploy-staging
|
||||
type: deploy2env
|
||||
properties:
|
||||
policy: example-multi-env-policy
|
||||
env: staging
|
||||
|
||||
# manual check
|
||||
- name: manual-approval
|
||||
type: suspend
|
||||
|
||||
# deploy to prod env
|
||||
- name: deploy-prod
|
||||
type: deploy2env
|
||||
properties:
|
||||
policy: example-multi-env-policy
|
||||
env: prod
|
||||
```
|
||||
|
||||
No more add-hoc scripts or glue code, KubeVela will get the application delivery workflow done with full automation and determinism. Most importantly, KubeVela expects you keep using the CI solutions you are already familiar with and KubeVela is fully complementary to them as the CD control plane.
|
||||
|
||||
For using KubeVela with your own CI pipelines and other tools, please check `Best Practices` section in the sidebar for more real world examples.
|
||||
|
||||
## What's Next
|
||||
|
||||
Here are some recommended next steps:
|
||||
|
||||
- Learn KubeVela's [Core Concepts](./core-concepts/application).
|
||||
- Learn KubeVela's [Architecture](./core-concepts/architecture).
|
||||
All above features are just the first glance of KubeVela. For next steps, we recommend:
|
||||
- Learn KubeVela's [application model](./core-concepts/application).
|
||||
- Interested in KubeVela itself? Learn its [design and architecture](./core-concepts/architecture).
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 472 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 429 KiB After Width: | Height: | Size: 198 KiB |
|
|
@ -75,8 +75,8 @@
|
|||
"message": "交付环境系统",
|
||||
"description": "The label for category Environment System in sidebar docs"
|
||||
},
|
||||
"sidebar.docs.category.Workflow": {
|
||||
"message": "定义交付工作流",
|
||||
"sidebar.docs.category.Designing Workflow": {
|
||||
"message": "设计交付工作流",
|
||||
"description": "The label for category Workflow End User in sidebar docs"
|
||||
},
|
||||
"sidebar.docs.category.Workflow System": {
|
||||
|
|
@ -115,15 +115,15 @@
|
|||
"message": "用户手册",
|
||||
"description": "The label for category User Guide in sidebar docs"
|
||||
},
|
||||
"sidebar.docs.category.Components": {
|
||||
"sidebar.docs.category.Deploying Components": {
|
||||
"message": "选择待交付组件",
|
||||
"description": "The label for category Components in sidebar docs"
|
||||
},
|
||||
"sidebar.docs.category.Traits": {
|
||||
"sidebar.docs.category.Attaching Traits": {
|
||||
"message": "绑定运维特征",
|
||||
"description": "The label for category Traits in sidebar docs"
|
||||
},
|
||||
"sidebar.docs.category.Policies": {
|
||||
"sidebar.docs.category.Defining Policies": {
|
||||
"message": "设定应用策略",
|
||||
"description": "The label for category Policies in sidebar docs"
|
||||
},
|
||||
|
|
@ -155,7 +155,7 @@
|
|||
"message": "云服务组件",
|
||||
"description": "The label for category Cloud Services in sidebar docs"
|
||||
},
|
||||
"sidebar.docs.category.CUE Components": {
|
||||
"sidebar.docs.category.CUE": {
|
||||
"message": "CUE 组件",
|
||||
"description": "The label for category CUE Components in sidebar docs"
|
||||
},
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
---
|
||||
title: 原生资源
|
||||
title: 资源模板
|
||||
---
|
||||
|
||||
KubeVela 可以直接部署任何原生的 Kubernetes 资源。比如一个 Job。
|
||||
KubeVela 可以以资源模板的方式直接部署任何 Kubernetes 对象。比如一个 Job。
|
||||
|
||||
## 如何使用
|
||||
|
||||
|
|
|
|||
|
|
@ -75,8 +75,8 @@
|
|||
"message": "交付环境系统",
|
||||
"description": "The label for category Environment System in sidebar docs"
|
||||
},
|
||||
"sidebar.docs.category.Workflow": {
|
||||
"message": "定义交付工作流",
|
||||
"sidebar.docs.category.Designing Workflow": {
|
||||
"message": "设计交付工作流",
|
||||
"description": "The label for category Workflow End User in sidebar docs"
|
||||
},
|
||||
"sidebar.docs.category.Workflow System": {
|
||||
|
|
@ -115,15 +115,15 @@
|
|||
"message": "用户手册",
|
||||
"description": "The label for category User Guide in sidebar docs"
|
||||
},
|
||||
"sidebar.docs.category.Components": {
|
||||
"sidebar.docs.category.Deploying Components": {
|
||||
"message": "选择待交付组件",
|
||||
"description": "The label for category Components in sidebar docs"
|
||||
},
|
||||
"sidebar.docs.category.Traits": {
|
||||
"sidebar.docs.category.Attaching Traits": {
|
||||
"message": "绑定运维特征",
|
||||
"description": "The label for category Traits in sidebar docs"
|
||||
},
|
||||
"sidebar.docs.category.Policies": {
|
||||
"sidebar.docs.category.Defining Policies": {
|
||||
"message": "设定应用策略",
|
||||
"description": "The label for category Policies in sidebar docs"
|
||||
},
|
||||
|
|
@ -155,7 +155,7 @@
|
|||
"message": "云服务组件",
|
||||
"description": "The label for category Cloud Services in sidebar docs"
|
||||
},
|
||||
"sidebar.docs.category.CUE Components": {
|
||||
"sidebar.docs.category.CUE": {
|
||||
"message": "CUE 组件",
|
||||
"description": "The label for category CUE Components in sidebar docs"
|
||||
},
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
---
|
||||
title: 应用部署计划
|
||||
title: 应用交付模型
|
||||
---
|
||||
|
||||
KubeVela 背后的应用交付模型是 [Open Application Model](../platform-engineers/oam/oam-model)，简称 OAM ，其核心是将应用部署所需的所有组件和各项运维动作，描述为一个统一的、与基础设施无关的“部署计划”，进而实现在混合环境中进行标准化和高效率的应用交付。这个应用部署计划就是这一节所要介绍的 **Application** 对象，也是 OAM 模型的使用者唯一需要了解的 API。
|
||||
KubeVela 背后的应用交付模型是 [Open Application Model](../platform-engineers/oam/oam-model)，简称 OAM ，其核心是将应用部署所需的所有组件和各项运维动作，描述为一个统一的、与基础设施无关的“部署计划”，进而实现在混合环境中进行标准化和高效率的应用交付。
|
||||
|
||||
## 应用程序部署计划（Application）
|
||||
## 应用部署计划（Application）
|
||||
|
||||
KubeVela 通过 YAML 文件的方式描述应用部署计划。一个典型的 YAML 样例如下：
|
||||
|
||||
|
|
@ -71,27 +71,11 @@ spec:
|
|||
env: prod
|
||||
```
|
||||
|
||||
这里的字段对应着：
|
||||
|
||||
- `apiVersion`：所使用的 OAM API 版本。
|
||||
- `kind`：种类。我们最经常用到的就是 Pod 了。
|
||||
- `metadata`：业务相关信息。比如这次要创建的是一个网站。
|
||||
- `Spec`：描述我们需要应用去交付什么，告诉 Kubernetes 做成什么样。这里我们放入 KubeVela 的 `components`、`policies` 以及 `workflow`。
|
||||
- `components`：一次应用交付部署计划所涵盖的全部组件。
|
||||
- `traits`：应用交付部署计划中每个组件独立的运维特征。
|
||||
- `policies`：作用于整个应用全局的部署策略。
|
||||
- `workflow`：自定义应用交付“执行过程”的工作流。
|
||||
|
||||
下面这张示意图诠释了它们之间的关系：
|
||||
|
||||
|
||||
先有一个总体的应用部署计划 Application。在此基础之上我们申明应用主体为可配置、可部署的组件（Components），并同时对应地去申明，期望每个组件要拥有的相关运维特征 （Traits），如果有需要，还可以申明自定义的执行流程 （Workflow）。
|
||||
|
||||
你使用 KubeVela 的时候，就像在玩“乐高“积木：先拿起一块大的“应用程序”，然后往上固定一块或几块“组件”，组件上又可以贴上任何颜色大小的“运维特征”。同时根据需求的变化，你随时可以重新组装，形成新的应用部署计划。
|
||||
在使用时，一个应用部署计划由组件、运维特征、策略、工作流等多个模块组装而成。
|
||||
|
||||
## 组件（Components）
|
||||
|
||||
KubeVela 内置了常用的组件类型，使用 [KubeVela CLI](../install#3-安装-kubevela-cli) 命令查看：
|
||||
一个应用部署计划可以包含很多待部署组件。KubeVela 内置了常用的组件类型，使用 [KubeVela CLI](../install#3-安装-kubevela-cli) 命令查看：
|
||||
```
|
||||
vela components
|
||||
```
|
||||
|
|
@ -109,13 +93,9 @@ worker vela-system deployments.apps Describes long-run
|
|||
|
||||
```
|
||||
|
||||
你可以继续使用 [Helm 组件](../end-user/components/helm)和[Kustomize 组件](../end-user/components/kustomize)等开箱即用的 KubeVela 内置组件来构建你的应用部署计划。
|
||||
|
||||
如果你是熟悉 Kubernetes 的平台管理员，你可以通过[自定义组件入门](../platform-engineers/components/custom-component)文档了解 KubeVela 是如何扩展任意类型的自定义组件的。特别的，[Terraform 组件](../platform-engineers/components/component-terraform) 就是 KubeVela 自定义组件能力的一个最佳实践，可以满足任意云资源的供应，只需少量云厂商特定配置（如鉴权、云资源模块等），即可成为一个开箱即用的云资源组件。
|
||||
|
||||
## 运维特征（Traits）
|
||||
|
||||
KubeVela 也内置了常用的运维特征类型，使用 [KubeVela CLI](../install#3-安装-kubevela-cli) 命令查看：
|
||||
运维特征是可以随时绑定给待部署组件的、模块化的运维能力。KubeVela 也内置了常用的运维特征类型，使用 [KubeVela CLI](../install#3-安装-kubevela-cli) 命令查看：
|
||||
```
|
||||
vela traits
|
||||
```
|
||||
|
|
@ -130,35 +110,15 @@ scaler vela-system webservice,worker false Manually
|
|||
sidecar vela-system deployments.apps true Inject a sidecar container to the component.
|
||||
```
|
||||
|
||||
你可以继续阅读用户手册里的 [绑定运维特征](../end-user/traits/ingress) ，具体查看如何完成各种运维特征的开发。
|
||||
|
||||
如果你是熟悉 Kubernetes 的平台管理员，也可以了解 KubeVela 中[自定义运维特征](../platform-engineers/traits/customize-trait) 的能力，为你的用户扩展任意运维功能。
|
||||
|
||||
## 应用策略（Policy)
|
||||
|
||||
应用策略（Policy）负责定义应用级别的部署特征，比如健康检查规则、安全组、防火墙、SLO、检验等模块。
|
||||
应用策略的扩展性和功能与运维特征类似，可以灵活的扩展和对接所有云原生应用生命周期管理的能力。相对于运维特征而言，应用策略作用于一个应用的整体，而运维特征作用于应用中的某个组件。
|
||||
|
||||
在本例中，我们设置了一个将应用部署到不同环境的策略。
|
||||
应用策略（Policy）负责定义指定应用交付过程中的策略，比如质量保证策略、安全组策略、防火墙规则、SLO 目标、放置策略等等。
|
||||
|
||||
## 工作流（Workflow）
|
||||
|
||||
KubeVela 的工作流机制允许用户自定义应用部署计划中的步骤，粘合额外的交付流程，指定任意的交付环境。简而言之，工作流提供了定制化的控制逻辑，在原有 Kubernetes 模式交付资源（Apply）的基础上，提供了面向过程的灵活性。比如说，使用工作流实现暂停、人工验证、状态等待、数据流传递、多环境灰度、A/B 测试等复杂操作。
|
||||
工作流允许用户将组件、运维特征、具体的交付动作等一系列元素组装成为一个完整的、面向过程的有向无环图（DAG）。典型的工作流步骤包括暂停、人工审核、等待、数据传递、多环境/多集群发布、A/B 测试等等。
|
||||
|
||||
工作流是 KubeVela 实践过程中基于 OAM 模型的进一步探索和最佳实践，充分遵守 OAM 的模块化理念和可复用特性。每一个工作流模块都是一个“超级粘合剂”，可以将你任意的工具和流程都组合起来。使得你在现代复杂云原生应用交付环境中，可以通过一份申明式的配置，完整的描述所有的交付流程，保证交付过程的稳定性和便利性。
|
||||
|
||||
> 需要说明的是，工作流机制是基于“应用和环境”粒度工作的，它提供了“自定义交付过程”的强大能力。一旦定义工作流，就代表用户自己指定交付的执行过程，原有的组件部署过程会被取代。工作流并非必填能力，用户在不编写 Workflow 过程的情况下，依旧可以完成组件和运维策略的自动化部署。
|
||||
|
||||
在上面的例子中，我们已经可以看到一些工作流的步骤：
|
||||
|
||||
- 这里使用了 `deploy2env` 和 `suspend` 类型的工作流步骤：
|
||||
- `deploy2env` 类型可以根据用户定义的策略将应用部署到指定的环境。
|
||||
- 在第一步完成后，开始执行 `suspend` 类型的工作流步骤。该步骤会暂停工作流，我们可以查看集群中第一个组件的状态，当其成功运行后，再使用 `vela workflow resume website` 命令来继续该工作流。
|
||||
- 当工作流继续运行后，第三个步骤开始部署组件及运维特征。此时我们查看集群，可以看到所以资源都已经被成功部署。
|
||||
|
||||
关于工作流，你可以从[指定环境部署](../end-user/workflow/multi-env)这个工作流节点类型开始逐次了解更多 KubeVela 当前的内置工作流节点类型。
|
||||
|
||||
如果你是熟悉 Kubernetes 的平台管理员，你可以[学习创建自定义工作流节点类型](../platform-engineers/workflow/workflow)，或者通过[设计文档](https://github.com/oam-dev/kubevela/blob/master/design/vela-core/workflow_policy.md)了解工作流系统背后的设计和架构.
|
||||
每一个工作流步骤在 KubeVela 中都是一个完全可插拔的独立功能模块，KubeVela 允许你通过 CUE 语言自由的定义和创建属于自己的工作流步骤来组成自己的交付计划。
|
||||
|
||||
## 下一步
|
||||
|
||||
|
|
@ -166,4 +126,4 @@ KubeVela 的工作流机制允许用户自定义应用部署计划中的步骤
|
|||
|
||||
- 加入 KubeVela 中文社区钉钉群，群号：23310022。
|
||||
- 阅读[**用户手册**](../end-user/components/helm)，从 Helm 组件开始了解如何构建你的应用部署计划。
|
||||
- 阅读[**管理员手册**](../platform-engineers/oam/oam-model)了解 KubeVela 的扩展方式和背后的 OAM 模型原理。
|
||||
- 阅读[**管理员手册**](../platform-engineers/oam/oam-model)了解开放应用模型的细节。
|
||||
|
|
@ -2,37 +2,33 @@
|
|||
title: 系统架构
|
||||
---
|
||||
|
||||
KubeVela 在默认安装模式下，是一个只包含“控制平面”的架构，通过插件机制与各种运行时系统进行紧密配合。其中 KubeVela 核心控制器工作在一个单独的控制面 Kubernetes 集群。
|
||||
如下图所示，自上而下看，用户只与 KubeVela 所在的控制面 Kubernetes 集群发生交互。
|
||||
KubeVela 的整体架构如下所示：
|
||||
|
||||
|
||||
|
||||
## API 层
|
||||
## KubeVela 是一个控制平面系统
|
||||
|
||||
KubeVela API 是声明式的，并以应用程序为中心，用于构建应用交付平台和解决方案。同时，由于它基于原生的 Kubernetes CRD 构建，所以使用起来非常方便。
|
||||
KubeVela 本身是一个的应用交付与管理控制平面，它架在 Kubernetes 集群、云平台等基础设施之上，通过开放应用模型来对组件、云服务、运维能力、交付工作流进行统一的编排和交付，因而与基础设施本身完全解耦并且很容易面向任何混合/多云/多集群基础设施进行应用交付与管理。
|
||||
|
||||
- 对于大多数不用关心底层细节的用户来说，你只需要：
|
||||
- 查看 KubeVela 所提供的开箱即用的组件、运维特征、应用策略和工作流
|
||||
- 通过 YAML 文件来描述一个应用部署计划
|
||||
- 对于少数管理员来说：
|
||||
- 内置新的组件、运维特征、应用策略和自定义工作流，提供给你的用户
|
||||
- 通常需要使用 YAML 文件和 CUE 语言来完成上述操作
|
||||
而为了能够同任何 CI 流水线或者 GitOps 工具无缝对接，KubeVela 的 API（即开放应用模型）被设计为是声明式、完全以应用为中心的，它包括：
|
||||
- 帮助用户定义应用交付计划的 `Application` 对象
|
||||
- 帮助平台管理员通过 CUE 语言定义平台能力和抽象的 `X-Definition `对象
|
||||
- 比如 `ComponentDefinition`、`TraitDefinition` 等
|
||||
|
||||
## 控制平面层
|
||||
|
||||
控制平面层是 KubeVela 的系统核心。它既能帮你按需组装内置能力，或者通过注册各种能力插件满足交付应用的需要，同时在交付后全自动处理 API 请求并管理全局状态。
|
||||
|
||||
主要包含如下三个部分:
|
||||
在实现上，KubeVela 需要依赖一个独立的 Kubernetes 集群来运行。这是一个有意为之的设计：因为帮助你快速实现一个科学的、健壮的控制平面系统，正是 Kubernetes 项目最擅长的一件事情。这个实践已经久经社区考验，能够让我们以最低的代价为大规模应用交付工作流带来宝贵的确定性、收敛性和自动化能力。具体来说，KubeVela 本身主要由如下几个部分注册:
|
||||
|
||||
- **核心控制器** 为整个系统提供核心控制逻辑，完成诸如编排应用和工作流、修订版本快照、垃圾回收等等基础逻辑
|
||||
- **新增内置能力** 由 X-Definitions 创建，注册应用交付所需要的内置能力。基于这个灵活性，我们可以自由地去集成开源生态的能力，按需自定义
|
||||
- **插件能力中心** Addon 让你可以调用生态下常见的能力，甚至直接省去了开发的时间和成本
|
||||
- **模块能力控制器** 负责对 X-Definitions 对象进行注册和管理。
|
||||
- **插件控制器** 负责注册和管理 KubeVela 运行所需要的第三方插件，比如 Flux，Terraform 组件等等。
|
||||
|
||||
## 执行层
|
||||
### 运行时基础设施
|
||||
|
||||
最后，执行层是应用程序实际会运行的地方。KubeVela 允许你在统一的工作流中，部署和管理应用程序到 Kubernetes 集群，例如本地、托管云服务、IoT/边缘设备端等等。
|
||||
运行时基础设施是应用实际运行的地方。KubeVela 本身是完全与这些基础设施无关的，因此它允许你面向任何环境，包括 Kubernetes 环境，也包括非 Kubernetes 环境比如云平台和边缘设备等，交付任何类型的应用。
|
||||
|
||||
## 下一步
|
||||
## KubeVela 是可编程的
|
||||
|
||||
- 学习如何用 KubeVela 来进行应用交付, 请查看[应用部署计划](./application)。
|
||||
- 阅读管理员手册学习 [开放应用模型](../platform-engineers/oam/oam-model)。
|
||||
在现实世界中，应用交付往往比较复杂，哪怕是一个非常通用的交付过程，也会因为用户、团队、环境、场景的变化而千差万别。所以 KubeVela 从第一天起就采用了一种“可编程”式的方法来实现它的交付模型，这使得 KubeVela 可以非常容易和灵活的适配到你的应用交付场景中。
|
||||
|
||||
|
||||
|
||||
如果要详细学习 KubeVela 的可编程文档，欢迎查看文档网站中《管理员手册》部分。
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
---
|
||||
title: 原生资源
|
||||
title: 资源模板
|
||||
---
|
||||
|
||||
KubeVela 可以直接部署任何原生的 Kubernetes 资源。比如一个 Job。
|
||||
KubeVela 可以以资源模板的方式直接部署任何 Kubernetes 对象。比如一个 Job。
|
||||
|
||||
## 如何使用
|
||||
|
||||
|
|
|
|||
|
|
@ -1,8 +1,8 @@
|
|||
---
|
||||
title: 附录：内置工作流步骤
|
||||
title: 工作流步骤
|
||||
---
|
||||
|
||||
为了便于用户使用，KubeVela 提供了一些内置的工作流步骤。
|
||||
本文档将详细介绍 KubeVela 内置的各个工作流步骤。您可以通过自由的组合它们来设计完整的交付工作流。
|
||||
|
||||
## apply-application
|
||||
|
||||
|
|
@ -15,7 +15,11 @@ slug: /
|
|||
|
||||
## 什么是 KubeVela？
|
||||
|
||||
KubeVela 是一个开箱即用的、现代化的应用交付与管理平台。KubeVela 通过以下设计，使得面向混合/多云环境的应用交付变得非常简单高效：
|
||||
KubeVela 是一个开箱即用的、现代化的应用交付与管理平台。
|
||||
|
||||
|
||||
|
||||
KubeVela 通过以下设计，使得面向混合/多云环境的应用交付变得非常简单高效：
|
||||
|
||||
- **完全以应用为中心** - KubeVela 创新性的提出了[开放应用模型（OAM）](https://oam.dev/)来作为应用交付的顶层抽象，并通过声明式的交付工作流来捕获面向混合环境的微服务应用交付的整个过程，甚至连多集群分发策略、流量调配和滚动更新等运维特征，也都声明在应用级别。用户无需关心任何基础设施细节，只需要专注于定义和部署应用即可。
|
||||
- **可编程式交付工作流** - KubeVela 的交付模型是利用 [CUE](https://cuelang.org/) 来实现的。CUE 是一种诞生自 Google Borg 系统的数据配置语言，它可以将应用交付的所有步骤、所需资源、关联的运维动作以可编程的方式粘合成一个 DAG（有向无环图）来作为最终的声明式交付计划。相比于其他系统的复杂性和不可扩展性，KubeVela 基于 CUE 的实现不仅使用简单、扩展性极强，也更符合现代 GitOps 应用交付的趋势与要求。
|
||||
|
|
|
|||
|
|
@ -2,75 +2,43 @@
|
|||
title: 交付第一个应用
|
||||
---
|
||||
|
||||
欢迎来到 KubeVela! 在本小节中，我们会向你介绍如何完成第一个 Demo。
|
||||
欢迎来到 KubeVela! 在本小节中，我们会向你介绍一些例子来帮助你理解如何使用 KubeVela 解决应用交付中的实际问题。
|
||||
|
||||
先来实际感受 KubeVela 到底是如何工作的。
|
||||
在实践之前，请确保您已经按照《快速安装》文档，在您的控制平面集群中安装了 KubeVela。
|
||||
|
||||
## 部署你的第一个应用
|
||||
## 一个最简单的示例
|
||||
|
||||
首先，在你的集群上，我们使用一个提前准备好的 YMAL 文件。
|
||||
KubeVela 中一个比较简单的应用部署定义，大致如下所示：
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: first-vela-app
|
||||
spec:
|
||||
components:
|
||||
- name: express-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
traits:
|
||||
- type: ingress-1-20
|
||||
properties:
|
||||
domain: testsvc.example.com
|
||||
http:
|
||||
"/": 8000
|
||||
```
|
||||
|
||||
我们可以直接使用 `kubectl` 把它提交给 KubeVela：
|
||||
|
||||
```bash
|
||||
kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/docs/examples/vela-app.yaml
|
||||
```
|
||||
|
||||
检查状态：直到看到 `status` 是 `running`，并且 `services` 是 `healthy`。
|
||||
上述命令一旦执行，KubeVela 就会帮助你在目标集群中交付一个 `Web 服务`类型的组件，且该组件的容器镜像是`crccheck/hello-world`。在本示例中，我们并没有特别指明目标集群是哪个，所以 KubeVela 会默认把应用部署在它所在的集群也就是控制平面集群当中。
|
||||
|
||||
```bash
|
||||
$ kubectl get application first-vela-app -o yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
generation: 1
|
||||
name: first-vela-app
|
||||
...
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: express-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
traits:
|
||||
- type: ingress
|
||||
properties:
|
||||
domain: testsvc.example.com
|
||||
http:
|
||||
/: 8000
|
||||
status:
|
||||
...
|
||||
services:
|
||||
- healthy: true
|
||||
name: express-server
|
||||
traits:
|
||||
- healthy: true
|
||||
message: 'Visiting URL: testsvc.example.com, IP: your ip address'
|
||||
type: ingress
|
||||
status: running
|
||||
```
|
||||
可以看到，这个 YAML 的类型是一个 `Application`，由 `core.oam.dev/v1beta1` 来定义，即 KubeVela 的 API Specification。
|
||||
|
||||
在 `Sepc` 字段里，我们也看到比如 `components` 和 `traits` 这样陌生的字段。
|
||||
|
||||
在下一章节中，我们将带你进一步深入它们背后 KubeVela 的核心概念：应用程序、组件系统和运维特征系统。
|
||||
|
||||
同时，在底层的 K8s 资源也被创建了出来:
|
||||
|
||||
```bash
|
||||
$ kubectl get deployment
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
express-server-v1 1/1 1 1 8m
|
||||
$ kubectl get svc
|
||||
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
express-server ClusterIP 172.21.11.152 <none> 8000/TCP 7m43s
|
||||
kubernetes ClusterIP 172.21.0.1 <none> 443/TCP 116d
|
||||
$ kubectl get ingress
|
||||
NAME CLASS HOSTS ADDRESS PORTS AGE
|
||||
express-server <none> testsvc.example.com <your ip address> 80 7m47s
|
||||
```
|
||||
|
||||
如果你的集群有一个工作中的 ingress，你可以查看这个 service。
|
||||
而由于我们已经在上述 YAML 文件中为这个组件绑定了一个 `ingress` 类型的运维特征，KubeVela 就会指导 Kubernetes 自动为这个组件背后的工作负载配置 Service、端口映射和 HTTP 路由规则。所以只要目标集群具备 Ingress 能力，上述 YAML 一部署成功，你就可以立刻通过外域名来问这个应用了。
|
||||
|
||||
```
|
||||
$ curl -H "Host:testsvc.example.com" http://<your ip address>/
|
||||
|
|
@ -88,14 +56,195 @@ Hello World
|
|||
`'--.._\..--''
|
||||
</xmp>
|
||||
```
|
||||
**太棒了!** 你已经全都部署成功了。
|
||||
|
||||
也就是说 KubeVlea 的应用交付，围绕应用程序、组件系统和运维特征系统这一整套应用部署计划的核心概念展开，同时通过 Workflow 工作流、CUE 粘合开源生态等进行场景和能力的按需扩展，达成跨云、标准和统一的交付目标。
|
||||
## 交付更多的组件
|
||||
|
||||
KubeVela 允许你部署的组件类型是非常丰富的。在上面的例子中，`Web Service`组件实际上就是一个预先编写好的[CUE](https://cuelang.org/) 文件。
|
||||
|
||||
你还可以其它很多类型，比如：
|
||||
|
||||
### Helm 组件
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: app-delivering-chart
|
||||
spec:
|
||||
components:
|
||||
- name: redis-comp
|
||||
type: helm
|
||||
properties:
|
||||
chart: redis-cluster
|
||||
version: 6.2.7
|
||||
url: https://charts.bitnami.com/bitnami
|
||||
repoType: helm
|
||||
```
|
||||
|
||||
### Terraform 云资源组件
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: rds-cloud-source
|
||||
spec:
|
||||
components:
|
||||
- name: sample-db
|
||||
type: alibaba-rds
|
||||
properties:
|
||||
instance_name: sample-db
|
||||
account_name: oamtest
|
||||
password: U34rfwefwefffaked
|
||||
writeConnectionSecretToRef:
|
||||
name: db-conn
|
||||
```
|
||||
|
||||
### 来自 Git 仓库的组件（基于 Kustomize）
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: git-app
|
||||
spec:
|
||||
components:
|
||||
- name: git-comp
|
||||
type: kustomize
|
||||
properties:
|
||||
repoType: git
|
||||
url: https://github.com/<path>/<to>/<repo>
|
||||
git:
|
||||
branch: master
|
||||
path: ./app/dev/
|
||||
```
|
||||
|
||||
当然，还有更多。欢迎查看边栏中的《选择待交付组件》章节来阅读关于部署各种类型的详细文档。如果你需要的话，你还可以在 KubeVela 中添加自己的组件类型。
|
||||
|
||||
## 绑定运维特征
|
||||
|
||||
KubeVela 能做的远不止部署，还包括运维。它允许你为待交付组件绑定预先定义好的各种运维行为（叫做运维特征），并且这个绑定会立刻生效。接下来，我们就为 Web 服务组件绑定一个“分批发布”运维特征：
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: rollout-trait-test
|
||||
spec:
|
||||
components:
|
||||
- name: express-server
|
||||
type: webservice
|
||||
externalRevision: express-server-v1
|
||||
properties:
|
||||
image: stefanprodan/podinfo:4.0.3
|
||||
traits:
|
||||
- type: rollout
|
||||
properties:
|
||||
targetSize: 5
|
||||
rolloutBatches:
|
||||
- replicas: 2
|
||||
- replicas: 3
|
||||
```
|
||||
|
||||
好了，接下来，只要上述 YAML 中的镜像版本发生变化，KubeVela 就会按照你所定义的分批策略来更新对应的应用实例了。
|
||||
|
||||
如果你想了解 KubeVela 所支持的所有运维特征，欢迎查看边栏中的《绑定运维特征》章节，同样的，KubeVela 允许你非常容易的在平台中添加自己的运维特征。
|
||||
|
||||
## 定义交付策略与交付工作流
|
||||
|
||||
组件与运维特征只是 KubeVela 非常基本的功能。KubeVela 本身实际上是一个全功能的持续交付（CD）系统，并且原生支持面向混合环境（比如混合云/多云/多集群）应用交付。
|
||||
|
||||
举个例子：
|
||||
|
||||
> 我要交付一个包括了两个组件的微服务应用，要求先需要在预发集群当中部署 1 个副本，然后暂停交付过程，请主管进行人工审核。当审核通过后，再继续部署到生产集群中，并且需要部署为3个副本。
|
||||
|
||||
想象一下，你需要在 CI/CD 流水线里编写多少“脏乱差”的一次性脚本或者胶水代码才能让上述流程自动化的、保证一定正确性的执行起来？
|
||||
|
||||
而在 KubeVela 中，上述流程可以非常容易的通过如下所示的声明式工作流建模出来：
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: example-app
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: hello-world-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
traits:
|
||||
- type: scaler
|
||||
properties:
|
||||
replicas: 1
|
||||
- name: data-worker
|
||||
type: worker
|
||||
properties:
|
||||
image: busybox
|
||||
cmd:
|
||||
- sleep
|
||||
- '1000000'
|
||||
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
|
||||
|
||||
- name: health-policy-demo
|
||||
type: health
|
||||
properties:
|
||||
probeInterval: 5
|
||||
probeTimeout: 10
|
||||
|
||||
workflow:
|
||||
steps:
|
||||
# deploy to staging env
|
||||
- name: deploy-staging
|
||||
type: deploy2env
|
||||
properties:
|
||||
policy: example-multi-env-policy
|
||||
env: staging
|
||||
|
||||
# manual check
|
||||
- name: manual-approval
|
||||
type: suspend
|
||||
|
||||
# deploy to prod env
|
||||
- name: deploy-prod
|
||||
type: deploy2env
|
||||
properties:
|
||||
policy: example-multi-env-policy
|
||||
env: prod
|
||||
```
|
||||
|
||||
不需要任何“脏乱差”脚本，KubeVela 就能够以完全自动化、高确定性的声明式工作流完成所有的应用交付动作。更为重要的是，KubeVela 希望你继续使用你现有的 CI 方案，而 KubeVela 则负责帮助你更好的完成 CD 流程。
|
||||
|
||||
## 下一步
|
||||
|
||||
后续步骤:
|
||||
上述所有功能，只是 KubeVela 这个现代化的云原生应用交付与管理平台的冰山一角。您可以从下面步骤来开始更好的了解 KubeVela:
|
||||
|
||||
- 查看 KubeVela 的[`应用部署计划及其概念`](./core-concepts/application)，进一步理解其是如何工作的。
|
||||
- 查看 KubeVela 的[`系统架构`](./core-concepts/architecture)，了解 KubeVela 的系统构成和运转模式。
|
||||
- 查看 KubeVela 的[`应用部署模型`](./core-concepts/application)，进一步理解其是如何工作的。
|
||||
- 查看 KubeVela 的[`系统架构`](./core-concepts/architecture)，了解 KubeVela 本身的设计与架构原理。
|
||||
- 加入 KubeVela 中文社区钉钉群，群号：23310022。
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 497 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 454 KiB After Width: | Height: | Size: 198 KiB |
16
sidebars.js
16
sidebars.js
|
|
@ -38,7 +38,7 @@ module.exports = {
|
|||
collapsed: true,
|
||||
items: [
|
||||
{
|
||||
'Components': [
|
||||
'Deploying Components': [
|
||||
'end-user/components/helm',
|
||||
'end-user/components/kustomize',
|
||||
{
|
||||
|
|
@ -54,36 +54,37 @@ module.exports = {
|
|||
],
|
||||
},
|
||||
{
|
||||
'CUE Components': [
|
||||
'CUE': [
|
||||
'end-user/components/cue/webservice',
|
||||
'end-user/components/cue/worker',
|
||||
'end-user/components/cue/task',
|
||||
'end-user/components/cue/raw',
|
||||
]
|
||||
},
|
||||
'end-user/components/cue/raw',
|
||||
'end-user/components/more',
|
||||
]
|
||||
},
|
||||
{
|
||||
'Traits': [
|
||||
'Attaching Traits': [
|
||||
'end-user/traits/ingress',
|
||||
'end-user/traits/rollout',
|
||||
'end-user/traits/autoscaler',
|
||||
'end-user/traits/kustomize-patch',
|
||||
'end-user/traits/annotations-and-labels',
|
||||
'end-user/traits/service-binding',
|
||||
'end-user/traits/sidecar',
|
||||
'end-user/traits/kustomize-patch',
|
||||
'end-user/traits/more',
|
||||
]
|
||||
},
|
||||
{
|
||||
'Policies': [
|
||||
'Defining Policies': [
|
||||
'end-user/policies/envbinding',
|
||||
'end-user/policies/health',
|
||||
]
|
||||
},
|
||||
{
|
||||
'Workflow': [
|
||||
'Designing Workflow': [
|
||||
'end-user/workflow/built-in-workflow-defs',
|
||||
'end-user/workflow/webhook-notification',
|
||||
'end-user/workflow/component-dependency-parameter',
|
||||
]
|
||||
|
|
@ -134,7 +135,6 @@ module.exports = {
|
|||
{
|
||||
'Workflow System': [
|
||||
'platform-engineers/workflow/workflow',
|
||||
'platform-engineers/workflow/built-in-workflow-defs',
|
||||
'platform-engineers/workflow/cue-actions',
|
||||
]
|
||||
},
|
||||
|
|
|
|||
|
|
@ -26,29 +26,31 @@ const features = [
|
|||
<>
|
||||
<p>
|
||||
<Translate>
|
||||
KubeVela leverages </Translate>
|
||||
<a href="https://github.com/cuelang/cue"> CUE</a> <Translate>to
|
||||
implement its model layer. This allows you to define an application deployment
|
||||
workflow as DAG, with all steps and application's needs glued together in programmable approach.
|
||||
No restrictions, natively extensible.</Translate>
|
||||
KubeVela models application delivery as DAG (Directed Acyclic Graph)
|
||||
and expresses it with</Translate>
|
||||
<a href="https://github.com/cuelang/cue"> CUE</a>, <Translate>
|
||||
a modern data configuration language. This allows you to declare
|
||||
application deployment workflow with all steps and delivery needs
|
||||
assembled together in programmable approach. No restrictions,
|
||||
natively extensible.</Translate>
|
||||
</p>
|
||||
</>
|
||||
),
|
||||
reverse: true,
|
||||
},
|
||||
{
|
||||
title: <><Translate>Runtime Agnostic</Translate></>,
|
||||
title: <><Translate>Infrastructure Agnostic</Translate></>,
|
||||
imgUrl: 'img/simple-yet-extensible-abstraction-mechanism.svg',
|
||||
description: (
|
||||
<>
|
||||
<p>
|
||||
<Translate>
|
||||
KubeVela works as an application
|
||||
delivery control plane that is fully runtime agnostic. It can
|
||||
deploy and operate any
|
||||
application components including containers, cloud functions, databases,
|
||||
delivery control plane that is fully decoupled from runtime
|
||||
infrastructure. It can deploy and manage any
|
||||
application types including containers, cloud services, databases,
|
||||
or even EC2 instances across hybrid environments, following the
|
||||
workflow you defined.</Translate>
|
||||
workflow you designed.</Translate>
|
||||
</p>
|
||||
</>
|
||||
),
|
||||
|
|
|
|||
|
|
@ -14,11 +14,13 @@ We will use the well-known [bookinfo](https://istio.io/latest/docs/examples/book
|
|||
|
||||
## Preparation
|
||||
|
||||
Install the Istio cluster plugin.
|
||||
If your cluster haven't installed Istio. Install the Istio cluster plugin.
|
||||
```shell
|
||||
vela addon enable istio
|
||||
```
|
||||
|
||||
Otherwise, you just need apply these 4 YAML files under this [path](https://github.com/oam-dev/kubevela/tree/master/vela-templates/addons/istio/definitions)
|
||||
|
||||
The default namespace needs to be labeled so that Istio will auto-inject sidecar.
|
||||
|
||||
```shell
|
||||
|
|
|
|||
|
|
@ -1,12 +1,12 @@
|
|||
---
|
||||
title: Application
|
||||
title: The Application Model
|
||||
---
|
||||
|
||||
KubeVela takes Application as the basis of modeling, uses Components and Traits to complete a set of application deployment plans. After you are familiar with these core concepts, you can develop in accordance with the user manual and administrator manual according to your needs.
|
||||
KubeVela introduces Open Application Model (OAM) to capture a full deployment of micro-services application across hybrid environments.
|
||||
|
||||
## Application
|
||||
|
||||
In modeling, the YAML file is the bearer of the application deployment plan. A typical YAML example is as follows:
|
||||
With this model, a typical deployment plan in KubeVela looks as below:
|
||||
|
||||
```yaml
|
||||
# sample.yaml
|
||||
|
|
@ -72,21 +72,9 @@ spec:
|
|||
env: prod
|
||||
```
|
||||
|
||||
|
||||
The fields here correspond to:
|
||||
|
||||
- apiVersion: The OAM API version used.
|
||||
- kind: of CRD Resourse Type. The one we use most often is Pod.
|
||||
- metadata: business-related information. For example, this time I want to create a website.
|
||||
- Spec: Describe what we need to deliver and tell Kubernetes what to make. Here we put the `components`, `policies` and `workflow` of KubeVela.
|
||||
- components: KubeVela's component system.
|
||||
- Traits: KubeVela's operation and maintenance feature system, works in component level.
|
||||
- Policies: KubeVela's application level policy.
|
||||
- Workflow: KubeVela's application level deployment workflow, you can custom every deployment step with it.
|
||||
|
||||
## Components
|
||||
|
||||
KubeVela has some built-in component types, you can find them by using [KubeVela CLI](../install#3-get-kubevela-cli):
|
||||
An application could be composed by multiple components. KubeVela already built-in with several widely used components definitions to help you model an application deployment, you can list them by using [KubeVela CLI](../install#3-get-kubevela-cli):
|
||||
|
||||
```
|
||||
vela components
|
||||
|
|
@ -112,14 +100,11 @@ alibaba-oss vela-system configurations.terraform.core.oam.dev Terraform configu
|
|||
alibaba-rds vela-system configurations.terraform.core.oam.dev Terraform configuration for Alibaba Cloud RDS object
|
||||
```
|
||||
|
||||
You can continue to use [Helm](../end-user/components/helm) and [Kustomize](../end-user/components/kustomize) components to deploy your application, an application is a deployment plan.
|
||||
|
||||
If you're a platform builder who's familiar with Kubernetes, you can learn to [define your custom component](../platform-engineers/components/custom-component) to extend every kind of component in KubeVela. Especially, [Terraform Components](../platform-engineers/components/component-terraform) is one of the best practice.
|
||||
|
||||
|
||||
## Traits
|
||||
|
||||
KubeVela also has many built-in traits, search them by using [KubeVela CLI](../install#3-get-kubevela-cli):
|
||||
Traits are operational behaviors that you can attach to component. KubeVela also has built-in traits installed, search them by using [KubeVela CLI](../install#3-get-kubevela-cli):
|
||||
|
||||
```
|
||||
vela traits
|
||||
|
|
@ -137,29 +122,20 @@ scaler vela-system webservice,worker false Manually
|
|||
sidecar vela-system deployments.apps true Inject a sidecar container to the component.
|
||||
```
|
||||
|
||||
You can learn how to bind trait by these detail docs, such as [ingress trait](../end-user/traits/ingress).
|
||||
|
||||
If you're a platform builder who's familiar with Kubernetes, you can learn to [define your custom trait](../platform-engineers/traits/customize-trait) to extend any operational capability for your users.
|
||||
|
||||
## Policy
|
||||
|
||||
Policy allows you to define application level capabilities, such as health check, security group, fire wall, SLO and so on.
|
||||
|
||||
Policy is similar to trait, but trait works for component while policy works for the whole application.
|
||||
Policy enforces deployment process of the application, such as quality gates, security groups, placement strategy, fire walls, SLO targets and so on.
|
||||
|
||||
## Workflow
|
||||
|
||||
In KubeVela, Workflow allows user to glue various operation and maintenance tasks into one process, and achieve automated and rapid delivery of cloud-native applications to any hybrid environment. From the design point of view, the Workflow is to customize the control logic: not only simply apply all resources, but also to provide some process-oriented flexibility. For example, the use of Workflow can help us implement complex operations such as pause, manual verification, waiting state, data flow transmission, multi-environment grayscale, and A/B testing.
|
||||
Workflow allows you to assemble components, operation and task steps into a DAG, and it is process-oriented. Typical workflow steps includes pause, manual verification, waiting state, data flow transmission, multi-environment grayscale, and A/B testing, etc.
|
||||
|
||||
The Workflow is based on modular design. Each Workflow module is defined by a Definition CRD and provided to users for operation through K8s API. As a "super glue", the Workflow module can combine any of your tools and processes through the CUE language. This allows you to create your own modules through a powerful declarative language and cloud-native APIs.
|
||||
Each workflow step is a independent capability entity that is fully plugable, KubeVela allows you to create your own step through CUE.
|
||||
|
||||
> Especially, workflow works in application level, if you specify workflow, the resources won't be deployed if you don't specify any step to deploy it.
|
||||
|
||||
If you're a platform builder who's familiar with Kubernetes, you can learn to [define your own workflow step by using CUE](../platform-engineers/workflow/workflow).
|
||||
|
||||
## What's Next
|
||||
|
||||
Here are some recommended next steps:
|
||||
|
||||
- Learn KubeVela's user guide to know how to deploy component, let's start from [helm component](../end-user/components/helm).
|
||||
- Learn KubeVela's admin guide to learn more about [the OAM model](../platform-engineers/oam/oam-model).
|
||||
- Start using KubeVela from deploying [Helm component](../end-user/components/helm).
|
||||
- Learn more about [Open Application Model](../platform-engineers/oam/oam-model).
|
||||
|
|
|
|||
|
|
@ -6,59 +6,34 @@ The overall architecture of KubeVela is shown as below:
|
|||
|
||||
|
||||
|
||||
## KubeVela is a Control Plane System
|
||||
|
||||
## API
|
||||
KubeVela orchestrates application components, cloud resources and pipeline over multiple clusters and hybrid environments. It is designed to be an application delivery and management control plane instead of a runtime plugin.
|
||||
|
||||
The API layer provides KubeVela APIs exposed to users for building application delivery platform and solutions.
|
||||
KubeVela APIs are declarative and application centric.
|
||||
It is based on Kubernetes CRDs to natively fit into the Kubernetes ecosystem.
|
||||
For easy integration with upstream CI pipelines and GitOps tools, KubeVela API (i.e. Open Application Model) are designed as declarative and application-centric, including:
|
||||
|
||||
The APIs can be categorized for two purposes:
|
||||
`Application` for designing application deployment plan.
|
||||
|
||||
- For **end users** to compose final application manifest to deploy.
|
||||
- Usually this contains only user-concerned config and hides infrastructure details.
|
||||
- Users will normally write the manifest in yaml format.
|
||||
- This currently includes Application only. But we may add more user-facing APIs, e.g. ApplicationSet to define multiple Applications.
|
||||
- For **platform admins** to define capability definitions to handle actual operations.
|
||||
- Each definition glues operational tasks using CUE and exposes user-concerned config only.
|
||||
- Admins will normally write the manifest in yaml + CUE format.
|
||||
- This currently includes Component, Trait, Policy, and Workflow definition types.
|
||||
`X-Definitions` for managing the abstraction and capabilities of KubeVela with CUE.
|
||||
- e.g. `ComponentDefinition`, `TraitDefinition`, etc.
|
||||
|
||||
The APIs are served by the control plane.
|
||||
Because it is so important that we put a separate section to talk about it.
|
||||
In implementation, KubeVela relies on a dedicated Kubernetes cluster to achieve above goals. We chose to rely on Kubernetes as the control plane implementation because this approach is battle tested and brings determinism, convergence and automation to application management at scale. In detail, KubeVela is composed by several parts:
|
||||
|
||||
## Control Plane
|
||||
- *Plugin Registry* that registers and manages `X-Definitions`.
|
||||
- *Core Controller* that provides the core control logic of the entire system. For example, handling KubeVela API resources, orchestrating workflow, storing revisions, parsing and executing CUE code, garbage collecting, etc.
|
||||
- *Addon Controllers* that register and manage built-in addons that KubeVela needed to work. For example, Flux and Terraform controller.
|
||||
|
||||
The control plane layers is where KubeVela puts the components central to the entire system.
|
||||
It is the first entry to handle user API requests, the central place to register plugins,
|
||||
and central processor to manage global states and dispatches tasks/resources.
|
||||
This control plane Kubernetes cluster will be referenced as the "control plane cluster" in the following documentation.
|
||||
|
||||
The control plane contains three major parts:
|
||||
### Runtime Infrastructure
|
||||
|
||||
- **Plugin registry** stores and manages X-Definitions.
|
||||
X-Definitions are CRDs that users can apply and get via kubectl.
|
||||
There are additional backend functions to store and manage multiple versions of X-Definitions.
|
||||
- **Core Control** provides the core control logic to the entire system.
|
||||
It consists of the core components that are hanlding Application, X-Definition API requests,
|
||||
orchestrating Workflows, storing revisions of Applications and Components,
|
||||
parsing and executing CUE fields, garbage collecting unused resources.
|
||||
- **Builtin Controllers** registers builtin plugins and provides the backing controllers for the resources
|
||||
created by X-Definitions. These are core to the KubeVela ecosystem that we believe everyone will use.
|
||||
The runtime infrastructure is where the applications are actually running on.
|
||||
KubeVela itself is fully runtime infrastructure agnostic and hence allows you to deploy application to both Kubernetes based infrastructure and non-Kubernetes environments such as cloud platforms and edge devices.
|
||||
|
||||
The control plane (including API layer) is KubeVela per se.
|
||||
Technically speaking, KubeVela is a control plane to manage applications over multiple clusters, hybrid environments.
|
||||
## KubeVela is Programmable
|
||||
|
||||
## Execution
|
||||
In real world, application deployment tends to be complex and varies from teams, environments and scenarios. Hence, KubeVela introduced a fully programmable approach to implement its deployment model so it can adapt to every need of your application delivery use case in-place.
|
||||
|
||||
The execution layer is where the applications are actually running on.
|
||||
KubeVela allows you to deploy and manage application resources in a consistent workflow onto both
|
||||
Kubernetes cluster (e.g. local, managed offerings, IoT/edge, on-prem)
|
||||
and non-Kubernetes environments on clouds.
|
||||
KubeVela itself does not run on the execution infrastructures, but manage them instead.
|
||||
|
||||
|
||||
## What's Next
|
||||
|
||||
Here are some recommended next steps:
|
||||
|
||||
- Learn KubeVela's Application to know the basics of how to building App Delivery, let's start from [Application](./application).
|
||||
- Learn KubeVela's admin guide to learn more about [the OAM model](../platform-engineers/oam/oam-model).
|
||||
For learning how to program KubeVela in detail, please check the `Administrator Manuals` in the documentation site.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Raw
|
||||
title: Raw Template
|
||||
---
|
||||
|
||||
Use raw Kubernetes resources directly. For example, a Job.
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ KubeVela's `kustomize` component meets the needs of users to directly connect Ya
|
|||
Let's take the YAML folder component from the OSS bucket registry as an example to explain the usage. In the `Application` this time, I hope to deliver a component named bucket-comp. The deployment file corresponding to the component is stored in the cloud storage OSS bucket, and the corresponding bucket name is definition-registry. `kustomize.yaml` comes from this address of oss-cn-beijing.aliyuncs.com and the path is `./app/prod/`.
|
||||
|
||||
|
||||
1. (Opentional) If your OSS bucket needs identity verification, create a Secret:
|
||||
1. (Optional) If your OSS bucket needs identity verification, create a Secret:
|
||||
|
||||
```shell
|
||||
$ kubectl create secret generic bucket-secret --from-literal=accesskey=<your-ak> --from-literal=secretkey=<your-sk>
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Want More？
|
||||
title: Needs More？
|
||||
---
|
||||
|
||||
## 1. Get from capability registry
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Multi-Environment Deployment
|
||||
title: Multi-Environment Policy
|
||||
---
|
||||
|
||||
This documentation will introduce how to use env-binding to automate multi-stage application rollout across multiple environments.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Health Status Check
|
||||
title: Health Check Policy
|
||||
---
|
||||
|
||||
This documentation will introduce how to use `health` policy to apply periodical
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Want More?
|
||||
title: Needs More?
|
||||
---
|
||||
|
||||
## 1. Get from capability registry
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Version Control
|
||||
title: Revisioning
|
||||
---
|
||||
|
||||
## Component Revision
|
||||
|
|
|
|||
|
|
@ -0,0 +1,269 @@
|
|||
---
|
||||
title: Built-in Steps
|
||||
---
|
||||
|
||||
This documentation will walk through the built-in workflow steps that you can use to design an application deployment process.
|
||||
|
||||
## apply-application
|
||||
|
||||
### Overview
|
||||
|
||||
Apply all components and traits in Application.
|
||||
|
||||
### Parameter
|
||||
|
||||
No arguments, used for custom steps before or after application applied.
|
||||
|
||||
### Example
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: first-vela-workflow
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: express-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
traits:
|
||||
- type: ingress
|
||||
properties:
|
||||
domain: testsvc.example.com
|
||||
http:
|
||||
/: 8000
|
||||
workflow:
|
||||
steps:
|
||||
- name: express-server
|
||||
type: apply-application
|
||||
```
|
||||
|
||||
## depends-on-app
|
||||
|
||||
### Overview
|
||||
|
||||
Wait for the specified Application to complete.
|
||||
|
||||
### Parameter
|
||||
|
||||
| Name | Type | Description |
|
||||
| :-------: | :----: | :------------------------------: |
|
||||
| name | string | The name of the Application |
|
||||
| namespace | string | The namespace of the Application |
|
||||
|
||||
### Example
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: first-vela-workflow
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: express-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
traits:
|
||||
- type: ingress
|
||||
properties:
|
||||
domain: testsvc.example.com
|
||||
http:
|
||||
/: 8000
|
||||
workflow:
|
||||
steps:
|
||||
- name: express-server
|
||||
type: depends-on-app
|
||||
properties:
|
||||
name: another-app
|
||||
namespace: default
|
||||
```
|
||||
|
||||
## deploy2env
|
||||
|
||||
### Overview
|
||||
|
||||
Apply Application in different policies and envs.
|
||||
|
||||
### Parameter
|
||||
|
||||
| Name | Type | Description |
|
||||
| :----: | :----: | :--------------------: |
|
||||
| policy | string | The name of the policy |
|
||||
| env | string | The name of the env |
|
||||
|
||||
### Example
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: multi-env-demo
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: nginx-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: nginx:1.21
|
||||
port: 80
|
||||
|
||||
policies:
|
||||
- name: env
|
||||
type: env-binding
|
||||
properties:
|
||||
created: false
|
||||
envs:
|
||||
- name: test
|
||||
patch:
|
||||
components:
|
||||
- name: nginx-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: nginx:1.20
|
||||
port: 80
|
||||
placement:
|
||||
namespaceSelector:
|
||||
name: test
|
||||
- name: prod
|
||||
patch:
|
||||
components:
|
||||
- name: nginx-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: nginx:1.20
|
||||
port: 80
|
||||
placement:
|
||||
namespaceSelector:
|
||||
name: prod
|
||||
|
||||
workflow:
|
||||
steps:
|
||||
- name: deploy-test-server
|
||||
type: deploy2env
|
||||
properties:
|
||||
policy: env
|
||||
env: test
|
||||
- name: deploy-prod-server
|
||||
type: deploy2env
|
||||
properties:
|
||||
policy: env
|
||||
env: prod
|
||||
```
|
||||
|
||||
## webhook-notification
|
||||
|
||||
### Overview
|
||||
|
||||
Send messages to the webhook address.
|
||||
|
||||
### Parameters
|
||||
|
||||
| Name | Type | Description |
|
||||
| :--------------: | :----: | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| slack | Object | Optional, please fulfill its url and message if you want to send Slack messages |
|
||||
| slack.url | String | Required, the webhook address of Slack |
|
||||
| slack.message | Object | Required, the Slack messages you want to send, please follow [Slack messaging](https://api.slack.com/reference/messaging/payload) |
|
||||
| dingding | Object | Optional, please fulfill its url and message if you want to send DingTalk messages |
|
||||
| dingding.url | String | Required, the webhook address of DingTalk |
|
||||
| dingding.message | Object | Required, the DingTalk messages you want to send, please follow [DingTalk messaging](https://developers.dingtalk.com/document/robots/custom-robot-access/title-72m-8ag-pqw) | |
|
||||
|
||||
### Example
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: first-vela-workflow
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: express-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
traits:
|
||||
- type: ingress
|
||||
properties:
|
||||
domain: testsvc.example.com
|
||||
http:
|
||||
/: 8000
|
||||
workflow:
|
||||
steps:
|
||||
- name: dingtalk-message
|
||||
type: webhook-notification
|
||||
properties:
|
||||
dingding:
|
||||
# the DingTalk webhook address, please refer to: https://developers.dingtalk.com/document/robots/custom-robot-access
|
||||
url: xxx
|
||||
message:
|
||||
msgtype: text
|
||||
text:
|
||||
context: Workflow starting...
|
||||
- name: application
|
||||
type: apply-application
|
||||
- name: slack-message
|
||||
type: webhook-notification
|
||||
properties:
|
||||
slack:
|
||||
# the Slack webhook address, please refer to: https://api.slack.com/messaging/webhooks
|
||||
url: xxx
|
||||
message:
|
||||
text: Workflow ended.
|
||||
```
|
||||
|
||||
## suspend
|
||||
|
||||
### Overview
|
||||
|
||||
Suspend the current workflow, we can use `vela workflow resume appname` to resume the suspended workflow.
|
||||
|
||||
> For more information of `vela workflow`, please refer to [vela cli](../../cli/vela_workflow)。
|
||||
|
||||
### Parameter
|
||||
|
||||
| Name | Type | Description |
|
||||
| :---: | :---: | :---------: |
|
||||
| - | - | - |
|
||||
|
||||
### Example
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: first-vela-workflow
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: express-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
traits:
|
||||
- type: ingress
|
||||
properties:
|
||||
domain: testsvc.example.com
|
||||
http:
|
||||
/: 8000
|
||||
workflow:
|
||||
steps:
|
||||
- name: slack-message
|
||||
type: webhook-notification
|
||||
properties:
|
||||
slack:
|
||||
# the Slack webhook address, please refer to: https://api.slack.com/messaging/webhooks
|
||||
message:
|
||||
text: Ready to apply the application, ask the administrator to approve and resume the workflow.
|
||||
- name: manual-approval
|
||||
type: suspend
|
||||
- name: express-server
|
||||
type: apply-application
|
||||
```
|
||||
|
|
@ -15,13 +15,9 @@ Today the application teams are eager to find a platform that can simplify the a
|
|||
|
||||
## What is KubeVela?
|
||||
|
||||
KubeVela is a modern application platform that makes it easier and faster to deliver and manage applications across hybrid, multi-cloud environments. At the mean time, it is highly extensible and programmable, which can adapt to your needs as they grow. This is achieved by doing the following:
|
||||
KubeVela is a modern application platform that makes it easier and faster to deliver and manage applications across hybrid, multi-cloud environments. At the mean time, it is highly extensible and programmable, which can adapt to your needs as they grow.
|
||||
|
||||
**Application Centric** - KubeVela introduces [Open Application Model (OAM)](https://oam.dev/) as the consistent and application-focused API to capture a full deployment of microservices on top of hybrid environments. Placement strategy, traffic shifting and rolling update are declared at the perspective of application developers. No infrastructure level concern, only application level concepts.
|
||||
|
||||
**Programmable Workflow** - KubeVela leverages [CUE](https://cuelang.org/) as the implementation engine behind the model layer. This allows you to compose deployment workflow in a modular and declarative API, and automates any operational tasks in a programmable manner. No restrictions, natively extensible.
|
||||
|
||||
**Runtime Agnostic** - KubeVela works as an application delivery control plane that is fully runtime agnostic. It can deploy and manage any application components including containers, cloud functions, databases, or even EC2 instances across hybrid environments, following the workflow you defined.
|
||||
|
||||
|
||||
## Who should use KubeVela?
|
||||
|
||||
|
|
@ -74,6 +70,6 @@ Welcome onboard and sail Vela!
|
|||
Here are some recommended next steps:
|
||||
|
||||
- Start to [install KubeVela](./install).
|
||||
- Learn KubeVela's [Core Concepts](core-concepts/application).
|
||||
- Learn KubeVela's [Architecture](core-concepts/architecture).
|
||||
- Learn KubeVela's [core concepts](core-concepts/application).
|
||||
- Learn KubeVela's [architecture](core-concepts/architecture).
|
||||
|
||||
|
|
|
|||
|
|
@ -4,44 +4,46 @@ title: Deploy First Application
|
|||
|
||||
Welcome to KubeVela! In this guide, we'll walk you through how to install KubeVela, and deploy your first simple application.
|
||||
|
||||
## Step 1: Install
|
||||
## Installation
|
||||
|
||||
Make sure you have finished and verified the installation following [this guide](install).
|
||||
Make sure you have finished and verified KubeVela installation following [this guide](install).
|
||||
|
||||
## Step 2: Deploy Your First Application
|
||||
## A Simple Application
|
||||
|
||||
Run the following command:
|
||||
A simple deployment definition in KubeVela looks as below:
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: first-vela-app
|
||||
spec:
|
||||
components:
|
||||
- name: express-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
traits:
|
||||
- type: ingress-1-20
|
||||
properties:
|
||||
domain: testsvc.example.com
|
||||
http:
|
||||
"/": 8000
|
||||
```
|
||||
|
||||
Now deploy it to KubeVela:
|
||||
|
||||
```bash
|
||||
kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/docs/examples/vela-app.yaml
|
||||
```
|
||||
|
||||
This will apply an application to KubeVela and let it distribute the application to proper runtime infrastructure.
|
||||
This command will deploy a web service component to target environment, which in our case is the Kubernetes cluster that KubeVela itself is installed.
|
||||
|
||||
|
||||
Check the status until we see `status` is `running` and services are `healthy`:
|
||||
|
||||
```bash
|
||||
$ kubectl get application first-vela-app -o yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
...
|
||||
status:
|
||||
...
|
||||
services:
|
||||
- healthy: true
|
||||
name: express-server
|
||||
traits:
|
||||
- healthy: true
|
||||
message: 'Visiting URL: testsvc.example.com, IP: your ip address'
|
||||
type: ingress
|
||||
status: running
|
||||
```
|
||||
|
||||
You can now directly visit the application (regardless of where it is running).
|
||||
After deployed, you can now directly visit this application as it already attached with a `ingress` trait (assume your cluster has Ingress enabled).
|
||||
|
||||
```
|
||||
$ curl -H "Host:testsvc.example.com" http://<your ip address>/
|
||||
$ curl -H "Host:testsvc.example.com" http://<some ip address>/
|
||||
<xmp>
|
||||
Hello World
|
||||
|
||||
|
|
@ -56,11 +58,195 @@ Hello World
|
|||
`'--.._\..--''
|
||||
</xmp>
|
||||
```
|
||||
**Voila!** You are all set to go.
|
||||
|
||||
## Deploy More Components
|
||||
|
||||
KubeVela allows you to deploy diverse components types. In above example, the `Web Service` component is actually a predefined [CUE](https://cuelang.org/) module.
|
||||
|
||||
You can also try:
|
||||
|
||||
### Helm components
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: app-delivering-chart
|
||||
spec:
|
||||
components:
|
||||
- name: redis-comp
|
||||
type: helm
|
||||
properties:
|
||||
chart: redis-cluster
|
||||
version: 6.2.7
|
||||
url: https://charts.bitnami.com/bitnami
|
||||
repoType: helm
|
||||
```
|
||||
|
||||
### Terraform components
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: rds-cloud-source
|
||||
spec:
|
||||
components:
|
||||
- name: sample-db
|
||||
type: alibaba-rds
|
||||
properties:
|
||||
instance_name: sample-db
|
||||
account_name: oamtest
|
||||
password: U34rfwefwefffaked
|
||||
writeConnectionSecretToRef:
|
||||
name: db-conn
|
||||
```
|
||||
|
||||
### Components from Git repository
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: git-app
|
||||
spec:
|
||||
components:
|
||||
- name: git-comp
|
||||
type: kustomize
|
||||
properties:
|
||||
repoType: git
|
||||
url: https://github.com/<path>/<to>/<repo>
|
||||
git:
|
||||
branch: master
|
||||
path: ./app/dev/
|
||||
```
|
||||
|
||||
... and many many more. Please check the `Deploying Components` section under `User Manuals` for all supported types, and even go ahead to add your own.
|
||||
|
||||
## Attach Operational Behaviors
|
||||
|
||||
KubeVela is not just about deploy. It allows you to attach predefined operational behaviors (named `Traits`) to your components in-place. For example, let's assign a batch rollout strategy to our web service:
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: rollout-trait-test
|
||||
spec:
|
||||
components:
|
||||
- name: express-server
|
||||
type: webservice
|
||||
externalRevision: express-server-v1
|
||||
properties:
|
||||
image: stefanprodan/podinfo:4.0.3
|
||||
traits:
|
||||
- type: rollout
|
||||
properties:
|
||||
targetSize: 5
|
||||
rolloutBatches:
|
||||
- replicas: 2
|
||||
- replicas: 3
|
||||
```
|
||||
|
||||
Now whenever the image version is updated in above YAML file, the `express-server` component will rollout following strategy defined in `rolloutBatches`.
|
||||
|
||||
For all supported traits in KubeVela, please check `Attaching Traits` section under `User Manuals`. Not surprisingly, you can also add your own traits to KubeVela with just minimal effort.
|
||||
|
||||
## Define Policies and Workflow
|
||||
|
||||
Components and traits are just the beginning of your vela sail. KubeVela is by design a full functional Continuous Delivery (CD) platform with fine grained support for hybrid/multi-cloud/multi-cluster deployment.
|
||||
|
||||
Let's say:
|
||||
|
||||
> I want to deploy an micro-services application with two components, firstly to staging cluster with only 1 instance, then pause and wait for manual approval. If approved, then deploy it to production cluster but with instances scaled to 3.
|
||||
|
||||
Oops, imagine how many add-hoc scripts and glue code are needed in your CI/CD pipeline to achieve automation and deployment success rate in above process.
|
||||
|
||||
While with KubeVela, above process can be easily modeled as a declarative deployment plan as below:
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: example-app
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: hello-world-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
traits:
|
||||
- type: scaler
|
||||
properties:
|
||||
replicas: 1
|
||||
- name: data-worker
|
||||
type: worker
|
||||
properties:
|
||||
image: busybox
|
||||
cmd:
|
||||
- sleep
|
||||
- '1000000'
|
||||
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
|
||||
|
||||
- name: health-policy-demo
|
||||
type: health
|
||||
properties:
|
||||
probeInterval: 5
|
||||
probeTimeout: 10
|
||||
|
||||
workflow:
|
||||
steps:
|
||||
# deploy to staging env
|
||||
- name: deploy-staging
|
||||
type: deploy2env
|
||||
properties:
|
||||
policy: example-multi-env-policy
|
||||
env: staging
|
||||
|
||||
# manual check
|
||||
- name: manual-approval
|
||||
type: suspend
|
||||
|
||||
# deploy to prod env
|
||||
- name: deploy-prod
|
||||
type: deploy2env
|
||||
properties:
|
||||
policy: example-multi-env-policy
|
||||
env: prod
|
||||
```
|
||||
|
||||
No more add-hoc scripts or glue code, KubeVela will get the application delivery workflow done with full automation and determinism. Most importantly, KubeVela expects you keep using the CI solutions you are already familiar with and KubeVela is fully complementary to them as the CD control plane.
|
||||
|
||||
For using KubeVela with your own CI pipelines and other tools, please check `Best Practices` section in the sidebar for more real world examples.
|
||||
|
||||
## What's Next
|
||||
|
||||
Here are some recommended next steps:
|
||||
|
||||
- Learn KubeVela's [Core Concepts](./core-concepts/application).
|
||||
- Learn KubeVela's [Architecture](./core-concepts/architecture).
|
||||
All above features are just the first glance of KubeVela. For next steps, we recommend:
|
||||
- Learn KubeVela's [application model](./core-concepts/application).
|
||||
- Interested in KubeVela itself? Learn its [design and architecture](./core-concepts/architecture).
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 464 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 429 KiB After Width: | Height: | Size: 272 KiB |
|
|
@ -2,10 +2,10 @@
|
|||
title: KubeVela Roadmap
|
||||
---
|
||||
|
||||
- [2021 Winter Roadmap](/docs/roadmap/2021-12-roadmap)
|
||||
- [2021 Fall Roadmap](/docs/roadmap/2021-09-roadmap)
|
||||
- [2021 Summer Roadmap](/docs/roadmap/2021-06-roadmap)
|
||||
- [2021 Spring Roadmap](/docs/roadmap/2021-03-roadmap)
|
||||
- [2020 Winter Roadmap](/docs/roadmap/2020-12-roadmap)
|
||||
- [2021 Winter Roadmap](/docs/next/roadmap/2021-12-roadmap)
|
||||
- [2021 Fall Roadmap](/docs/next/roadmap/2021-09-roadmap)
|
||||
- [2021 Summer Roadmap](/docs/next/roadmap/2021-06-roadmap)
|
||||
- [2021 Spring Roadmap](/docs/next/roadmap/2021-03-roadmap)
|
||||
- [2020 Winter Roadmap](/docs/next/roadmap/2020-12-roadmap)
|
||||
|
||||
To learn more details, please visit the [github issues list](https://github.com/oam-dev/kubevela/issues) and milestones.
|
||||
|
|
@ -65,7 +65,7 @@
|
|||
{
|
||||
"collapsed": true,
|
||||
"type": "category",
|
||||
"label": "Components",
|
||||
"label": "Deploying Components",
|
||||
"items": [
|
||||
{
|
||||
"type": "doc",
|
||||
|
|
@ -112,7 +112,7 @@
|
|||
{
|
||||
"collapsed": true,
|
||||
"type": "category",
|
||||
"label": "CUE Components",
|
||||
"label": "CUE",
|
||||
"items": [
|
||||
{
|
||||
"type": "doc",
|
||||
|
|
@ -125,13 +125,13 @@
|
|||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.1/end-user/components/cue/task"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.1/end-user/components/cue/raw"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.1/end-user/components/cue/raw"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.1/end-user/components/more"
|
||||
|
|
@ -141,7 +141,7 @@
|
|||
{
|
||||
"collapsed": true,
|
||||
"type": "category",
|
||||
"label": "Traits",
|
||||
"label": "Attaching Traits",
|
||||
"items": [
|
||||
{
|
||||
"type": "doc",
|
||||
|
|
@ -180,7 +180,7 @@
|
|||
{
|
||||
"collapsed": true,
|
||||
"type": "category",
|
||||
"label": "Policies",
|
||||
"label": "Defining Policies",
|
||||
"items": [
|
||||
{
|
||||
"type": "doc",
|
||||
|
|
@ -195,8 +195,12 @@
|
|||
{
|
||||
"collapsed": true,
|
||||
"type": "category",
|
||||
"label": "Workflow",
|
||||
"label": "Designing Workflow",
|
||||
"items": [
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.1/end-user/workflow/built-in-workflow-defs"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.1/end-user/workflow/webhook-notification"
|
||||
|
|
@ -299,10 +303,6 @@
|
|||
"type": "doc",
|
||||
"id": "version-v1.1/platform-engineers/workflow/workflow"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.1/platform-engineers/workflow/built-in-workflow-defs"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.1/platform-engineers/workflow/cue-actions"
|
||||
|
|
|
|||
Loading…
Reference in New Issue