Docs v1.1 new structure (#135)
* Update sidebar to v1.1 * adding getting-started * v1.1 new docs structure * First half of new infra on v1.1 * Second half of new infra on v1.1 * [Fix] rollback of Versioned related docs * remove version-v0.3.5 * [FIX] en doc couldn't diaplay Co-authored-by: 段少 <duanwei.duan@alibaba-inc.com>
This commit is contained in:
Wei (段少)
GitHub
parent
83a07e09f2
commit
765f448aab
|
|
@ -19,7 +19,7 @@ https://github.com/oam-dev/kubevela.io/blob/main/static/img/zh-CN-dingding-group
|
||||||
|
|
||||||
#### 准备工作
|
#### 准备工作
|
||||||
|
|
||||||
- 账号：您需要先准备一个 GitHub 账号。使用 Github 进行翻译任务的认领和 PR 提交。
|
- 账号：你需要先准备一个 GitHub 账号。使用 Github 进行翻译任务的认领和 PR 提交。
|
||||||
- 仓库和分支管理
|
- 仓库和分支管理
|
||||||
- fork [kubevela.io](https://github.com/oam-dev/kubevela.io) 的仓库，并作为自己仓库的上游： `git remote add upstream https://github.com/oam-dev/kubevela.io.git`
|
- fork [kubevela.io](https://github.com/oam-dev/kubevela.io) 的仓库，并作为自己仓库的上游： `git remote add upstream https://github.com/oam-dev/kubevela.io.git`
|
||||||
- 在自己的仓库，也就是 origin 上进行翻译；
|
- 在自己的仓库，也就是 origin 上进行翻译；
|
||||||
|
|
|
||||||
|
|
@ -29,7 +29,7 @@ KubeVela v1.0 启用了新的官网架构和文档维护方式，新增功能包
|
||||||
|
|
||||||
#### 准备工作
|
#### 准备工作
|
||||||
|
|
||||||
- 账号：您需要先准备一个 GitHub 账号。使用 Github 进行翻译任务的认领和 PR 提交。
|
- 账号：你需要先准备一个 GitHub 账号。使用 Github 进行翻译任务的认领和 PR 提交。
|
||||||
- 仓库和分支管理
|
- 仓库和分支管理
|
||||||
- fork [kubevela.io](https://github.com/oam-dev/kubevela.io) 的仓库，并作为自己仓库的上游： `git remote add upstream https://github.com/oam-dev/kubevela.io.git`
|
- fork [kubevela.io](https://github.com/oam-dev/kubevela.io) 的仓库，并作为自己仓库的上游： `git remote add upstream https://github.com/oam-dev/kubevela.io.git`
|
||||||
- 在自己的仓库，也就是 origin 上进行翻译；
|
- 在自己的仓库，也就是 origin 上进行翻译；
|
||||||
|
|
|
||||||
|
|
@ -14,11 +14,11 @@ KubeVela is a modern application platform that makes deploying and managing appl
|
||||||
|
|
||||||
## Installation
|
## Installation
|
||||||
|
|
||||||
Installation guide is available on [this section](./install).
|
Installation guide is available on [this section](getting-started/quick-install).
|
||||||
|
|
||||||
## Quick Start
|
## Quick Start
|
||||||
|
|
||||||
Quick start is available on [this section](./quick-start).
|
Quick start is available on [this section](getting-started/first-application).
|
||||||
|
|
||||||
## Contributing
|
## Contributing
|
||||||
Check out [CONTRIBUTING](https://github.com/oam-dev/kubevela/blob/master/CONTRIBUTING.md) to see how to develop with KubeVela.
|
Check out [CONTRIBUTING](https://github.com/oam-dev/kubevela/blob/master/CONTRIBUTING.md) to see how to develop with KubeVela.
|
||||||
|
|
|
||||||
|
|
@ -1,46 +0,0 @@
|
||||||
---
|
|
||||||
title: How it Works
|
|
||||||
---
|
|
||||||
|
|
||||||
In this documentation, we will explain the core idea of KubeVela and clarify some technical terms that are widely used in the project.
|
|
||||||
|
|
||||||
## API
|
|
||||||
|
|
||||||
On control plane, KubeVela introduces [Open Application Model (OAM)](https://oam.dev) as the main API to model a full deployment of modern microservices application. This API could be explained as below:
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
In detail:
|
|
||||||
- Components - deployable/provisionable entities that compose your application.
|
|
||||||
- e.g. a Helm chart, a Kubernetes workload, a Terraform module, or a cloud database instance etc.
|
|
||||||
- Traits - attachable features that will *overlay* given component with operational behaviors.
|
|
||||||
- e.g. autoscaling rules, rollout strategies, ingress rules, sidecars, security policies etc.
|
|
||||||
- Application - full description of your application deployment assembled with components and traits.
|
|
||||||
- Environment - the target environments to deploy this application.
|
|
||||||
|
|
||||||
We also reference components and traits as *"capabilities"* in KubeVela.
|
|
||||||
|
|
||||||
## Workflow
|
|
||||||
|
|
||||||
To ensure simple yet consistent user experience across hybrid environments. KubeVela introduces a workflow with separate of concerns as below:
|
|
||||||
- **Platform Team**
|
|
||||||
- Model and manage platform capabilities as components or traits, together with target environments specifications.
|
|
||||||
- **Application Team**
|
|
||||||
- Choose a environment, assemble the application with components and traits per needs, and deploy it to target environment.
|
|
||||||
|
|
||||||
> Note that either platform team or application team application will only talk to the control plane cluster. KubeVela is designed to hide the details of runtime infrastructures except for debugging or verifying purpose.
|
|
||||||
|
|
||||||
Below is how this workflow looks like:
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
All the capability building blocks can be updated or extended easily at any time since they are fully programmable via CUE.
|
|
||||||
|
|
||||||
## Environment
|
|
||||||
Before releasing an application to production, it's important to test the code in testing/staging workspaces. In KubeVela, we describe these workspaces as "environments". Each environment has its own configuration (e.g., domain, Kubernetes cluster and namespace, configuration data, access control policy, etc.) to allow user to create different deployment environments such as "test" and "production".
|
|
||||||
|
|
||||||
## What's Next
|
|
||||||
|
|
||||||
Here are some recommended next steps:
|
|
||||||
|
|
||||||
- Learn how to [deploy an application](end-user/application) in detail and understand how it works.
|
|
||||||
|
|
@ -0,0 +1,5 @@
|
||||||
|
---
|
||||||
|
title: Application
|
||||||
|
---
|
||||||
|
|
||||||
|
TBD
|
||||||
|
|
@ -0,0 +1,5 @@
|
||||||
|
---
|
||||||
|
title: Infrastructure
|
||||||
|
---
|
||||||
|
|
||||||
|
TBD
|
||||||
|
|
@ -0,0 +1,5 @@
|
||||||
|
---
|
||||||
|
title: Workflow
|
||||||
|
---
|
||||||
|
|
||||||
|
TBD
|
||||||
|
|
@ -4,7 +4,7 @@ title: The Reference Documentation Guide of Capabilities
|
||||||
|
|
||||||
In this documentation, we will show how to check the detailed schema of a given capability (i.e. workload type or trait).
|
In this documentation, we will show how to check the detailed schema of a given capability (i.e. workload type or trait).
|
||||||
|
|
||||||
This may sound challenging because every capability is a "plug-in" in KubeVela (even for the built-in ones), also, it's by design that KubeVela allows platform administrators to modify the capability templates at any time. In this case, do we need to manually write documentation for every newly installed capability? And how can we ensure those documentations for the system is up-to-date?
|
This may sound challenging because every capability is a "plug-in" in KubeVela (even for the built-in ones), also, it's by design that KubeVela allows platform platform-engineerss to modify the capability templates at any time. In this case, do we need to manually write documentation for every newly installed capability? And how can we ensure those documentations for the system is up-to-date?
|
||||||
|
|
||||||
## Using Browser
|
## Using Browser
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -72,7 +72,7 @@ Services:
|
||||||
- route: Visiting URL: http://example.com IP: <ingress-IP-address>
|
- route: Visiting URL: http://example.com IP: <ingress-IP-address>
|
||||||
```
|
```
|
||||||
|
|
||||||
**In [kind cluster setup](../../install#kind)**, you can visit the service via localhost:
|
**In [kind cluster setup](../../getting-started/quick-install#kind)**, you can visit the service via localhost:
|
||||||
|
|
||||||
> If not in kind cluster, replace 'localhost' with ingress address
|
> If not in kind cluster, replace 'localhost' with ingress address
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -35,7 +35,7 @@ Under the hood, `Appfile` will build the image from source code, and then genera
|
||||||
|
|
||||||
## Schema
|
## Schema
|
||||||
|
|
||||||
> Before learning about Appfile's detailed schema, we recommend you to get familiar with [core concepts](../concepts) in KubeVela.
|
> Before learning about Appfile's detailed schema, we recommend you to get familiar with core concepts in KubeVela.
|
||||||
|
|
||||||
|
|
||||||
```yaml
|
```yaml
|
||||||
|
|
@ -81,7 +81,7 @@ In the following workflow, we will build and deploy an example NodeJS app under
|
||||||
### Prerequisites
|
### Prerequisites
|
||||||
|
|
||||||
- [Docker](https://docs.docker.com/get-docker/) installed on the host
|
- [Docker](https://docs.docker.com/get-docker/) installed on the host
|
||||||
- [KubeVela](../install) installed and configured
|
- KubeVela] installed and configured
|
||||||
|
|
||||||
### 1. Download test app code
|
### 1. Download test app code
|
||||||
|
|
||||||
|
|
@ -165,7 +165,7 @@ vela status testapp
|
||||||
|
|
||||||
#### Alternative: Local testing without pushing image remotely
|
#### Alternative: Local testing without pushing image remotely
|
||||||
|
|
||||||
If you have local [kind](../install) cluster running, you may try the local push option. No remote container registry is needed in this case.
|
If you have local kind cluster running, you may try the local push option. No remote container registry is needed in this case.
|
||||||
|
|
||||||
Add local option to `build`:
|
Add local option to `build`:
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -8,7 +8,7 @@ Install vela kubectl plugin can help you to ship applications more easily!
|
||||||
|
|
||||||
## Installation
|
## Installation
|
||||||
|
|
||||||
See [advanced-install](../../advanced-install#install-kubectl-vela-plugin)
|
See [advanced-install](../../platform-engineers/advanced-install)
|
||||||
|
|
||||||
## Usage
|
## Usage
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,238 +0,0 @@
|
||||||
---
|
|
||||||
title: Application
|
|
||||||
---
|
|
||||||
|
|
||||||
This documentation will walk through how to use KubeVela to design a simple application without any polices or placement rule defined.
|
|
||||||
|
|
||||||
> Note: since you didn't declare placement rule, KubeVela will deploy this application directly to the control plane cluster (i.e. the cluster your `kubectl` is talking to). This is also the same case if you are using local cluster such as KinD or MiniKube to play KubeVela.
|
|
||||||
|
|
||||||
## Step 1: Check Available Components
|
|
||||||
|
|
||||||
Components are deployable or provisionable entities that compose your application. It could be a Helm chart, a simple Kubernetes workload, a CUE or Terraform module, or a cloud database etc.
|
|
||||||
|
|
||||||
Let's check the available components in fresh new KubeVela.
|
|
||||||
|
|
||||||
```shell
|
|
||||||
kubectl get comp -n vela-system
|
|
||||||
```
|
|
||||||
```console
|
|
||||||
NAME WORKLOAD-KIND DESCRIPTION
|
|
||||||
task Job Describes jobs that run code or a script to completion.
|
|
||||||
webservice Deployment Describes long-running, scalable, containerized services that have a stable network endpoint to receive external network traffic from customers.
|
|
||||||
worker Deployment Describes long-running, scalable, containerized services that running at backend. They do NOT have network endpoint to receive external network traffic.
|
|
||||||
```
|
|
||||||
|
|
||||||
To show the specification for given component, you could use `vela show`.
|
|
||||||
|
|
||||||
```shell
|
|
||||||
kubectl vela show webservice
|
|
||||||
```
|
|
||||||
```console
|
|
||||||
# Properties
|
|
||||||
+------------------+----------------------------------------------------------------------------------+-----------------------+----------+---------+
|
|
||||||
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
|
|
||||||
+------------------+----------------------------------------------------------------------------------+-----------------------+----------+---------+
|
|
||||||
| cmd | Commands to run in the container | []string | false | |
|
|
||||||
| env | Define arguments by using environment variables | [[]env](#env) | false | |
|
|
||||||
| addRevisionLabel | | bool | true | false |
|
|
||||||
| image | Which image would you like to use for your service | string | true | |
|
|
||||||
| port | Which port do you want customer traffic sent to | int | true | 80 |
|
|
||||||
| cpu | Number of CPU units for the service, like `0.5` (0.5 CPU core), `1` (1 CPU core) | string | false | |
|
|
||||||
| volumes | Declare volumes and volumeMounts | [[]volumes](#volumes) | false | |
|
|
||||||
+------------------+----------------------------------------------------------------------------------+-----------------------+----------+---------+
|
|
||||||
... // skip other fields
|
|
||||||
```
|
|
||||||
|
|
||||||
> Tips: `vela show xxx --web` will open its capability reference documentation in your default browser.
|
|
||||||
|
|
||||||
You could always [add more components](components/more) to the platform at any time.
|
|
||||||
|
|
||||||
## Step 2: Declare an Application
|
|
||||||
|
|
||||||
Application is the full description of a deployment. Let's define an application that deploys a *Web Service* and a *Worker* components.
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
# sample.yaml
|
|
||||||
apiVersion: core.oam.dev/v1beta1
|
|
||||||
kind: Application
|
|
||||||
metadata:
|
|
||||||
name: website
|
|
||||||
spec:
|
|
||||||
components:
|
|
||||||
- name: frontend
|
|
||||||
type: webservice
|
|
||||||
properties:
|
|
||||||
image: nginx
|
|
||||||
- name: backend
|
|
||||||
type: worker
|
|
||||||
properties:
|
|
||||||
image: busybox
|
|
||||||
cmd:
|
|
||||||
- sleep
|
|
||||||
- '1000'
|
|
||||||
```
|
|
||||||
|
|
||||||
## Step 3: Attach Traits
|
|
||||||
|
|
||||||
Traits are platform provided features that could *overlay* a given component with extra operational behaviors.
|
|
||||||
|
|
||||||
```shell
|
|
||||||
kubectl get trait -n vela-system
|
|
||||||
```
|
|
||||||
```console
|
|
||||||
NAME APPLIES-TO DESCRIPTION
|
|
||||||
cpuscaler [webservice worker] Automatically scale the component based on CPU usage.
|
|
||||||
ingress [webservice worker] Enable public web traffic for the component.
|
|
||||||
scaler [webservice worker] Manually scale the component.
|
|
||||||
sidecar [webservice worker] Inject a sidecar container to the component.
|
|
||||||
```
|
|
||||||
|
|
||||||
Let's check the specification of `sidecar` trait.
|
|
||||||
|
|
||||||
```shell
|
|
||||||
kubectl vela show sidecar
|
|
||||||
```
|
|
||||||
```console
|
|
||||||
# Properties
|
|
||||||
+---------+-----------------------------------------+----------+----------+---------+
|
|
||||||
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
|
|
||||||
+---------+-----------------------------------------+----------+----------+---------+
|
|
||||||
| name | Specify the name of sidecar container | string | true | |
|
|
||||||
| image | Specify the image of sidecar container | string | true | |
|
|
||||||
| command | Specify the commands run in the sidecar | []string | false | |
|
|
||||||
+---------+-----------------------------------------+----------+----------+---------+
|
|
||||||
```
|
|
||||||
|
|
||||||
Note that traits are designed to be *overlays*.
|
|
||||||
|
|
||||||
This means for `sidecar` trait, your `frontend` component doesn't need to have a sidecar template or bring a webhook to enable sidecar injection. Instead, KubeVela is able to patch a sidecar to its workload instance after it is generated by the component (no matter it's a Helm chart or CUE module) but before it is applied to runtime cluster.
|
|
||||||
|
|
||||||
Similarly, the system will assign a HPA instance based on the properties you set and "link" it to the target workload instance, the component itself is untouched.
|
|
||||||
|
|
||||||
Now let's attach `sidecar` and `cpuscaler` traits to the `frontend` component.
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
# sample.yaml
|
|
||||||
apiVersion: core.oam.dev/v1beta1
|
|
||||||
kind: Application
|
|
||||||
metadata:
|
|
||||||
name: website
|
|
||||||
spec:
|
|
||||||
components:
|
|
||||||
- name: frontend # This is the component I want to deploy
|
|
||||||
type: webservice
|
|
||||||
properties:
|
|
||||||
image: nginx
|
|
||||||
traits:
|
|
||||||
- type: cpuscaler # Automatically scale the component by CPU usage after deployed
|
|
||||||
properties:
|
|
||||||
min: 1
|
|
||||||
max: 10
|
|
||||||
cpuPercent: 60
|
|
||||||
- type: sidecar # Inject a fluentd sidecar before applying the component to runtime cluster
|
|
||||||
properties:
|
|
||||||
name: "sidecar-test"
|
|
||||||
image: "fluentd"
|
|
||||||
- name: backend
|
|
||||||
type: worker
|
|
||||||
properties:
|
|
||||||
image: busybox
|
|
||||||
cmd:
|
|
||||||
- sleep
|
|
||||||
- '1000'
|
|
||||||
```
|
|
||||||
|
|
||||||
## Step 4: Deploy the Application
|
|
||||||
|
|
||||||
```shell
|
|
||||||
kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/docs/examples/enduser/sample.yaml
|
|
||||||
```
|
|
||||||
```console
|
|
||||||
application.core.oam.dev/website created
|
|
||||||
```
|
|
||||||
|
|
||||||
You'll get the application becomes `running`.
|
|
||||||
|
|
||||||
```shell
|
|
||||||
kubectl get application
|
|
||||||
```
|
|
||||||
```console
|
|
||||||
NAME COMPONENT TYPE PHASE HEALTHY STATUS AGE
|
|
||||||
website frontend webservice running true 4m54s
|
|
||||||
```
|
|
||||||
|
|
||||||
Check the details of the application.
|
|
||||||
|
|
||||||
```shell
|
|
||||||
kubectl get app website -o yaml
|
|
||||||
```
|
|
||||||
```console
|
|
||||||
apiVersion: core.oam.dev/v1beta1
|
|
||||||
kind: Application
|
|
||||||
metadata:
|
|
||||||
generation: 1
|
|
||||||
name: website
|
|
||||||
namespace: default
|
|
||||||
spec:
|
|
||||||
components:
|
|
||||||
- name: frontend
|
|
||||||
properties:
|
|
||||||
image: nginx
|
|
||||||
traits:
|
|
||||||
- properties:
|
|
||||||
cpuPercent: 60
|
|
||||||
max: 10
|
|
||||||
min: 1
|
|
||||||
type: cpuscaler
|
|
||||||
- properties:
|
|
||||||
image: fluentd
|
|
||||||
name: sidecar-test
|
|
||||||
type: sidecar
|
|
||||||
type: webservice
|
|
||||||
- name: backend
|
|
||||||
properties:
|
|
||||||
cmd:
|
|
||||||
- sleep
|
|
||||||
- "1000"
|
|
||||||
image: busybox
|
|
||||||
type: worker
|
|
||||||
status:
|
|
||||||
...
|
|
||||||
latestRevision:
|
|
||||||
name: website-v1
|
|
||||||
revision: 1
|
|
||||||
revisionHash: e9e062e2cddfe5fb
|
|
||||||
services:
|
|
||||||
- healthy: true
|
|
||||||
name: frontend
|
|
||||||
traits:
|
|
||||||
- healthy: true
|
|
||||||
type: cpuscaler
|
|
||||||
- healthy: true
|
|
||||||
type: sidecar
|
|
||||||
- healthy: true
|
|
||||||
name: backend
|
|
||||||
status: running
|
|
||||||
```
|
|
||||||
|
|
||||||
Specifically:
|
|
||||||
|
|
||||||
1. `status.latestRevision` declares current revision of this deployment.
|
|
||||||
2. `status.services` declares the component created by this deployment and the healthy state.
|
|
||||||
3. `status.status` declares the global state of this deployment.
|
|
||||||
|
|
||||||
### List Revisions
|
|
||||||
|
|
||||||
When updating an application entity, KubeVela will create a new revision for this change.
|
|
||||||
|
|
||||||
When unused application revison number exceed `applicationRevisionLimit`（ default is 10 ）, KubeVela will remove the oldest revision.
|
|
||||||
|
|
||||||
```shell
|
|
||||||
kubectl get apprev -l app.oam.dev/name=website
|
|
||||||
```
|
|
||||||
```console
|
|
||||||
NAME AGE
|
|
||||||
website-v1 35m
|
|
||||||
```
|
|
||||||
|
|
||||||
Furthermore, the system will decide how to/whether to rollout the application based on the attached [rollout plan](scopes/rollout-plan).
|
|
||||||
|
|
@ -4,13 +4,13 @@ title: Cloud Services
|
||||||
|
|
||||||
KubeVela allows you to declare cloud services your application needs in consistent API. Currently, we support both Terraform and Crossplane.
|
KubeVela allows you to declare cloud services your application needs in consistent API. Currently, we support both Terraform and Crossplane.
|
||||||
|
|
||||||
> Please check [the platform team guide for cloud services](../../platform-engineers/cloud-services) if you are interested in how these capabilities are maintained in KubeVela.
|
> Please check [the platform-engineers guide for cloud services](../../platform-engineers/cloud-services) if you are interested in how these capabilities are maintained in KubeVela.
|
||||||
|
|
||||||
The cloud services will be consumed by the application via [Service Binding Trait](../traits/service-binding).
|
The cloud services will be consumed by the application via [Service Binding Trait](../traits/service-binding).
|
||||||
|
|
||||||
## Terraform
|
## Terraform
|
||||||
|
|
||||||
> ⚠️ This section assumes [Terraform related capabilities](../../platform-engineers/terraform) have been installed in your platform.
|
> ⚠️ This section assumes [Terraform related capabilities](../../platform-engineers/components/component-terraform) have been installed in your platform.
|
||||||
|
|
||||||
Check the parameters of cloud resource components and trait.
|
Check the parameters of cloud resource components and trait.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,5 @@
|
||||||
|
---
|
||||||
|
title: Alibaba-ROS
|
||||||
|
---
|
||||||
|
|
||||||
|
TBD
|
||||||
|
|
@ -0,0 +1,5 @@
|
||||||
|
---
|
||||||
|
title: RDS
|
||||||
|
---
|
||||||
|
|
||||||
|
TBD
|
||||||
|
|
@ -0,0 +1,5 @@
|
||||||
|
---
|
||||||
|
title: SLS
|
||||||
|
---
|
||||||
|
|
||||||
|
TBD
|
||||||
|
|
@ -0,0 +1,37 @@
|
||||||
|
---
|
||||||
|
title: Worker
|
||||||
|
---
|
||||||
|
|
||||||
|
## Description
|
||||||
|
|
||||||
|
Describes long-running, scalable, containerized services that running at backend. They do NOT have network endpoint to receive external network traffic.
|
||||||
|
|
||||||
|
## Samples
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
apiVersion: core.oam.dev/v1beta1
|
||||||
|
kind: Application
|
||||||
|
metadata:
|
||||||
|
name: app-worker
|
||||||
|
spec:
|
||||||
|
components:
|
||||||
|
- name: myworker
|
||||||
|
type: worker
|
||||||
|
properties:
|
||||||
|
image: "busybox"
|
||||||
|
cmd:
|
||||||
|
- sleep
|
||||||
|
- "1000"
|
||||||
|
```
|
||||||
|
|
||||||
|
## Specification
|
||||||
|
|
||||||
|
```console
|
||||||
|
# Properties
|
||||||
|
+-------+----------------------------------------------------+----------+----------+---------+
|
||||||
|
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
|
||||||
|
+-------+----------------------------------------------------+----------+----------+---------+
|
||||||
|
| cmd | Commands to run in the container | []string | false | |
|
||||||
|
| image | Which image would you like to use for your service | string | true | |
|
||||||
|
+-------+----------------------------------------------------+----------+----------+---------+
|
||||||
|
```
|
||||||
|
|
@ -0,0 +1,5 @@
|
||||||
|
---
|
||||||
|
title: Helm Components
|
||||||
|
---
|
||||||
|
|
||||||
|
TBD
|
||||||
|
|
@ -0,0 +1,5 @@
|
||||||
|
---
|
||||||
|
title: Helm Components
|
||||||
|
---
|
||||||
|
|
||||||
|
TBD
|
||||||
|
|
@ -6,7 +6,7 @@ Components in KubeVela are designed to be brought by users.
|
||||||
|
|
||||||
## 1. Get from capability center
|
## 1. Get from capability center
|
||||||
|
|
||||||
KubeVela allows you to explore capabilities maintained by platform team.
|
KubeVela allows you to explore capabilities maintained by platform-engineers.
|
||||||
There are two commands in kubectl vela plugin: `comp` and `trait`.
|
There are two commands in kubectl vela plugin: `comp` and `trait`.
|
||||||
|
|
||||||
In case you haven't installed kubectl vela plugin: see [this](../../developers/references/kubectl-plugin#install-kubectl-vela-plugin).
|
In case you haven't installed kubectl vela plugin: see [this](../../developers/references/kubectl-plugin#install-kubectl-vela-plugin).
|
||||||
|
|
@ -49,6 +49,6 @@ By default, the two commands will retrieve capabilities from [repo](https://regi
|
||||||
Check below documentations about how to bring your own components to the system in various approaches.
|
Check below documentations about how to bring your own components to the system in various approaches.
|
||||||
|
|
||||||
- [Helm](../../platform-engineers/helm/component) - Helm chart is a natural form of component, note that you need to have a valid Helm repository (e.g. GitHub repo or a Helm hub) to host the chart in this case.
|
- [Helm](../../platform-engineers/helm/component) - Helm chart is a natural form of component, note that you need to have a valid Helm repository (e.g. GitHub repo or a Helm hub) to host the chart in this case.
|
||||||
- [CUE](../../platform-engineers/cue/component) - CUE is powerful approach to encapsulate a component and it doesn't require any repository.
|
- [CUE](../../platform-engineers/components/component-cue) - CUE is powerful approach to encapsulate a component and it doesn't require any repository.
|
||||||
- [Simple Template](../../platform-engineers/kube/component) - Not a Helm or CUE expert? A simple template approach is also provided to define any Kubernetes API resource as a component. Note that only key-value style parameters are supported in this case.
|
- [Simple Template](../../platform-engineers/kube/component) - Not a Helm or CUE expert? A simple template approach is also provided to define any Kubernetes API resource as a component. Note that only key-value style parameters are supported in this case.
|
||||||
- [Cloud Services](../../platform-engineers/cloud-services) - KubeVela allows you to declare cloud services as part of the application and provision them in consistent API.
|
- [Cloud Services](../../platform-engineers/cloud-services) - KubeVela allows you to declare cloud services as part of the application and provision them in consistent API.
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,3 @@
|
||||||
|
---
|
||||||
|
title: 本地试运行
|
||||||
|
---
|
||||||
|
|
@ -1,117 +1,9 @@
|
||||||
---
|
---
|
||||||
title: Dry-Run and Live-Diff
|
title: Live-Diff
|
||||||
---
|
---
|
||||||
|
|
||||||
KubeVela allows you to dry-run and live-diff your application.
|
KubeVela allows you to dry-run and live-diff your application.
|
||||||
|
|
||||||
## Dry-Run the `Application`
|
|
||||||
|
|
||||||
Dry run will help you to understand what are the real resources which will to be expanded and deployed
|
|
||||||
to the Kubernetes cluster. In other words, it will mock to run the same logic as KubeVela's controller
|
|
||||||
and output the results locally.
|
|
||||||
|
|
||||||
For example, let's dry-run the following application:
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
# app.yaml
|
|
||||||
apiVersion: core.oam.dev/v1beta1
|
|
||||||
kind: Application
|
|
||||||
metadata:
|
|
||||||
name: vela-app
|
|
||||||
spec:
|
|
||||||
components:
|
|
||||||
- name: express-server
|
|
||||||
type: webservice
|
|
||||||
properties:
|
|
||||||
image: crccheck/hello-world
|
|
||||||
port: 8000
|
|
||||||
traits:
|
|
||||||
- type: ingress
|
|
||||||
properties:
|
|
||||||
domain: testsvc.example.com
|
|
||||||
http:
|
|
||||||
"/": 8000
|
|
||||||
```
|
|
||||||
|
|
||||||
```shell
|
|
||||||
kubectl vela dry-run -f app.yaml
|
|
||||||
```
|
|
||||||
```console
|
|
||||||
---
|
|
||||||
# Application(vela-app) -- Comopnent(express-server)
|
|
||||||
---
|
|
||||||
|
|
||||||
apiVersion: apps/v1
|
|
||||||
kind: Deployment
|
|
||||||
metadata:
|
|
||||||
labels:
|
|
||||||
app.oam.dev/appRevision: ""
|
|
||||||
app.oam.dev/component: express-server
|
|
||||||
app.oam.dev/name: vela-app
|
|
||||||
workload.oam.dev/type: webservice
|
|
||||||
spec:
|
|
||||||
selector:
|
|
||||||
matchLabels:
|
|
||||||
app.oam.dev/component: express-server
|
|
||||||
template:
|
|
||||||
metadata:
|
|
||||||
labels:
|
|
||||||
app.oam.dev/component: express-server
|
|
||||||
spec:
|
|
||||||
containers:
|
|
||||||
- image: crccheck/hello-world
|
|
||||||
name: express-server
|
|
||||||
ports:
|
|
||||||
- containerPort: 8000
|
|
||||||
|
|
||||||
---
|
|
||||||
apiVersion: v1
|
|
||||||
kind: Service
|
|
||||||
metadata:
|
|
||||||
labels:
|
|
||||||
app.oam.dev/appRevision: ""
|
|
||||||
app.oam.dev/component: express-server
|
|
||||||
app.oam.dev/name: vela-app
|
|
||||||
trait.oam.dev/resource: service
|
|
||||||
trait.oam.dev/type: ingress
|
|
||||||
name: express-server
|
|
||||||
spec:
|
|
||||||
ports:
|
|
||||||
- port: 8000
|
|
||||||
targetPort: 8000
|
|
||||||
selector:
|
|
||||||
app.oam.dev/component: express-server
|
|
||||||
|
|
||||||
---
|
|
||||||
apiVersion: networking.k8s.io/v1beta1
|
|
||||||
kind: Ingress
|
|
||||||
metadata:
|
|
||||||
labels:
|
|
||||||
app.oam.dev/appRevision: ""
|
|
||||||
app.oam.dev/component: express-server
|
|
||||||
app.oam.dev/name: vela-app
|
|
||||||
trait.oam.dev/resource: ingress
|
|
||||||
trait.oam.dev/type: ingress
|
|
||||||
name: express-server
|
|
||||||
spec:
|
|
||||||
rules:
|
|
||||||
- host: testsvc.example.com
|
|
||||||
http:
|
|
||||||
paths:
|
|
||||||
- backend:
|
|
||||||
serviceName: express-server
|
|
||||||
servicePort: 8000
|
|
||||||
path: /
|
|
||||||
|
|
||||||
---
|
|
||||||
```
|
|
||||||
|
|
||||||
In this example, the definitions(`webservice` and `ingress`) which `vela-app` depends on is the built-in
|
|
||||||
components and traits of KubeVela. You can also use `-d `or `--definitions` to specify your local definition files.
|
|
||||||
|
|
||||||
`-d `or `--definitions` permitting user to provide capability definitions used in the application from local files.
|
|
||||||
`dry-run` cmd will prioritize the provided capabilities than the living ones in the cluster.
|
|
||||||
|
|
||||||
## Live-Diff the `Application`
|
## Live-Diff the `Application`
|
||||||
|
|
||||||
Live-diff helps you to have a preview of what would change if you're going to upgrade an application without making any changes
|
Live-diff helps you to have a preview of what would change if you're going to upgrade an application without making any changes
|
||||||
|
|
@ -0,0 +1,3 @@
|
||||||
|
---
|
||||||
|
title: Initializer
|
||||||
|
---
|
||||||
|
|
@ -1,5 +1,5 @@
|
||||||
---
|
---
|
||||||
title: Progressive Rollout RoadMap
|
title: 概述
|
||||||
---
|
---
|
||||||
|
|
||||||
Here are some workitems on the roadmap
|
Here are some workitems on the roadmap
|
||||||
|
|
@ -1,67 +0,0 @@
|
||||||
---
|
|
||||||
title: Rollout Plan
|
|
||||||
---
|
|
||||||
In this documentation, we will show how to use the rollout plan to rolling update an application.
|
|
||||||
|
|
||||||
## Overview
|
|
||||||
|
|
||||||
By default, when we update the properties of application, KubeVela will update the underlying instances directly. The availability of the application will be guaranteed by rollout traits (if any).
|
|
||||||
|
|
||||||
Though KubeVela also provides a rolling style update mechanism, you can specify the `spec.rolloutPlan` in application to do so.
|
|
||||||
|
|
||||||
## Example
|
|
||||||
|
|
||||||
1. Deploy application to the cluster
|
|
||||||
```yaml
|
|
||||||
apiVersion: core.oam.dev/v1beta1
|
|
||||||
kind: Application
|
|
||||||
metadata:
|
|
||||||
name: test-rolling
|
|
||||||
spec:
|
|
||||||
components:
|
|
||||||
- name: metrics-provider
|
|
||||||
type: worker
|
|
||||||
properties:
|
|
||||||
cmd:
|
|
||||||
- ./podinfo
|
|
||||||
- stress-cpu=1.0
|
|
||||||
image: stefanprodan/podinfo:4.0.6
|
|
||||||
port: 8080
|
|
||||||
rolloutPlan:
|
|
||||||
rolloutStrategy: "IncreaseFirst"
|
|
||||||
rolloutBatches:
|
|
||||||
- replicas: 50%
|
|
||||||
- replicas: 50%
|
|
||||||
targetSize: 6
|
|
||||||
```
|
|
||||||
|
|
||||||
2. User can modify the application container command and apply
|
|
||||||
```yaml
|
|
||||||
apiVersion: core.oam.dev/v1beta1
|
|
||||||
kind: Application
|
|
||||||
metadata:
|
|
||||||
name: test-rolling
|
|
||||||
spec:
|
|
||||||
components:
|
|
||||||
- name: metrics-provider
|
|
||||||
type: worker
|
|
||||||
properties:
|
|
||||||
cmd:
|
|
||||||
- ./podinfo
|
|
||||||
- stress-cpu=2.0
|
|
||||||
image: stefanprodan/podinfo:4.0.6
|
|
||||||
port: 8080
|
|
||||||
rolloutPlan:
|
|
||||||
rolloutStrategy: "IncreaseFirst"
|
|
||||||
rolloutBatches:
|
|
||||||
- replicas: 50%
|
|
||||||
- replicas: 50%
|
|
||||||
targetSize: 6
|
|
||||||
```
|
|
||||||
|
|
||||||
User can check the status of the application and see the rollout completes, and the
|
|
||||||
application's `status.rollout.rollingState` becomes `rolloutSucceed`.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
@ -0,0 +1,5 @@
|
||||||
|
---
|
||||||
|
title: AutoScaler
|
||||||
|
---
|
||||||
|
|
||||||
|
TBD
|
||||||
|
|
@ -0,0 +1,5 @@
|
||||||
|
---
|
||||||
|
title: Manual Scaler
|
||||||
|
---
|
||||||
|
|
||||||
|
TBD
|
||||||
|
|
@ -6,7 +6,7 @@ Traits in KubeVela are designed as modularized building blocks, they are fully c
|
||||||
|
|
||||||
## 1. Get from capability canter
|
## 1. Get from capability canter
|
||||||
|
|
||||||
KubeVela allows you to explore capabilities maintained by platform team. There are two commands in kubectl vela
|
KubeVela allows you to explore capabilities maintained by platform-engineers. There are two commands in kubectl vela
|
||||||
plugin: `comp` and `trait`.
|
plugin: `comp` and `trait`.
|
||||||
|
|
||||||
In case you haven't installed kubectl vela plugin: see [this](../../developers/references/kubectl-plugin#install-kubectl-vela-plugin).
|
In case you haven't installed kubectl vela plugin: see [this](../../developers/references/kubectl-plugin#install-kubectl-vela-plugin).
|
||||||
|
|
@ -55,5 +55,7 @@ from [repo](https://registry.kubevela.net) maintained by KubeVela.
|
||||||
|
|
||||||
## 2. Designed by yourself
|
## 2. Designed by yourself
|
||||||
|
|
||||||
Check [this documentation](../../platform-engineers/cue/trait) about how to design and enable your own traits in
|
|
||||||
|
Check [this documentation](../../platform-engineers/traits/trait) about how to design and enable your own traits in
|
||||||
|
|
||||||
KubeVela platform.
|
KubeVela platform.
|
||||||
|
|
@ -0,0 +1,3 @@
|
||||||
|
---
|
||||||
|
title: 使用 Workflow 工作流
|
||||||
|
---
|
||||||
|
|
@ -0,0 +1,4 @@
|
||||||
|
---
|
||||||
|
title: Components Topology
|
||||||
|
---
|
||||||
|
|
||||||
|
|
@ -0,0 +1,5 @@
|
||||||
|
---
|
||||||
|
title: Multi-Enviroment
|
||||||
|
---
|
||||||
|
|
||||||
|
|
||||||
|
|
@ -0,0 +1,5 @@
|
||||||
|
---
|
||||||
|
title: First Application
|
||||||
|
---
|
||||||
|
|
||||||
|
TBD
|
||||||
|
|
@ -1,16 +1,15 @@
|
||||||
---
|
---
|
||||||
title: Introduction
|
title: Introduction
|
||||||
slug: /
|
slug: /
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
## Motivation
|
## Motivation
|
||||||
|
|
||||||
The trend of cloud-native technology is moving towards pursuing consistent application delivery across clouds and on-premises infrastructures using Kubernetes as the common layer. Kubernetes, although excellent in abstracting low-level infrastructure details, does not introduce abstractions to model software deployment on top of today's hybrid and distributed environments. We’ve seen the lack of application level context have impacted user experiences, slowed down productivity, led to unexpected errors or misconfigurations in production.
|
The trend of cloud-native technology is moving towards pursuing consistent application delivery across clouds and on-premises infrastructures using Kubernetes as the common layer. Kubernetes, although excellent in abstracting low-level infrastructure details, does not introduce abstractions to model software deployment on top of today's hybrid and distributed environments. We’ve seen the lack of application level context have impacted user experiences, slowed down productivity, led to unexpected errors or misconfigurations in production.
|
||||||
|
|
||||||
On the other hand, modeling the deployment and operation of microservice application across hybrid environments is a complicated and fragmented process. Many CD or PaaS systems today are either over complex or highly restrictive (which means your needs are almost certain to outgrow the capabilities of such systems today or tomorrow). Application teams complain those platforms are rigid and slow in response to features requests and improvements. Platform teams do want to help but the engineering effort to build such a cross-environments, flexible and consistent application delivery system seems daunting.
|
On the other hand, modeling the deployment and operation of microservice application across hybrid environments is a complicated and fragmented process. Many CD or PaaS systems today are either over complex or highly restrictive (which means your needs are almost certain to outgrow the capabilities of such systems today or tomorrow). End Users complain those platforms are rigid and slow in response to features requests and improvements. platform-engineerss do want to help but the engineering effort to build such a cross-environments, flexible and consistent application delivery system seems daunting.
|
||||||
|
|
||||||
## What is KubeVela?
|
## What is KubeVela?
|
||||||
|
|
||||||
|
|
@ -26,7 +25,7 @@ KubeVela is a modern application platform that makes deploying and managing appl
|
||||||
|
|
||||||
The overall architecture of KubeVela is shown as below:
|
The overall architecture of KubeVela is shown as below:
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
### Control Plane
|
### Control Plane
|
||||||
|
|
||||||
|
|
@ -70,12 +69,4 @@ Furthermore, KubeVela also supports other encapsulation formats including Kustom
|
||||||
|
|
||||||
KubeVela is a modern application deployment system built with cloud native stack. It leverages [Open Application Model](https://github.com/oam-dev/spec) and Kubernetes as control plane to resolve a hard problem - making shipping applications enjoyable.
|
KubeVela is a modern application deployment system built with cloud native stack. It leverages [Open Application Model](https://github.com/oam-dev/spec) and Kubernetes as control plane to resolve a hard problem - making shipping applications enjoyable.
|
||||||
|
|
||||||
## What's Next
|
|
||||||
|
|
||||||
Here are some recommended next steps:
|
|
||||||
- [Get started](./quick-start) with KubeVela.
|
|
||||||
- Learn KubeVela's [core concepts](./concepts).
|
|
||||||
- Learn how to [deploy an application](end-user/application) in detail and understand how it works.
|
|
||||||
- Join `#kubevela` channel in CNCF [Slack](https://cloud-native.slack.com) and/or [Gitter](https://gitter.im/oam-dev/community)
|
|
||||||
|
|
||||||
Welcome onboard and sail Vela!
|
Welcome onboard and sail Vela!
|
||||||
|
|
@ -5,7 +5,7 @@ title: Installation
|
||||||
import Tabs from '@theme/Tabs';
|
import Tabs from '@theme/Tabs';
|
||||||
import TabItem from '@theme/TabItem';
|
import TabItem from '@theme/TabItem';
|
||||||
|
|
||||||
> For upgrading existing KubeVela, please read the [upgrade guide](./advanced-install/#upgrade).
|
> For upgrading existing KubeVela, please read the [upgrade guide](../platform-engineers/advanced-install/#upgrade).
|
||||||
|
|
||||||
## 1. Choose Control Plane Cluster
|
## 1. Choose Control Plane Cluster
|
||||||
|
|
||||||
|
|
@ -95,7 +95,7 @@ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/mast
|
||||||
helm install --create-namespace -n vela-system kubevela kubevela/vela-core
|
helm install --create-namespace -n vela-system kubevela kubevela/vela-core
|
||||||
```
|
```
|
||||||
By default, it will enable the webhook with a self-signed certificate provided by [kube-webhook-certgen](https://github.com/jet/kube-webhook-certgen).
|
By default, it will enable the webhook with a self-signed certificate provided by [kube-webhook-certgen](https://github.com/jet/kube-webhook-certgen).
|
||||||
You can also [install it with `cert-manager`](./advanced-install#install-kubevela-with-cert-manager).
|
You can also [install it with `cert-manager`](../platform-engineers/advanced-install#install-kubevela-with-cert-manager).
|
||||||
|
|
||||||
4. Verify chart installed successfully
|
4. Verify chart installed successfully
|
||||||
```shell script
|
```shell script
|
||||||
|
|
@ -132,7 +132,7 @@ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/mast
|
||||||
|
|
||||||
KubeVela CLI gives you a simplified workflow to manage applications with optimized output. It is not mandatory though.
|
KubeVela CLI gives you a simplified workflow to manage applications with optimized output. It is not mandatory though.
|
||||||
|
|
||||||
KubeVela CLI could be [installed as kubectl plugin](./advanced-install#install-kubectl-vela-plugin), or install as standalone binary.
|
KubeVela CLI could be [installed as kubectl plugin](../platform-engineers/advanced-install#install-kubectl-vela-plugin), or install as standalone binary.
|
||||||
|
|
||||||
<Tabs
|
<Tabs
|
||||||
className="unique-tabs"
|
className="unique-tabs"
|
||||||
|
|
@ -223,4 +223,4 @@ These capabilities are built-in so they are ready to use if showed up. KubeVela
|
||||||
|
|
||||||
Also, whenever new capabilities are added in the platform, you will immediately see them in above output.
|
Also, whenever new capabilities are added in the platform, you will immediately see them in above output.
|
||||||
|
|
||||||
> See the [advanced installation guide](./advanced-install) to learn more about installation details.
|
> See the [advanced installation guide](../platform-engineers/advanced-install) to learn more about installation details.
|
||||||
|
|
@ -0,0 +1,75 @@
|
||||||
|
---
|
||||||
|
title: Install kubectl plugin
|
||||||
|
---
|
||||||
|
import Tabs from '@theme/Tabs';
|
||||||
|
import TabItem from '@theme/TabItem';
|
||||||
|
|
||||||
|
Install vela kubectl plugin can help you to ship applications more easily!
|
||||||
|
|
||||||
|
## Installation
|
||||||
|
|
||||||
|
You can install kubectl plugin `kubectl vela` by:
|
||||||
|
|
||||||
|
<Tabs
|
||||||
|
className="unique-tabs"
|
||||||
|
defaultValue="krew"
|
||||||
|
values={[
|
||||||
|
{label: 'Krew', value: 'krew'},
|
||||||
|
{label: 'Script', value: 'script'},
|
||||||
|
]}>
|
||||||
|
<TabItem value="krew">
|
||||||
|
|
||||||
|
1. [Install and set up](https://krew.sigs.k8s.io/docs/user-guide/setup/install/) Krew on your machine.
|
||||||
|
2. Discover plugins available on Krew:
|
||||||
|
```shell
|
||||||
|
kubectl krew update
|
||||||
|
```
|
||||||
|
3. install kubectl vela:
|
||||||
|
```shell script
|
||||||
|
kubectl krew install vela
|
||||||
|
```
|
||||||
|
|
||||||
|
</TabItem>
|
||||||
|
<TabItem value="script">
|
||||||
|
|
||||||
|
**macOS/Linux**
|
||||||
|
```shell script
|
||||||
|
curl -fsSl https://kubevela.io/script/install-kubectl-vela.sh | bash
|
||||||
|
```
|
||||||
|
|
||||||
|
You can also download the binary from [release pages ( >= v1.0.3)](https://github.com/oam-dev/kubevela/releases) manually.
|
||||||
|
Kubectl will discover it from your system path automatically.
|
||||||
|
|
||||||
|
</TabItem>
|
||||||
|
</Tabs>
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
|
||||||
|
```shell
|
||||||
|
$ kubectl vela -h
|
||||||
|
A Highly Extensible Platform Engine based on Kubernetes and Open Application Model.
|
||||||
|
|
||||||
|
Usage:
|
||||||
|
kubectl vela [flags]
|
||||||
|
kubectl vela [command]
|
||||||
|
|
||||||
|
Available Commands:
|
||||||
|
|
||||||
|
Flags:
|
||||||
|
-h, --help help for vela
|
||||||
|
|
||||||
|
dry-run Dry Run an application, and output the K8s resources as
|
||||||
|
result to stdout, only CUE template supported for now
|
||||||
|
live-diff Dry-run an application, and do diff on a specific app
|
||||||
|
revison. The provided capability definitions will be used
|
||||||
|
during Dry-run. If any capabilities used in the app are not
|
||||||
|
found in the provided ones, it will try to find from
|
||||||
|
cluster.
|
||||||
|
show Show the reference doc for a workload type or trait
|
||||||
|
version Prints out build version information
|
||||||
|
|
||||||
|
|
||||||
|
Use "kubectl vela [command] --help" for more information about a command.
|
||||||
|
```
|
||||||
|
|
@ -86,7 +86,7 @@ Kubectl will discover it from your system path automatically.
|
||||||
</TabItem>
|
</TabItem>
|
||||||
</Tabs>
|
</Tabs>
|
||||||
|
|
||||||
For more usage please reference [kubectl plugin](./developers/references/kubectl-plugin).
|
For more usage please reference [kubectl plugin](../developers/references/kubectl-plugin).
|
||||||
## Upgrade
|
## Upgrade
|
||||||
|
|
||||||
### Step 1. Update Helm repo
|
### Step 1. Update Helm repo
|
||||||
|
|
@ -12,7 +12,7 @@ In KubeVela, the needed cloud services are claimed as *components* in an applica
|
||||||
|
|
||||||
KubeVela relies on [Terraform Controller](https://github.com/oam-dev/terraform-controller) or [Crossplane](http://crossplane.io/) as providers to talk to the clouds. Please check the documentations below for detailed steps.
|
KubeVela relies on [Terraform Controller](https://github.com/oam-dev/terraform-controller) or [Crossplane](http://crossplane.io/) as providers to talk to the clouds. Please check the documentations below for detailed steps.
|
||||||
|
|
||||||
- [Terraform](./terraform)
|
- [Terraform](./components/component-terraform)
|
||||||
- [Crossplane](./crossplane)
|
- [Crossplane](./crossplane)
|
||||||
|
|
||||||
## Can a Instance of Cloud Services be Shared by Multiple Applications?
|
## Can a Instance of Cloud Services be Shared by Multiple Applications?
|
||||||
|
|
|
||||||
|
|
@ -371,4 +371,4 @@ hello-world-trait-7bdcff98f7 ClusterIP <your ip> <none> 8000/TC
|
||||||
|
|
||||||
## What's Next
|
## What's Next
|
||||||
|
|
||||||
Please check the [Learning CUE](./basic) documentation about why we support CUE as first-class templating solution and more details about using CUE efficiently.
|
Please check the [Learning CUE](../cue/basic) documentation about why we support CUE as first-class templating solution and more details about using CUE efficiently.
|
||||||
|
|
@ -0,0 +1,4 @@
|
||||||
|
---
|
||||||
|
title: Component Defualt
|
||||||
|
---
|
||||||
|
|
||||||
|
|
@ -1,16 +1,16 @@
|
||||||
---
|
---
|
||||||
title: Terraform
|
title: Component Terraform
|
||||||
---
|
---
|
||||||
|
|
||||||
在本文档中，我们将使用阿里云的 RDS（关系数据库服务）和阿里云的 OSS（对象存储系统）作为示例，展示如何在应用程序部署中启用云服务。
|
In this documentation, we will use Alibaba Cloud's RDS (Relational Database Service), and Alibaba Cloud's OSS (Object Storage System) as examples to show how to enable cloud services as part of the application deployment.
|
||||||
|
|
||||||
这些云服务由 Terraform 提供。
|
These cloud services are provided by Terraform.
|
||||||
|
|
||||||
## 准备 Terraform 控制器
|
## Prepare Terraform Controller
|
||||||
|
|
||||||
<details>
|
<details>
|
||||||
|
|
||||||
从最新的 [发布列表](https://github.com/oam-dev/terraform-controller/releases) 下载最新的图表，如 `terraform-controller-chart-0.1.8.tgz` 并安装它。
|
Download the latest chart, like `terraform-controller-chart-0.1.8.tgz`, from the latest [releases list](https://github.com/oam-dev/terraform-controller/releases) and install it.
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
$ helm install terraform-controller terraform-controller-0.1.8.tgz
|
$ helm install terraform-controller terraform-controller-0.1.8.tgz
|
||||||
|
|
@ -22,17 +22,17 @@ REVISION: 1
|
||||||
TEST SUITE: None
|
TEST SUITE: None
|
||||||
```
|
```
|
||||||
|
|
||||||
### 应用提供商凭据
|
### Apply Provider Credentials
|
||||||
|
|
||||||
通过应用 Terraform Provider 凭据，可以对 Terraform 控制器进行身份验证以部署和管理云资源。
|
By applying Terraform Provider credentials, Terraform controller can be authenticated to deploy and manage cloud resources.
|
||||||
|
|
||||||
如何申请阿里云或 AWS 的 Provider 请参考[Terraform控制器入门](https://github.com/oam-dev/terraform-controller/blob/master/getting-started.md)。
|
Please refer to [Terraform controller getting started](https://github.com/oam-dev/terraform-controller/blob/master/getting-started.md) on how to apply Provider for Alibaba Cloud or AWS.
|
||||||
|
|
||||||
</details>
|
</details>
|
||||||
|
|
||||||
### 注册`alibaba-rds`组件
|
### Register `alibaba-rds` Component
|
||||||
|
|
||||||
注册 [alibaba-rds](https://github.com/oam-dev/kubevela/tree/master/docs/examples/terraform/cloud-resource-provision-and-consume/ComponentDefinition-alibaba-rds.yaml) 到 KubeVela。
|
Register [alibaba-rds](https://github.com/oam-dev/kubevela/tree/master/docs/examples/terraform/cloud-resource-provision-and-consume/ComponentDefinition-alibaba-rds.yaml) to KubeVela.
|
||||||
|
|
||||||
```yaml
|
```yaml
|
||||||
apiVersion: core.oam.dev/v1alpha2
|
apiVersion: core.oam.dev/v1alpha2
|
||||||
|
|
@ -97,9 +97,10 @@ spec:
|
||||||
|
|
||||||
```
|
```
|
||||||
|
|
||||||
### 注册`alibaba-oss`组件
|
### Register `alibaba-oss` Component
|
||||||
|
|
||||||
|
Register [alibaba-oss](https://github.com/oam-dev/kubevela/tree/master/docs/examples/terraform/cloud-resource-provision-and-consume/ComponentDefinition-alibaba-oss.yaml) to KubeVela.
|
||||||
|
|
||||||
注册 [alibaba-oss](https://github.com/oam-dev/kubevela/tree/master/docs/examples/terraform/cloud-resource-provision-and-consume/ComponentDefinition-alibaba-oss.yaml) 到 KubeVela。
|
|
||||||
|
|
||||||
```yaml
|
```yaml
|
||||||
apiVersion: core.oam.dev/v1alpha2
|
apiVersion: core.oam.dev/v1alpha2
|
||||||
|
|
@ -1,245 +1,6 @@
|
||||||
---
|
---
|
||||||
title: Advanced Features
|
title: 开发与调试
|
||||||
---
|
---
|
||||||
|
|
||||||
As a Data Configuration Language, CUE allows you to do some advanced templating magic in definition objects.
|
|
||||||
|
|
||||||
## Render Multiple Resources With a Loop
|
TBD
|
||||||
|
|
||||||
You can define the for-loop inside the `outputs`.
|
|
||||||
|
|
||||||
> Note that in this case the type of `parameter` field used in the for-loop must be a map.
|
|
||||||
|
|
||||||
Below is an example that will render multiple Kubernetes Services in one trait:
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
apiVersion: core.oam.dev/v1beta1
|
|
||||||
kind: TraitDefinition
|
|
||||||
metadata:
|
|
||||||
name: expose
|
|
||||||
spec:
|
|
||||||
schematic:
|
|
||||||
cue:
|
|
||||||
template: |
|
|
||||||
parameter: {
|
|
||||||
http: [string]: int
|
|
||||||
}
|
|
||||||
|
|
||||||
outputs: {
|
|
||||||
for k, v in parameter.http {
|
|
||||||
"\(k)": {
|
|
||||||
apiVersion: "v1"
|
|
||||||
kind: "Service"
|
|
||||||
spec: {
|
|
||||||
selector:
|
|
||||||
app: context.name
|
|
||||||
ports: [{
|
|
||||||
port: v
|
|
||||||
targetPort: v
|
|
||||||
}]
|
|
||||||
}
|
|
||||||
}
|
|
||||||
}
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
The usage of this trait could be:
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
apiVersion: core.oam.dev/v1beta1
|
|
||||||
kind: Application
|
|
||||||
metadata:
|
|
||||||
name: testapp
|
|
||||||
spec:
|
|
||||||
components:
|
|
||||||
- name: express-server
|
|
||||||
type: webservice
|
|
||||||
properties:
|
|
||||||
...
|
|
||||||
traits:
|
|
||||||
- type: expose
|
|
||||||
properties:
|
|
||||||
http:
|
|
||||||
myservice1: 8080
|
|
||||||
myservice2: 8081
|
|
||||||
```
|
|
||||||
|
|
||||||
## Execute HTTP Request in Trait Definition
|
|
||||||
|
|
||||||
The trait definition can send a HTTP request and capture the response to help you rendering the resource with keyword `processing`.
|
|
||||||
|
|
||||||
You can define HTTP request `method`, `url`, `body`, `header` and `trailer` in the `processing.http` section, and the returned data will be stored in `processing.output`.
|
|
||||||
|
|
||||||
> Please ensure the target HTTP server returns a **JSON data**. `output`.
|
|
||||||
|
|
||||||
Then you can reference the returned data from `processing.output` in `patch` or `output/outputs`.
|
|
||||||
|
|
||||||
Below is an example:
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
apiVersion: core.oam.dev/v1beta1
|
|
||||||
kind: TraitDefinition
|
|
||||||
metadata:
|
|
||||||
name: auth-service
|
|
||||||
spec:
|
|
||||||
schematic:
|
|
||||||
cue:
|
|
||||||
template: |
|
|
||||||
parameter: {
|
|
||||||
serviceURL: string
|
|
||||||
}
|
|
||||||
|
|
||||||
processing: {
|
|
||||||
output: {
|
|
||||||
token?: string
|
|
||||||
}
|
|
||||||
// The target server will return a JSON data with `token` as key.
|
|
||||||
http: {
|
|
||||||
method: *"GET" | string
|
|
||||||
url: parameter.serviceURL
|
|
||||||
request: {
|
|
||||||
body?: bytes
|
|
||||||
header: {}
|
|
||||||
trailer: {}
|
|
||||||
}
|
|
||||||
}
|
|
||||||
}
|
|
||||||
|
|
||||||
patch: {
|
|
||||||
data: token: processing.output.token
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
In above example, this trait definition will send request to get the `token` data, and then patch the data to given component instance.
|
|
||||||
|
|
||||||
## Data Passing
|
|
||||||
|
|
||||||
A trait definition can read the generated API resources (rendered from `output` and `outputs`) of given component definition.
|
|
||||||
|
|
||||||
> KubeVela will ensure the component definitions are always rendered before traits definitions.
|
|
||||||
|
|
||||||
Specifically, the `context.output` contains the rendered workload API resource (whose GVK is indicated by `spec.workload`in component definition), and use `context.outputs.<xx>` to contain all the other rendered API resources.
|
|
||||||
|
|
||||||
Below is an example for data passing:
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
apiVersion: core.oam.dev/v1beta1
|
|
||||||
kind: ComponentDefinition
|
|
||||||
metadata:
|
|
||||||
name: worker
|
|
||||||
spec:
|
|
||||||
workload:
|
|
||||||
definition:
|
|
||||||
apiVersion: apps/v1
|
|
||||||
kind: Deployment
|
|
||||||
schematic:
|
|
||||||
cue:
|
|
||||||
template: |
|
|
||||||
output: {
|
|
||||||
apiVersion: "apps/v1"
|
|
||||||
kind: "Deployment"
|
|
||||||
spec: {
|
|
||||||
selector: matchLabels: {
|
|
||||||
"app.oam.dev/component": context.name
|
|
||||||
}
|
|
||||||
|
|
||||||
template: {
|
|
||||||
metadata: labels: {
|
|
||||||
"app.oam.dev/component": context.name
|
|
||||||
}
|
|
||||||
spec: {
|
|
||||||
containers: [{
|
|
||||||
name: context.name
|
|
||||||
image: parameter.image
|
|
||||||
ports: [{containerPort: parameter.port}]
|
|
||||||
envFrom: [{
|
|
||||||
configMapRef: name: context.name + "game-config"
|
|
||||||
}]
|
|
||||||
if parameter["cmd"] != _|_ {
|
|
||||||
command: parameter.cmd
|
|
||||||
}
|
|
||||||
}]
|
|
||||||
}
|
|
||||||
}
|
|
||||||
}
|
|
||||||
}
|
|
||||||
|
|
||||||
outputs: gameconfig: {
|
|
||||||
apiVersion: "v1"
|
|
||||||
kind: "ConfigMap"
|
|
||||||
metadata: {
|
|
||||||
name: context.name + "game-config"
|
|
||||||
}
|
|
||||||
data: {
|
|
||||||
enemies: parameter.enemies
|
|
||||||
lives: parameter.lives
|
|
||||||
}
|
|
||||||
}
|
|
||||||
|
|
||||||
parameter: {
|
|
||||||
// +usage=Which image would you like to use for your service
|
|
||||||
// +short=i
|
|
||||||
image: string
|
|
||||||
// +usage=Commands to run in the container
|
|
||||||
cmd?: [...string]
|
|
||||||
lives: string
|
|
||||||
enemies: string
|
|
||||||
port: int
|
|
||||||
}
|
|
||||||
|
|
||||||
|
|
||||||
---
|
|
||||||
apiVersion: core.oam.dev/v1beta1
|
|
||||||
kind: TraitDefinition
|
|
||||||
metadata:
|
|
||||||
name: ingress
|
|
||||||
spec:
|
|
||||||
schematic:
|
|
||||||
cue:
|
|
||||||
template: |
|
|
||||||
parameter: {
|
|
||||||
domain: string
|
|
||||||
path: string
|
|
||||||
exposePort: int
|
|
||||||
}
|
|
||||||
// trait template can have multiple outputs in one trait
|
|
||||||
outputs: service: {
|
|
||||||
apiVersion: "v1"
|
|
||||||
kind: "Service"
|
|
||||||
spec: {
|
|
||||||
selector:
|
|
||||||
app: context.name
|
|
||||||
ports: [{
|
|
||||||
port: parameter.exposePort
|
|
||||||
targetPort: context.output.spec.template.spec.containers[0].ports[0].containerPort
|
|
||||||
}]
|
|
||||||
}
|
|
||||||
}
|
|
||||||
outputs: ingress: {
|
|
||||||
apiVersion: "networking.k8s.io/v1beta1"
|
|
||||||
kind: "Ingress"
|
|
||||||
metadata:
|
|
||||||
name: context.name
|
|
||||||
labels: config: context.outputs.gameconfig.data.enemies
|
|
||||||
spec: {
|
|
||||||
rules: [{
|
|
||||||
host: parameter.domain
|
|
||||||
http: {
|
|
||||||
paths: [{
|
|
||||||
path: parameter.path
|
|
||||||
backend: {
|
|
||||||
serviceName: context.name
|
|
||||||
servicePort: parameter.exposePort
|
|
||||||
}
|
|
||||||
}]
|
|
||||||
}
|
|
||||||
}]
|
|
||||||
}
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
In detail, during rendering `worker` `ComponentDefinition`:
|
|
||||||
1. the rendered Kubernetes Deployment resource will be stored in the `context.output`,
|
|
||||||
2. all other rendered resources will be stored in `context.outputs.<xx>`, with `<xx>` is the unique name in every `template.outputs`.
|
|
||||||
|
|
||||||
Thus, in `TraitDefinition`, it can read the rendered API resources (e.g. `context.outputs.gameconfig.data.enemies`) from the `context`.
|
|
||||||
|
|
@ -22,7 +22,7 @@ The reasons for KubeVela supports CUE as a first-class solution to design abstra
|
||||||
|
|
||||||
Please make sure below CLIs are present in your environment:
|
Please make sure below CLIs are present in your environment:
|
||||||
* [`cue` >=v0.2.2](https://cuelang.org/docs/install/)
|
* [`cue` >=v0.2.2](https://cuelang.org/docs/install/)
|
||||||
* [`vela` (>v1.0.0)](../../install#3-get-kubevela-cli)
|
* [`vela` (>v1.0.0)](../../getting-started/quick-install#3-get-kubevela-cli)
|
||||||
|
|
||||||
## CUE CLI Basic
|
## CUE CLI Basic
|
||||||
|
|
||||||
|
|
|
||||||
File diff suppressed because it is too large
Load Diff
|
|
@ -8,7 +8,7 @@ In this section, it will introduce how to declare Helm charts as components via
|
||||||
|
|
||||||
## Prerequisite
|
## Prerequisite
|
||||||
|
|
||||||
* Make sure you have enabled Helm support in the [installation guide](../../install#4-enable-helm-support).
|
* Make sure you have enabled Helm support in the [installation guide](../../getting-started/quick-install#4-enable-helm-support).
|
||||||
|
|
||||||
## Declare `ComponentDefinition`
|
## Declare `ComponentDefinition`
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,3 @@
|
||||||
|
---
|
||||||
|
title: 平台环境初始化
|
||||||
|
---
|
||||||
|
|
@ -0,0 +1,5 @@
|
||||||
|
---
|
||||||
|
title: 自定义交付环境
|
||||||
|
---
|
||||||
|
|
||||||
|
TBD
|
||||||
|
|
@ -1,14 +1,14 @@
|
||||||
---
|
---
|
||||||
title: Resource Model
|
title: 交付环境原理
|
||||||
---
|
---
|
||||||
|
|
||||||
This documentation will explain the core resource model of KubeVela which is fully powered by Open Application Model (OAM).
|
This documentation will explain the core resource model of KubeVela which is fully powered by Open Application Model (OAM).
|
||||||
|
|
||||||
## Application
|
## Application
|
||||||
|
|
||||||
The *Application* is the core API of KubeVela. It allows application team to work with a single artifact to capture the complete application deployment with simplified primitives.
|
The *Application* is the core API of KubeVela. It allows End User to work with a single artifact to capture the complete application deployment with simplified primitives.
|
||||||
|
|
||||||
This provides a simpler path for on-boarding application team to the platform without leaking low level details in runtime infrastructure. For example, they will be able to declare a "web service" without defining a detailed Kubernetes Deployment + Service combo each time, or claim the auto-scaling requirements without referring to the underlying KEDA ScaleObject. They can also declare a cloud database with same API if they want.
|
This provides a simpler path for on-boarding End User to the platform without leaking low level details in runtime infrastructure. For example, they will be able to declare a "web service" without defining a detailed Kubernetes Deployment + Service combo each time, or claim the auto-scaling requirements without referring to the underlying KEDA ScaleObject. They can also declare a cloud database with same API if they want.
|
||||||
|
|
||||||
Every application is composed by multiple components with attachable operational behaviors (traits). For example:
|
Every application is composed by multiple components with attachable operational behaviors (traits). For example:
|
||||||
|
|
||||||
|
|
@ -39,18 +39,18 @@ spec:
|
||||||
bucket: "my-bucket"
|
bucket: "my-bucket"
|
||||||
```
|
```
|
||||||
|
|
||||||
The `Application` resource in KubeVela is a LEGO-style entity and does not even have fixed schema. Instead, it is assembled by below building block entities that are maintained by the platform team.
|
The `Application` resource in KubeVela is a LEGO-style entity and does not even have fixed schema. Instead, it is assembled by below building block entities that are maintained by the platform-engineers.
|
||||||
Though the application object doesn't have fixed schema, it is a composition object assembled by several *programmable building blocks* as shown below.
|
Though the application object doesn't have fixed schema, it is a composition object assembled by several *programmable building blocks* as shown below.
|
||||||
|
|
||||||
## Component
|
## Component
|
||||||
|
|
||||||
The component model (`ComponentDefinition` API) is designed to allow *component providers* to encapsulate deployable/provisionable entities with a wide range of tools, and hence give a easier path to application team to deploy complicated microservices across hybrid environments at ease. A component normally carries its workload type description (i.e. `WorkloadDefinition`), a encapsulation module with a parameter list.
|
The component model (`ComponentDefinition` API) is designed to allow *component providers* to encapsulate deployable/provisionable entities with a wide range of tools, and hence give a easier path to End User to deploy complicated microservices across hybrid environments at ease. A component normally carries its workload type description (i.e. `WorkloadDefinition`), a encapsulation module with a parameter list.
|
||||||
|
|
||||||
> Hence, a components provider could be anyone who packages software components in form of Helm chart of CUE modules. Think about 3rd-party software distributor, DevOps team, or even your CI pipeline.
|
> Hence, a components provider could be anyone who packages software components in form of Helm chart of CUE modules. Think about 3rd-party software distributor, DevOps team, or even your CI pipeline.
|
||||||
|
|
||||||
Components are shareable and reusable. For example, by referencing the same *Alibaba Cloud RDS* component and setting different parameter values, application team could easily provision Alibaba Cloud RDS instances of different sizes in different availability zones.
|
Components are shareable and reusable. For example, by referencing the same *Alibaba Cloud RDS* component and setting different parameter values, End User could easily provision Alibaba Cloud RDS instances of different sizes in different availability zones.
|
||||||
|
|
||||||
Application team will use the `Application` entity to declare how they want to instantiate and deploy a group of certain components. In above example, it describes an application composed with Kubernetes stateless workload (component `foo`) and a Alibaba Cloud OSS bucket (component `bar`) alongside.
|
End User will use the `Application` entity to declare how they want to instantiate and deploy a group of certain components. In above example, it describes an application composed with Kubernetes stateless workload (component `foo`) and a Alibaba Cloud OSS bucket (component `bar`) alongside.
|
||||||
|
|
||||||
### How it Works?
|
### How it Works?
|
||||||
|
|
||||||
|
|
@ -182,7 +182,7 @@ spec:
|
||||||
}
|
}
|
||||||
```
|
```
|
||||||
|
|
||||||
Please note that the application team do NOT need to know about definition objects, they learn how to use a given capability with visualized forms (or the JSON schema of parameters if they prefer). Please check the [Generate Forms from Definitions](openapi-v3-json-schema) section about how this is achieved.
|
Please note that the End User do NOT need to know about definition objects, they learn how to use a given capability with visualized forms (or the JSON schema of parameters if they prefer). Please check the [Generate Forms from Definitions](../openapi-v3-json-schema) section about how this is achieved.
|
||||||
|
|
||||||
## Standard Contract Behind The Abstractions
|
## Standard Contract Behind The Abstractions
|
||||||
|
|
||||||
|
|
@ -2,7 +2,7 @@
|
||||||
title: KEDA as Autoscaling Trait
|
title: KEDA as Autoscaling Trait
|
||||||
---
|
---
|
||||||
|
|
||||||
> Before continue, make sure you have learned about the concepts of [Definition Objects](definition-and-templates) and [Defining Traits with CUE](cue/trait) section.
|
> Before continue, make sure you have learned about the concepts of [Definition Objects](definition-and-templates) and [Defining Traits with CUE](./traits/trait) section.
|
||||||
|
|
||||||
In the following tutorial, you will learn to add [KEDA](https://keda.sh/) as a new autoscaling trait to your KubeVela based platform.
|
In the following tutorial, you will learn to add [KEDA](https://keda.sh/) as a new autoscaling trait to your KubeVela based platform.
|
||||||
|
|
||||||
|
|
@ -98,7 +98,7 @@ schematic:
|
||||||
|
|
||||||
This is a CUE based template which only exposes `type` and `value` as trait properties for user to set.
|
This is a CUE based template which only exposes `type` and `value` as trait properties for user to set.
|
||||||
|
|
||||||
> Please check the [Defining Trait with CUE](cue/trait) section for more details regarding to CUE templating.
|
<!-- > Please check the [Defining Trait with CUE](traits/trait) section for more details regarding to CUE templating. -->
|
||||||
|
|
||||||
## Step 2: Register New Trait to KubeVela
|
## Step 2: Register New Trait to KubeVela
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,207 @@
|
||||||
|
---
|
||||||
|
title: OAM Model
|
||||||
|
---
|
||||||
|
|
||||||
|
This documentation will explain the core resource model of KubeVela which is fully powered by Open Application Model (OAM).
|
||||||
|
|
||||||
|
## Application
|
||||||
|
|
||||||
|
The *Application* is the core API of KubeVela. It allows End User to work with a single artifact to capture the complete application deployment with simplified primitives.
|
||||||
|
|
||||||
|
This provides a simpler path for on-boarding End User to the platform without leaking low level details in runtime infrastructure. For example, they will be able to declare a "web service" without defining a detailed Kubernetes Deployment + Service combo each time, or claim the auto-scaling requirements without referring to the underlying KEDA ScaleObject. They can also declare a cloud database with same API if they want.
|
||||||
|
|
||||||
|
Every application is composed by multiple components with attachable operational behaviors (traits). For example:
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
apiVersion: core.oam.dev/v1beta1
|
||||||
|
kind: Application
|
||||||
|
metadata:
|
||||||
|
name: application-sample
|
||||||
|
spec:
|
||||||
|
components:
|
||||||
|
- name: foo
|
||||||
|
type: webservice
|
||||||
|
properties:
|
||||||
|
image: crccheck/hello-world
|
||||||
|
port: 8000
|
||||||
|
traits:
|
||||||
|
- type: ingress
|
||||||
|
properties:
|
||||||
|
domain: testsvc.example.com
|
||||||
|
http:
|
||||||
|
"/": 8000
|
||||||
|
- type: sidecar
|
||||||
|
properties:
|
||||||
|
name: "logging"
|
||||||
|
image: "fluentd"
|
||||||
|
- name: bar
|
||||||
|
type: aliyun-oss # cloud service
|
||||||
|
bucket: "my-bucket"
|
||||||
|
```
|
||||||
|
|
||||||
|
The `Application` resource in KubeVela is a LEGO-style entity and does not even have fixed schema. Instead, it is assembled by below building block entities that are maintained by the platform-engineers.
|
||||||
|
Though the application object doesn't have fixed schema, it is a composition object assembled by several *programmable building blocks* as shown below.
|
||||||
|
|
||||||
|
## Component
|
||||||
|
|
||||||
|
The component model (`ComponentDefinition` API) is designed to allow *component providers* to encapsulate deployable/provisionable entities with a wide range of tools, and hence give a easier path to End User to deploy complicated microservices across hybrid environments at ease. A component normally carries its workload type description (i.e. `WorkloadDefinition`), a encapsulation module with a parameter list.
|
||||||
|
|
||||||
|
> Hence, a components provider could be anyone who packages software components in form of Helm chart of CUE modules. Think about 3rd-party software distributor, DevOps team, or even your CI pipeline.
|
||||||
|
|
||||||
|
Components are shareable and reusable. For example, by referencing the same *Alibaba Cloud RDS* component and setting different parameter values, End User could easily provision Alibaba Cloud RDS instances of different sizes in different availability zones.
|
||||||
|
|
||||||
|
End User will use the `Application` entity to declare how they want to instantiate and deploy a group of certain components. In above example, it describes an application composed with Kubernetes stateless workload (component `foo`) and a Alibaba Cloud OSS bucket (component `bar`) alongside.
|
||||||
|
|
||||||
|
### How it Works?
|
||||||
|
|
||||||
|
In above example, `type: worker` means the specification of this component (claimed in following `properties` section) will be enforced by a `ComponentDefinition` object named `worker` as below:
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
apiVersion: core.oam.dev/v1beta1
|
||||||
|
kind: ComponentDefinition
|
||||||
|
metadata:
|
||||||
|
name: worker
|
||||||
|
annotations:
|
||||||
|
definition.oam.dev/description: "Describes long-running, scalable, containerized services that running at backend. They do NOT have network endpoint to receive external network traffic."
|
||||||
|
spec:
|
||||||
|
workload:
|
||||||
|
definition:
|
||||||
|
apiVersion: apps/v1
|
||||||
|
kind: Deployment
|
||||||
|
schematic:
|
||||||
|
cue:
|
||||||
|
template: |
|
||||||
|
output: {
|
||||||
|
apiVersion: "apps/v1"
|
||||||
|
kind: "Deployment"
|
||||||
|
spec: {
|
||||||
|
selector: matchLabels: {
|
||||||
|
"app.oam.dev/component": context.name
|
||||||
|
}
|
||||||
|
template: {
|
||||||
|
metadata: labels: {
|
||||||
|
"app.oam.dev/component": context.name
|
||||||
|
}
|
||||||
|
spec: {
|
||||||
|
containers: [{
|
||||||
|
name: context.name
|
||||||
|
image: parameter.image
|
||||||
|
|
||||||
|
if parameter["cmd"] != _|_ {
|
||||||
|
command: parameter.cmd
|
||||||
|
}
|
||||||
|
}]
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
parameter: {
|
||||||
|
image: string
|
||||||
|
cmd?: [...string]
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
|
||||||
|
Hence, the `properties` section of `backend` only exposes two parameters to fill: `image` and `cmd`, this is enforced by the `parameter` list of the `.spec.template` field of the definition.
|
||||||
|
|
||||||
|
## Traits
|
||||||
|
|
||||||
|
Traits (`TraitDefinition` API) are operational features provided by the platform. A trait augments the component instance with operational behaviors such as load balancing policy, network ingress routing, auto-scaling policies, or upgrade strategies, etc.
|
||||||
|
|
||||||
|
To attach a trait to component instance, the user will declare `.type` field to reference the specific `TraitDefinition`, and `.properties` field to set property values of the given trait. Similarly, `TraitDefinition` also allows you to define *template* for operational features.
|
||||||
|
|
||||||
|
In the above example, `type: autoscaler` in `frontend` means the specification (i.e. `properties` section) of this trait will be enforced by a `TraitDefinition` object named `autoscaler` as below:
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
apiVersion: core.oam.dev/v1beta1
|
||||||
|
kind: TraitDefinition
|
||||||
|
metadata:
|
||||||
|
annotations:
|
||||||
|
definition.oam.dev/description: "configure k8s HPA for Deployment"
|
||||||
|
name: hpa
|
||||||
|
spec:
|
||||||
|
appliesToWorkloads:
|
||||||
|
- deployments.apps
|
||||||
|
schematic:
|
||||||
|
cue:
|
||||||
|
template: |
|
||||||
|
outputs: hpa: {
|
||||||
|
apiVersion: "autoscaling/v2beta2"
|
||||||
|
kind: "HorizontalPodAutoscaler"
|
||||||
|
metadata: name: context.name
|
||||||
|
spec: {
|
||||||
|
scaleTargetRef: {
|
||||||
|
apiVersion: "apps/v1"
|
||||||
|
kind: "Deployment"
|
||||||
|
name: context.name
|
||||||
|
}
|
||||||
|
minReplicas: parameter.min
|
||||||
|
maxReplicas: parameter.max
|
||||||
|
metrics: [{
|
||||||
|
type: "Resource"
|
||||||
|
resource: {
|
||||||
|
name: "cpu"
|
||||||
|
target: {
|
||||||
|
type: "Utilization"
|
||||||
|
averageUtilization: parameter.cpuUtil
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}]
|
||||||
|
}
|
||||||
|
}
|
||||||
|
parameter: {
|
||||||
|
min: *1 | int
|
||||||
|
max: *10 | int
|
||||||
|
cpuUtil: *50 | int
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
The application also have a `sidecar` trait.
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
apiVersion: core.oam.dev/v1beta1
|
||||||
|
kind: TraitDefinition
|
||||||
|
metadata:
|
||||||
|
annotations:
|
||||||
|
definition.oam.dev/description: "add sidecar to the app"
|
||||||
|
name: sidecar
|
||||||
|
spec:
|
||||||
|
appliesToWorkloads:
|
||||||
|
- deployments.apps
|
||||||
|
schematic:
|
||||||
|
cue:
|
||||||
|
template: |-
|
||||||
|
patch: {
|
||||||
|
// +patchKey=name
|
||||||
|
spec: template: spec: containers: [parameter]
|
||||||
|
}
|
||||||
|
parameter: {
|
||||||
|
name: string
|
||||||
|
image: string
|
||||||
|
command?: [...string]
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
Please note that the End User do NOT need to know about definition objects, they learn how to use a given capability with visualized forms (or the JSON schema of parameters if they prefer). Please check the [Generate Forms from Definitions](../openapi-v3-json-schema) section about how this is achieved.
|
||||||
|
|
||||||
|
## Standard Contract Behind The Abstractions
|
||||||
|
|
||||||
|
Once the application is deployed, KubeVela will index and manage the underlying instances with name, revisions, labels and selector etc in automatic approach. These metadata are shown as below.
|
||||||
|
|
||||||
|
| Label | Description |
|
||||||
|
| :--: | :---------: |
|
||||||
|
|`workload.oam.dev/type=<component definition name>` | The name of its corresponding `ComponentDefinition` |
|
||||||
|
|`trait.oam.dev/type=<trait definition name>` | The name of its corresponding `TraitDefinition` |
|
||||||
|
|`app.oam.dev/name=<app name>` | The name of the application it belongs to |
|
||||||
|
|`app.oam.dev/component=<component name>` | The name of the component it belongs to |
|
||||||
|
|`trait.oam.dev/resource=<name of trait resource instance>` | The name of trait resource instance |
|
||||||
|
|`app.oam.dev/appRevision=<name of app revision>` | The name of the application revision it belongs to |
|
||||||
|
|
||||||
|
|
||||||
|
Consider these metadata as a standard contract for any "day 2" operation controller such as rollout controller to work on KubeVela deployed applications. This is the key to ensure the interoperability for KubeVela based platform as well.
|
||||||
|
|
||||||
|
## No Configuration Drift
|
||||||
|
|
||||||
|
Despite the efficiency and extensibility in abstracting application deployment, IaC (Infrastructure-as-Code) tools may lead to an issue called *Infrastructure/Configuration Drift*, i.e. the generated 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.
|
||||||
|
|
@ -0,0 +1,5 @@
|
||||||
|
---
|
||||||
|
title: X-Definition
|
||||||
|
---
|
||||||
|
|
||||||
|
TBD
|
||||||
|
|
@ -0,0 +1,245 @@
|
||||||
|
---
|
||||||
|
title: Advanced Features
|
||||||
|
---
|
||||||
|
|
||||||
|
As a Data Configuration Language, CUE allows you to do some advanced templating magic in definition objects.
|
||||||
|
|
||||||
|
## Render Multiple Resources With a Loop
|
||||||
|
|
||||||
|
You can define the for-loop inside the `outputs`.
|
||||||
|
|
||||||
|
> Note that in this case the type of `parameter` field used in the for-loop must be a map.
|
||||||
|
|
||||||
|
Below is an example that will render multiple Kubernetes Services in one trait:
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
apiVersion: core.oam.dev/v1beta1
|
||||||
|
kind: TraitDefinition
|
||||||
|
metadata:
|
||||||
|
name: expose
|
||||||
|
spec:
|
||||||
|
schematic:
|
||||||
|
cue:
|
||||||
|
template: |
|
||||||
|
parameter: {
|
||||||
|
http: [string]: int
|
||||||
|
}
|
||||||
|
|
||||||
|
outputs: {
|
||||||
|
for k, v in parameter.http {
|
||||||
|
"\(k)": {
|
||||||
|
apiVersion: "v1"
|
||||||
|
kind: "Service"
|
||||||
|
spec: {
|
||||||
|
selector:
|
||||||
|
app: context.name
|
||||||
|
ports: [{
|
||||||
|
port: v
|
||||||
|
targetPort: v
|
||||||
|
}]
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
The usage of this trait could be:
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
apiVersion: core.oam.dev/v1beta1
|
||||||
|
kind: Application
|
||||||
|
metadata:
|
||||||
|
name: testapp
|
||||||
|
spec:
|
||||||
|
components:
|
||||||
|
- name: express-server
|
||||||
|
type: webservice
|
||||||
|
properties:
|
||||||
|
...
|
||||||
|
traits:
|
||||||
|
- type: expose
|
||||||
|
properties:
|
||||||
|
http:
|
||||||
|
myservice1: 8080
|
||||||
|
myservice2: 8081
|
||||||
|
```
|
||||||
|
|
||||||
|
## Execute HTTP Request in Trait Definition
|
||||||
|
|
||||||
|
The trait definition can send a HTTP request and capture the response to help you rendering the resource with keyword `processing`.
|
||||||
|
|
||||||
|
You can define HTTP request `method`, `url`, `body`, `header` and `trailer` in the `processing.http` section, and the returned data will be stored in `processing.output`.
|
||||||
|
|
||||||
|
> Please ensure the target HTTP server returns a **JSON data**. `output`.
|
||||||
|
|
||||||
|
Then you can reference the returned data from `processing.output` in `patch` or `output/outputs`.
|
||||||
|
|
||||||
|
Below is an example:
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
apiVersion: core.oam.dev/v1beta1
|
||||||
|
kind: TraitDefinition
|
||||||
|
metadata:
|
||||||
|
name: auth-service
|
||||||
|
spec:
|
||||||
|
schematic:
|
||||||
|
cue:
|
||||||
|
template: |
|
||||||
|
parameter: {
|
||||||
|
serviceURL: string
|
||||||
|
}
|
||||||
|
|
||||||
|
processing: {
|
||||||
|
output: {
|
||||||
|
token?: string
|
||||||
|
}
|
||||||
|
// The target server will return a JSON data with `token` as key.
|
||||||
|
http: {
|
||||||
|
method: *"GET" | string
|
||||||
|
url: parameter.serviceURL
|
||||||
|
request: {
|
||||||
|
body?: bytes
|
||||||
|
header: {}
|
||||||
|
trailer: {}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
patch: {
|
||||||
|
data: token: processing.output.token
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
In above example, this trait definition will send request to get the `token` data, and then patch the data to given component instance.
|
||||||
|
|
||||||
|
## Data Passing
|
||||||
|
|
||||||
|
A trait definition can read the generated API resources (rendered from `output` and `outputs`) of given component definition.
|
||||||
|
|
||||||
|
> KubeVela will ensure the component definitions are always rendered before traits definitions.
|
||||||
|
|
||||||
|
Specifically, the `context.output` contains the rendered workload API resource (whose GVK is indicated by `spec.workload`in component definition), and use `context.outputs.<xx>` to contain all the other rendered API resources.
|
||||||
|
|
||||||
|
Below is an example for data passing:
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
apiVersion: core.oam.dev/v1beta1
|
||||||
|
kind: ComponentDefinition
|
||||||
|
metadata:
|
||||||
|
name: worker
|
||||||
|
spec:
|
||||||
|
workload:
|
||||||
|
definition:
|
||||||
|
apiVersion: apps/v1
|
||||||
|
kind: Deployment
|
||||||
|
schematic:
|
||||||
|
cue:
|
||||||
|
template: |
|
||||||
|
output: {
|
||||||
|
apiVersion: "apps/v1"
|
||||||
|
kind: "Deployment"
|
||||||
|
spec: {
|
||||||
|
selector: matchLabels: {
|
||||||
|
"app.oam.dev/component": context.name
|
||||||
|
}
|
||||||
|
|
||||||
|
template: {
|
||||||
|
metadata: labels: {
|
||||||
|
"app.oam.dev/component": context.name
|
||||||
|
}
|
||||||
|
spec: {
|
||||||
|
containers: [{
|
||||||
|
name: context.name
|
||||||
|
image: parameter.image
|
||||||
|
ports: [{containerPort: parameter.port}]
|
||||||
|
envFrom: [{
|
||||||
|
configMapRef: name: context.name + "game-config"
|
||||||
|
}]
|
||||||
|
if parameter["cmd"] != _|_ {
|
||||||
|
command: parameter.cmd
|
||||||
|
}
|
||||||
|
}]
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
outputs: gameconfig: {
|
||||||
|
apiVersion: "v1"
|
||||||
|
kind: "ConfigMap"
|
||||||
|
metadata: {
|
||||||
|
name: context.name + "game-config"
|
||||||
|
}
|
||||||
|
data: {
|
||||||
|
enemies: parameter.enemies
|
||||||
|
lives: parameter.lives
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
parameter: {
|
||||||
|
// +usage=Which image would you like to use for your service
|
||||||
|
// +short=i
|
||||||
|
image: string
|
||||||
|
// +usage=Commands to run in the container
|
||||||
|
cmd?: [...string]
|
||||||
|
lives: string
|
||||||
|
enemies: string
|
||||||
|
port: int
|
||||||
|
}
|
||||||
|
|
||||||
|
|
||||||
|
---
|
||||||
|
apiVersion: core.oam.dev/v1beta1
|
||||||
|
kind: TraitDefinition
|
||||||
|
metadata:
|
||||||
|
name: ingress
|
||||||
|
spec:
|
||||||
|
schematic:
|
||||||
|
cue:
|
||||||
|
template: |
|
||||||
|
parameter: {
|
||||||
|
domain: string
|
||||||
|
path: string
|
||||||
|
exposePort: int
|
||||||
|
}
|
||||||
|
// trait template can have multiple outputs in one trait
|
||||||
|
outputs: service: {
|
||||||
|
apiVersion: "v1"
|
||||||
|
kind: "Service"
|
||||||
|
spec: {
|
||||||
|
selector:
|
||||||
|
app: context.name
|
||||||
|
ports: [{
|
||||||
|
port: parameter.exposePort
|
||||||
|
targetPort: context.output.spec.template.spec.containers[0].ports[0].containerPort
|
||||||
|
}]
|
||||||
|
}
|
||||||
|
}
|
||||||
|
outputs: ingress: {
|
||||||
|
apiVersion: "networking.k8s.io/v1beta1"
|
||||||
|
kind: "Ingress"
|
||||||
|
metadata:
|
||||||
|
name: context.name
|
||||||
|
labels: config: context.outputs.gameconfig.data.enemies
|
||||||
|
spec: {
|
||||||
|
rules: [{
|
||||||
|
host: parameter.domain
|
||||||
|
http: {
|
||||||
|
paths: [{
|
||||||
|
path: parameter.path
|
||||||
|
backend: {
|
||||||
|
serviceName: context.name
|
||||||
|
servicePort: parameter.exposePort
|
||||||
|
}
|
||||||
|
}]
|
||||||
|
}
|
||||||
|
}]
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
In detail, during rendering `worker` `ComponentDefinition`:
|
||||||
|
1. the rendered Kubernetes Deployment resource will be stored in the `context.output`,
|
||||||
|
2. all other rendered resources will be stored in `context.outputs.<xx>`, with `<xx>` is the unique name in every `template.outputs`.
|
||||||
|
|
||||||
|
Thus, in `TraitDefinition`, it can read the rendered API resources (e.g. `context.outputs.gameconfig.data.enemies`) from the `context`.
|
||||||
|
|
@ -0,0 +1,2 @@
|
||||||
|
---
|
||||||
|
title: 自定义工作流
|
||||||
|
|
@ -0,0 +1,3 @@
|
||||||
|
---
|
||||||
|
title: 工作流原理
|
||||||
|
---
|
||||||
|
|
@ -10,7 +10,7 @@ Now let's walk through its experience.
|
||||||
|
|
||||||
## Step 1: Install
|
## Step 1: Install
|
||||||
|
|
||||||
Make sure you have finished and verified the installation following [this guide](./install).
|
Make sure you have finished and verified the installation following quick-install.
|
||||||
|
|
||||||
## Step 2: Deploy Your First Application
|
## Step 2: Deploy Your First Application
|
||||||
|
|
||||||
|
|
@ -59,7 +59,7 @@ Services:
|
||||||
- ✅ ingress: Visiting URL: testsvc.example.com, IP: <your IP address>
|
- ✅ ingress: Visiting URL: testsvc.example.com, IP: <your IP address>
|
||||||
```
|
```
|
||||||
|
|
||||||
**In [kind cluster setup](./install#kind)**, you can visit the service via localhost. In other setups, replace localhost with ingress address accordingly.
|
**In kind cluster setup, you can visit the service via localhost. In other setups, replace localhost with ingress address accordingly.
|
||||||
|
|
||||||
```
|
```
|
||||||
curl -H "Host:testsvc.example.com" http://localhost/
|
curl -H "Host:testsvc.example.com" http://localhost/
|
||||||
|
|
|
||||||
|
|
@ -1,71 +0,0 @@
|
||||||
---
|
|
||||||
title: Quick Start
|
|
||||||
---
|
|
||||||
|
|
||||||
Welcome to KubeVela! In this guide, we'll walk you through how to install KubeVela, and deploy your first simple application.
|
|
||||||
|
|
||||||
## Step 1: Install
|
|
||||||
|
|
||||||
Make sure you have finished and verified the installation following [this guide](./install).
|
|
||||||
|
|
||||||
## Step 2: Deploy Your First Application
|
|
||||||
|
|
||||||
```bash script
|
|
||||||
kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/docs/examples/vela-app.yaml
|
|
||||||
```
|
|
||||||
```console
|
|
||||||
application.core.oam.dev/first-vela-app created
|
|
||||||
```
|
|
||||||
|
|
||||||
Above command will apply an application to KubeVela and let it distribute the application to proper runtime infrastructure.
|
|
||||||
|
|
||||||
Check the status until we see `status` is `running` and services are `healthy`:
|
|
||||||
|
|
||||||
```bash script
|
|
||||||
kubectl get application first-vela-app -o yaml
|
|
||||||
```
|
|
||||||
```console
|
|
||||||
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).
|
|
||||||
|
|
||||||
```bash script
|
|
||||||
curl -H "Host:testsvc.example.com" http://<your ip address>/
|
|
||||||
```
|
|
||||||
```console
|
|
||||||
<xmp>
|
|
||||||
Hello World
|
|
||||||
|
|
||||||
|
|
||||||
## .
|
|
||||||
## ## ## ==
|
|
||||||
## ## ## ## ## ===
|
|
||||||
/""""""""""""""""\___/ ===
|
|
||||||
~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ / ===- ~~~
|
|
||||||
\______ o _,/
|
|
||||||
\ \ _,'
|
|
||||||
`'--.._\..--''
|
|
||||||
</xmp>
|
|
||||||
```
|
|
||||||
**Voila!** You are all set to go.
|
|
||||||
|
|
||||||
## What's Next
|
|
||||||
|
|
||||||
Here are some recommended next steps:
|
|
||||||
|
|
||||||
- Learn KubeVela's [core concepts](./concepts)
|
|
||||||
- Learn more details about [`Application`](end-user/application) and what it can do for you.
|
|
||||||
- Learn how to attach [rollout plan](end-user/scopes/rollout-plan) to this application.
|
|
||||||
|
|
@ -81,11 +81,11 @@ module.exports = {
|
||||||
to: '/docs/install',
|
to: '/docs/install',
|
||||||
},
|
},
|
||||||
{
|
{
|
||||||
label: 'Platform Team Guide',
|
label: 'platform-engineers Guide',
|
||||||
to: '/docs/platform-engineers/overview',
|
to: '/docs/platform-engineers/overview',
|
||||||
},
|
},
|
||||||
{
|
{
|
||||||
label: 'Application Team Guide',
|
label: 'End User Guide',
|
||||||
to: '/docs/end-user/application',
|
to: '/docs/end-user/application',
|
||||||
},
|
},
|
||||||
],
|
],
|
||||||
|
|
|
||||||
|
|
@ -29,7 +29,7 @@ KubeVela v1.0 启用了新的官网架构和文档维护方式，新增功能包
|
||||||
|
|
||||||
#### 准备工作
|
#### 准备工作
|
||||||
|
|
||||||
- 账号：您需要先准备一个 GitHub 账号。使用 Github 进行翻译任务的认领和 PR 提交。
|
- 账号：你需要先准备一个 GitHub 账号。使用 Github 进行翻译任务的认领和 PR 提交。
|
||||||
- 仓库和分支管理
|
- 仓库和分支管理
|
||||||
- fork [kubevela.io](https://github.com/oam-dev/kubevela.io) 的仓库，并作为自己仓库的上游： `git remote add upstream https://github.com/oam-dev/kubevela.io.git`
|
- fork [kubevela.io](https://github.com/oam-dev/kubevela.io) 的仓库，并作为自己仓库的上游： `git remote add upstream https://github.com/oam-dev/kubevela.io.git`
|
||||||
- 在自己的仓库，也就是 origin 上进行翻译；
|
- 在自己的仓库，也就是 origin 上进行翻译；
|
||||||
|
|
|
||||||
|
|
@ -32,7 +32,7 @@ KubeVela Github 地址：[https://github.com/oam-dev/kubevela/](https://github.c
|
||||||
|
|
||||||
现如今，云原生技术的迅猛发展可能让很多人都感觉到眼花缭乱，但实际上，这个生态的总体发展趋势和主旋律，是通过 Kubernetes 搭建了一个统一的基础设施抽象层，为平台团队屏蔽掉了“计算”、“网络”、“存储”等过去我们不得不关注的基础设施概念，使得我们能够基于 Kubernetes 方便地构建出任何我们想要的垂直业务系统而无需关心任何基础设施层的细节。这正是 Kubernetes 被称为云计算界的 Linux 以及 “Platform for Platforms” 的根本原因。
|
现如今，云原生技术的迅猛发展可能让很多人都感觉到眼花缭乱，但实际上，这个生态的总体发展趋势和主旋律，是通过 Kubernetes 搭建了一个统一的基础设施抽象层，为平台团队屏蔽掉了“计算”、“网络”、“存储”等过去我们不得不关注的基础设施概念，使得我们能够基于 Kubernetes 方便地构建出任何我们想要的垂直业务系统而无需关心任何基础设施层的细节。这正是 Kubernetes 被称为云计算界的 Linux 以及 “Platform for Platforms” 的根本原因。
|
||||||
|
|
||||||
但是，当我们把视角从平台团队提升到垂直业务系统的最终用户（如：应用开发人员）的时候，我们会发现 Kubernetes 这样的定位和设计在解决了平台团队的大问题之后，却也为应用开发者们带来了挑战和困扰。比如，太多的用户都在抱怨 Kubernetes “太复杂了”。究其原因，其实在于 Kubernetes 中的核心概念与体系，如：Pod、sidecar、Service、资源管理、调度算法和 CRD 等等，主要是面向平台团队而非最终用户设计的。缺乏面向用户的设计不仅带来了陡峭的学习曲线，影响了用户的使用体验，拖慢了研发效能，甚至在很多情况下还会引发错误操作乃至生产故障（毕竟不可能每个业务开发人员都是 Kubernetes 专家）。
|
但是，当我们把视角从平台团队提升到垂直业务系统的最终用户（如：应用开发人员）的时候，我们会发现 Kubernetes 这样的定位和设计在解决了平台团队的大问题之后，却也为用户们带来了挑战和困扰。比如，太多的用户都在抱怨 Kubernetes “太复杂了”。究其原因，其实在于 Kubernetes 中的核心概念与体系，如：Pod、sidecar、Service、资源管理、调度算法和 CRD 等等，主要是面向平台团队而非最终用户设计的。缺乏面向用户的设计不仅带来了陡峭的学习曲线，影响了用户的使用体验，拖慢了研发效能，甚至在很多情况下还会引发错误操作乃至生产故障（毕竟不可能每个业务开发人员都是 Kubernetes 专家）。
|
||||||
|
|
||||||
这也是为什么在云原生生态中，几乎每一个平台团队都会基于 Kubernetes 构建一个上层平台给用户使用。最简单的也会给 Kubernetes 做一个图形界面，稍微正式一些的则往往会基于 Kubernetes 开发一个类 PaaS 平台来满足自己的需求。理论上讲，在 Kubernetes 生态中各种能力已经非常丰富的今天，开发一个类 PaaS 平台应该是比较容易的。
|
这也是为什么在云原生生态中，几乎每一个平台团队都会基于 Kubernetes 构建一个上层平台给用户使用。最简单的也会给 Kubernetes 做一个图形界面，稍微正式一些的则往往会基于 Kubernetes 开发一个类 PaaS 平台来满足自己的需求。理论上讲，在 Kubernetes 生态中各种能力已经非常丰富的今天，开发一个类 PaaS 平台应该是比较容易的。
|
||||||
|
|
||||||
|
|
@ -52,7 +52,7 @@ KubeVela 项目的创立初衷，就是以一个统一的方式同时解决上
|
||||||
|
|
||||||
由于 KubeVela 默认的功能集与“Heroku”类似（即：主要面向应用开发人员），所以在下文中，我们会以应用开发人员或者开发者来代替最终用户。但我们很快也会讲到，KubeVela 里的每一个功能，都是一个插件，作为平台团队，你可以轻松地“卸载”它的所有内置能力、然后“安装”自己需要的任何社区能力，让 KubeVela 变成一个完全不一样的系统。
|
由于 KubeVela 默认的功能集与“Heroku”类似（即：主要面向应用开发人员），所以在下文中，我们会以应用开发人员或者开发者来代替最终用户。但我们很快也会讲到，KubeVela 里的每一个功能，都是一个插件，作为平台团队，你可以轻松地“卸载”它的所有内置能力、然后“安装”自己需要的任何社区能力，让 KubeVela 变成一个完全不一样的系统。
|
||||||
|
|
||||||
### 1. 应用开发者眼中的 KubeVela
|
### 1. 用户眼中的 KubeVela
|
||||||
|
|
||||||
前面已经提到，对于开发者来说，KubeVela 是一个简单、易用、又高可扩展的云原生应用管理工具，它可以让开发者以极低的心智负担和上手成本在 Kubernetes 上定义与部署应用。而关于整个系统的使用，开发者只需要编写一个 docker-compose 风格应用描述文件 Appfile 即可，不需要接触和学习任何 Kubernetes 层的相关细节。
|
前面已经提到，对于开发者来说，KubeVela 是一个简单、易用、又高可扩展的云原生应用管理工具，它可以让开发者以极低的心智负担和上手成本在 Kubernetes 上定义与部署应用。而关于整个系统的使用，开发者只需要编写一个 docker-compose 风格应用描述文件 Appfile 即可，不需要接触和学习任何 Kubernetes 层的相关细节。
|
||||||
|
|
||||||
|
|
@ -98,7 +98,7 @@ services:
|
||||||
|
|
||||||
- [应用特征（Traits）](https://kubevela.io/#/en/concepts?id=workload-type-amp-trait)，则为工作负载实例加上了运维时配置。在上面的例子中，我们定义了一个 Route Trait 来描述应用如何被从外界访问，以及一个 Autoscale Trait 来描述应用如何根据 CPU 使用量进行自动的水平扩容。
|
- [应用特征（Traits）](https://kubevela.io/#/en/concepts?id=workload-type-amp-trait)，则为工作负载实例加上了运维时配置。在上面的例子中，我们定义了一个 Route Trait 来描述应用如何被从外界访问，以及一个 Autoscale Trait 来描述应用如何根据 CPU 使用量进行自动的水平扩容。
|
||||||
|
|
||||||
而正是基于这种模块化的设计，这个 Appfile 本身是高度可扩展的。当任何一个新的 Workload Type 或者 Trait 被安装到平台后，用户就可以立刻在 Appfile 里声明使用这个新增的能力。举个例子，比如后面平台团队新开发了一个用来配置应用监控属性的运维侧能力，叫做 Metrics。那么只需要举手之捞，应用开发者就可以立刻使用 $ vela show metrics 命令查看这个新增能力的详情，并且在 Appfile 中使用它，如下所示：
|
而正是基于这种模块化的设计，这个 Appfile 本身是高度可扩展的。当任何一个新的 Workload Type 或者 Trait 被安装到平台后，用户就可以立刻在 Appfile 里声明使用这个新增的能力。举个例子，比如后面平台团队新开发了一个用来配置应用监控属性的运维侧能力，叫做 Metrics。那么只需要举手之捞，用户就可以立刻使用 $ vela show metrics 命令查看这个新增能力的详情，并且在 Appfile 中使用它，如下所示：
|
||||||
|
|
||||||
```yaml
|
```yaml
|
||||||
name: testapp
|
name: testapp
|
||||||
|
|
@ -161,7 +161,7 @@ services:
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
有了 KubeVela，平台工程师终于拥有了一个可以方便快捷地将任何一个 Kubernetes 社区能力封装抽象成一个面向用户的上层平台特性的强大工具。而作为这个平台的最终用户，应用开发者们只需要学习这些上层抽象，在一个配置文件中描述应用，就可以一键交付出去。
|
有了 KubeVela，平台工程师终于拥有了一个可以方便快捷地将任何一个 Kubernetes 社区能力封装抽象成一个面向用户的上层平台特性的强大工具。而作为这个平台的最终用户，用户们只需要学习这些上层抽象，在一个配置文件中描述应用，就可以一键交付出去。
|
||||||
|
|
||||||
### 3. KubeVela VS 经典 PaaS
|
### 3. KubeVela VS 经典 PaaS
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -3,16 +3,16 @@
|
||||||
"message": "Next",
|
"message": "Next",
|
||||||
"description": "The label for version current"
|
"description": "The label for version current"
|
||||||
},
|
},
|
||||||
"sidebar.docs.category.Overview": {
|
|
||||||
"message": "概述",
|
|
||||||
"description": "The label for category Overview in sidebar docs"
|
|
||||||
},
|
|
||||||
"sidebar.docs.category.Getting Started": {
|
"sidebar.docs.category.Getting Started": {
|
||||||
"message": "快速开始",
|
"message": "快速开始",
|
||||||
"description": "The label for category Getting Started in sidebar docs"
|
"description": "The label for category Getting Started in sidebar docs"
|
||||||
},
|
},
|
||||||
|
"sidebar.docs.category.Core Concepts": {
|
||||||
|
"message": "核心概念",
|
||||||
|
"description": "The label for Core Concepts in sidebar docs"
|
||||||
|
},
|
||||||
"sidebar.docs.category.CUE": {
|
"sidebar.docs.category.CUE": {
|
||||||
"message": "CUE",
|
"message": "CUE 语言",
|
||||||
"description": "The label for category CUE in sidebar docs"
|
"description": "The label for category CUE in sidebar docs"
|
||||||
},
|
},
|
||||||
"sidebar.docs.category.Helm": {
|
"sidebar.docs.category.Helm": {
|
||||||
|
|
@ -24,7 +24,7 @@
|
||||||
"description": "The label for category Raw Template in sidebar docs"
|
"description": "The label for category Raw Template in sidebar docs"
|
||||||
},
|
},
|
||||||
"sidebar.docs.category.Defining Traits": {
|
"sidebar.docs.category.Defining Traits": {
|
||||||
"message": "定义 Traits",
|
"message": "运维特征系统",
|
||||||
"description": "The label for category Defining Traits in sidebar docs"
|
"description": "The label for category Defining Traits in sidebar docs"
|
||||||
},
|
},
|
||||||
"sidebar.docs.category.Defining Cloud Service": {
|
"sidebar.docs.category.Defining Cloud Service": {
|
||||||
|
|
@ -67,8 +67,32 @@
|
||||||
"message": "参考",
|
"message": "参考",
|
||||||
"description": "The label for category References in sidebar docs"
|
"description": "The label for category References in sidebar docs"
|
||||||
},
|
},
|
||||||
|
"sidebar.docs.category.OAM": {
|
||||||
|
"message": "开放应用模型",
|
||||||
|
"description": "The label for category OAM in sidebar docs"
|
||||||
|
},
|
||||||
|
"sidebar.docs.category.Initializer Platform Eng": {
|
||||||
|
"message": "交付环境系统",
|
||||||
|
"description": "The label for category Initializer Platform Eng in sidebar docs"
|
||||||
|
},
|
||||||
|
"sidebar.docs.category.Workflow End User": {
|
||||||
|
"message": "定义交付工作流",
|
||||||
|
"description": "The label for category Workflow End User in sidebar docs"
|
||||||
|
},
|
||||||
|
"sidebar.docs.category.Workflow Platform Engineers": {
|
||||||
|
"message": "工作流系统",
|
||||||
|
"description": "The label for category Workflow Platform Engineers in sidebar docs"
|
||||||
|
},
|
||||||
|
"sidebar.docs.category.Customize Traits": {
|
||||||
|
"message": "自定义运维特征",
|
||||||
|
"description": "The label for category Customize Traits in sidebar docs"
|
||||||
|
},
|
||||||
|
"sidebar.docs.category.Customize Components": {
|
||||||
|
"message": "自定义组件",
|
||||||
|
"description": "The label for category Customize Traits in sidebar docs"
|
||||||
|
},
|
||||||
"sidebar.docs.category.CLI": {
|
"sidebar.docs.category.CLI": {
|
||||||
"message": "CLI",
|
"message": "CLI 命令行工具",
|
||||||
"description": "The label for category CLI in sidebar docs"
|
"description": "The label for category CLI in sidebar docs"
|
||||||
},
|
},
|
||||||
"sidebar.docs.category.Capabilities": {
|
"sidebar.docs.category.Capabilities": {
|
||||||
|
|
@ -80,39 +104,43 @@
|
||||||
"description": "The label for category Appendix in sidebar docs"
|
"description": "The label for category Appendix in sidebar docs"
|
||||||
},
|
},
|
||||||
"sidebar.docs.category.Defining Components": {
|
"sidebar.docs.category.Defining Components": {
|
||||||
"message": "定义 Components",
|
"message": "组件系统",
|
||||||
"description": "The label for category Defining Components in sidebar docs"
|
"description": "The label for category Defining Components in sidebar docs"
|
||||||
},
|
},
|
||||||
"sidebar.docs.category.Application Team Guide": {
|
"sidebar.docs.category.End User Guide": {
|
||||||
"message": "Application Team Guide",
|
"message": "用户手册",
|
||||||
"description": "The label for category Application Team Guide in sidebar docs"
|
"description": "The label for category End User Guide in sidebar docs"
|
||||||
},
|
},
|
||||||
"sidebar.docs.category.Components": {
|
"sidebar.docs.category.Components": {
|
||||||
"message": "Components",
|
"message": "选择待交付组件",
|
||||||
"description": "The label for category Components in sidebar docs"
|
"description": "The label for category Components in sidebar docs"
|
||||||
},
|
},
|
||||||
"sidebar.docs.category.Traits": {
|
"sidebar.docs.category.Traits": {
|
||||||
"message": "Traits",
|
"message": "挂载运维特征",
|
||||||
"description": "The label for category Traits in sidebar docs"
|
"description": "The label for category Traits in sidebar docs"
|
||||||
},
|
},
|
||||||
"sidebar.docs.category.Observability": {
|
"sidebar.docs.category.Observability": {
|
||||||
"message": "Observability",
|
"message": "新增可观测性",
|
||||||
"description": "The label for category Observability in sidebar docs"
|
"description": "The label for category Observability in sidebar docs"
|
||||||
},
|
},
|
||||||
|
"sidebar.docs.category.Scaler": {
|
||||||
|
"message": "扩缩容",
|
||||||
|
"description": "The label for category Scaler in sidebar docs"
|
||||||
|
},
|
||||||
"sidebar.docs.category.Debugging": {
|
"sidebar.docs.category.Debugging": {
|
||||||
"message": "Debugging",
|
"message": "调试指南",
|
||||||
"description": "The label for category Debugging in sidebar docs"
|
"description": "The label for category Debugging in sidebar docs"
|
||||||
},
|
},
|
||||||
"sidebar.docs.category.Platform Team Guide": {
|
"sidebar.docs.category.platform-engineers Guide": {
|
||||||
"message": "Platform Team Guide",
|
"message": "管理员手册",
|
||||||
"description": "The label for category Platform Team Guide in sidebar docs"
|
"description": "The label for category platform-engineers Guide in sidebar docs"
|
||||||
},
|
},
|
||||||
"sidebar.docs.category.Simple Template": {
|
"sidebar.docs.category.Simple Template": {
|
||||||
"message": "Simple Template",
|
"message": "Simple Template",
|
||||||
"description": "The label for category Simple Template in sidebar docs"
|
"description": "The label for category Simple Template in sidebar docs"
|
||||||
},
|
},
|
||||||
"sidebar.docs.category.Cloud Services": {
|
"sidebar.docs.category.Cloud Services": {
|
||||||
"message": "Cloud Services",
|
"message": "云服务",
|
||||||
"description": "The label for category Cloud Services in sidebar docs"
|
"description": "The label for category Cloud Services in sidebar docs"
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
@ -14,11 +14,11 @@ KubeVela is a modern application engine that adapts to your application's needs,
|
||||||
|
|
||||||
## Installation
|
## Installation
|
||||||
|
|
||||||
Installation guide is available on [this section](./install).
|
Installation guide is available on [this section](getting-started/quick-install).
|
||||||
|
|
||||||
## Quick Start
|
## Quick Start
|
||||||
|
|
||||||
Quick start is available on [this section](./quick-start).
|
Quick start is available on [this section](getting-started/first-application).
|
||||||
|
|
||||||
## Contributing
|
## Contributing
|
||||||
Check out [CONTRIBUTING](https://github.com/oam-dev/kubevela/blob/master/CONTRIBUTING.md) to see how to develop with KubeVela.
|
Check out [CONTRIBUTING](https://github.com/oam-dev/kubevela/blob/master/CONTRIBUTING.md) to see how to develop with KubeVela.
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,4 @@
|
||||||
|
---
|
||||||
|
title: 应用部署计划
|
||||||
|
---
|
||||||
|
|
||||||
|
|
@ -0,0 +1,5 @@
|
||||||
|
---
|
||||||
|
title: 系统架构
|
||||||
|
---
|
||||||
|
|
||||||
|
|
||||||
|
|
@ -0,0 +1,5 @@
|
||||||
|
---
|
||||||
|
title: 交付工作流
|
||||||
|
---
|
||||||
|
|
||||||
|
|
||||||
|
|
@ -4,7 +4,7 @@ title: The Reference Documentation Guide of Capabilities
|
||||||
|
|
||||||
In this documentation, we will show how to check the detailed schema of a given capability (i.e. workload type or trait).
|
In this documentation, we will show how to check the detailed schema of a given capability (i.e. workload type or trait).
|
||||||
|
|
||||||
This may sound challenging because every capability is a "plug-in" in KubeVela (even for the built-in ones), also, it's by design that KubeVela allows platform administrators to modify the capability templates at any time. In this case, do we need to manually write documentation for every newly installed capability? And how can we ensure those documentations for the system is up-to-date?
|
This may sound challenging because every capability is a "plug-in" in KubeVela (even for the built-in ones), also, it's by design that KubeVela allows platform platform-engineerss to modify the capability templates at any time. In this case, do we need to manually write documentation for every newly installed capability? And how can we ensure those documentations for the system is up-to-date?
|
||||||
|
|
||||||
## Using Browser
|
## Using Browser
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -72,7 +72,7 @@ Services:
|
||||||
- route: Visiting URL: http://example.com IP: <ingress-IP-address>
|
- route: Visiting URL: http://example.com IP: <ingress-IP-address>
|
||||||
```
|
```
|
||||||
|
|
||||||
**In [kind cluster setup](../../install#kind)**, you can visit the service via localhost:
|
**In [kind cluster setup](../../getting-started/quick-install#kind)**, you can visit the service via localhost:
|
||||||
|
|
||||||
> If not in kind cluster, replace 'localhost' with ingress address
|
> If not in kind cluster, replace 'localhost' with ingress address
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -35,7 +35,7 @@ services:
|
||||||
|
|
||||||
## Schema
|
## Schema
|
||||||
|
|
||||||
> 在深入学习 Appfile 的详细 schema 之前，我们建议你先熟悉 KubeVela 的[核心概念](../concepts)
|
> 在深入学习 Appfile 的详细 schema 之前，我们建议你先熟悉 KubeVela 的[核心概念](../core-concepts/application.md)
|
||||||
|
|
||||||
```yaml
|
```yaml
|
||||||
name: _app-name_
|
name: _app-name_
|
||||||
|
|
@ -80,7 +80,7 @@ services:
|
||||||
### 环境要求
|
### 环境要求
|
||||||
|
|
||||||
- [Docker](https://docs.docker.com/get-docker/) 需要在主机上安装 docker
|
- [Docker](https://docs.docker.com/get-docker/) 需要在主机上安装 docker
|
||||||
- [KubeVela](../install) 需要安装 KubeVela 并配置
|
- [KubeVela](../getting-started/quick-install) 需要安装 KubeVela 并配置
|
||||||
|
|
||||||
### 1. 下载测试的 app 的源码
|
### 1. 下载测试的 app 的源码
|
||||||
|
|
||||||
|
|
@ -159,7 +159,7 @@ $ vela status testapp
|
||||||
|
|
||||||
#### 本地测试方式
|
#### 本地测试方式
|
||||||
|
|
||||||
如果你本地有运行的 [kind](../install) 集群，你可以尝试推送到本地。这种方法无需注册远程容器仓库。
|
如果你本地有运行的 [kind](../getting-started/quick-install) 集群，你可以尝试推送到本地。这种方法无需注册远程容器仓库。
|
||||||
|
|
||||||
在 `build` 中添加 local 的选项值：
|
在 `build` 中添加 local 的选项值：
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,237 +0,0 @@
|
||||||
---
|
|
||||||
title: Application
|
|
||||||
---
|
|
||||||
|
|
||||||
本文档将介绍如何使用 KubeVela 设计一个没有定义任何策略或放置规则的简单 Application。
|
|
||||||
|
|
||||||
> 注意：由于您没有声明放置规则，KubeVela 会将此应用程序直接部署到控制平面集群（即您的 `kubectl` 正在与之通信的集群）。 如果你使用 KinD 或 MiniKube 等本地集群来玩 KubeVela，也是同样的情况。
|
|
||||||
|
|
||||||
## 步骤 1：检查可用组件
|
|
||||||
|
|
||||||
组件是组成应用程序的可部署或可配置实体。 它可以是 Helm chart、简单的 Kubernetes 工作负载、CUE 或 Terraform 模块或云数据库等。
|
|
||||||
|
|
||||||
让我们检查一下全新 KubeVela 中的可用组件。
|
|
||||||
|
|
||||||
```shell
|
|
||||||
kubectl get comp -n vela-system
|
|
||||||
```
|
|
||||||
```console
|
|
||||||
NAME WORKLOAD-KIND DESCRIPTION
|
|
||||||
task Job Describes jobs that run code or a script to completion.
|
|
||||||
webservice Deployment Describes long-running, scalable, containerized services that have a stable network endpoint to receive external network traffic from customers.
|
|
||||||
worker Deployment Describes long-running, scalable, containerized services that running at backend. They do NOT have network endpoint to receive external network traffic.
|
|
||||||
```
|
|
||||||
|
|
||||||
要显示给定组件的规范，您可以使用 `vela show`。
|
|
||||||
|
|
||||||
```shell
|
|
||||||
kubectl vela show webservice
|
|
||||||
```
|
|
||||||
```console
|
|
||||||
# Properties
|
|
||||||
+------------------+----------------------------------------------------------------------------------+-----------------------+----------+---------+
|
|
||||||
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
|
|
||||||
+------------------+----------------------------------------------------------------------------------+-----------------------+----------+---------+
|
|
||||||
| cmd | Commands to run in the container | []string | false | |
|
|
||||||
| env | Define arguments by using environment variables | [[]env](#env) | false | |
|
|
||||||
| addRevisionLabel | | bool | true | false |
|
|
||||||
| image | Which image would you like to use for your service | string | true | |
|
|
||||||
| port | Which port do you want customer traffic sent to | int | true | 80 |
|
|
||||||
| cpu | Number of CPU units for the service, like `0.5` (0.5 CPU core), `1` (1 CPU core) | string | false | |
|
|
||||||
| volumes | Declare volumes and volumeMounts | [[]volumes](#volumes) | false | |
|
|
||||||
+------------------+----------------------------------------------------------------------------------+-----------------------+----------+---------+
|
|
||||||
... // skip other fields
|
|
||||||
```
|
|
||||||
|
|
||||||
> 提示：`vela show xxx --web` 将在您的默认浏览器中打开其功能参考文档。
|
|
||||||
|
|
||||||
您可以随时向平台[添加更多组件](components/more)。
|
|
||||||
|
|
||||||
## 步骤 2：声明一个 Application
|
|
||||||
|
|
||||||
Application 是部署的完整描述。 让我们定义一个部署 *Web Service* 和 *Worker* 组件的 Application。
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
# sample.yaml
|
|
||||||
apiVersion: core.oam.dev/v1beta1
|
|
||||||
kind: Application
|
|
||||||
metadata:
|
|
||||||
name: website
|
|
||||||
spec:
|
|
||||||
components:
|
|
||||||
- name: frontend
|
|
||||||
type: webservice
|
|
||||||
properties:
|
|
||||||
image: nginx
|
|
||||||
- name: backend
|
|
||||||
type: worker
|
|
||||||
properties:
|
|
||||||
image: busybox
|
|
||||||
cmd:
|
|
||||||
- sleep
|
|
||||||
- '1000'
|
|
||||||
```
|
|
||||||
|
|
||||||
## 步骤 3：附加 Trait
|
|
||||||
|
|
||||||
Trait 是平台提供的功能，可以*Overlay*具有额外操作行为的给定组件。
|
|
||||||
|
|
||||||
```shell
|
|
||||||
kubectl get trait -n vela-system
|
|
||||||
```
|
|
||||||
```console
|
|
||||||
NAME APPLIES-TO DESCRIPTION
|
|
||||||
cpuscaler [webservice worker] Automatically scale the component based on CPU usage.
|
|
||||||
ingress [webservice worker] Enable public web traffic for the component.
|
|
||||||
scaler [webservice worker] Manually scale the component.
|
|
||||||
sidecar [webservice worker] Inject a sidecar container to the component.
|
|
||||||
```
|
|
||||||
|
|
||||||
让我们检查一下 `sidecar` trait 的规范。
|
|
||||||
|
|
||||||
```shell
|
|
||||||
kubectl vela show sidecar
|
|
||||||
```
|
|
||||||
```console
|
|
||||||
# Properties
|
|
||||||
+---------+-----------------------------------------+----------+----------+---------+
|
|
||||||
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
|
|
||||||
+---------+-----------------------------------------+----------+----------+---------+
|
|
||||||
| name | Specify the name of sidecar container | string | true | |
|
|
||||||
| image | Specify the image of sidecar container | string | true | |
|
|
||||||
| command | Specify the commands run in the sidecar | []string | false | |
|
|
||||||
+---------+-----------------------------------------+----------+----------+---------+
|
|
||||||
```
|
|
||||||
|
|
||||||
请注意，Trait 被设计为可以 *Overlay*。
|
|
||||||
|
|
||||||
这意味着对于 `sidecar` trait，你的 `frontend` 组件不需要有一个 sidecar 模板或带一个 webhook 来启用 sidecar 注入。 相反，KubeVela 能够在组件生成 sidecar 之后（无论是 Helm chart 还是 CUE 模块），但在将 sidecar 应用于运行时集群之前，将其修补到其工作负载实例。
|
|
||||||
|
|
||||||
同样，系统将根据您设置的属性分配一个 HPA 实例并将其“链接”到目标工作负载实例，组件本身不受影响。
|
|
||||||
|
|
||||||
现在让我们将 `sidecar` 和 `cpuscaler` trait 附加到 `frontend` 组件。
|
|
||||||
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
# sample.yaml
|
|
||||||
apiVersion: core.oam.dev/v1beta1
|
|
||||||
kind: Application
|
|
||||||
metadata:
|
|
||||||
name: website
|
|
||||||
spec:
|
|
||||||
components:
|
|
||||||
- name: frontend # This is the component I want to deploy
|
|
||||||
type: webservice
|
|
||||||
properties:
|
|
||||||
image: nginx
|
|
||||||
traits:
|
|
||||||
- type: cpuscaler # Automatically scale the component by CPU usage after deployed
|
|
||||||
properties:
|
|
||||||
min: 1
|
|
||||||
max: 10
|
|
||||||
cpuPercent: 60
|
|
||||||
- type: sidecar # Inject a fluentd sidecar before applying the component to runtime cluster
|
|
||||||
properties:
|
|
||||||
name: "sidecar-test"
|
|
||||||
image: "fluentd"
|
|
||||||
- name: backend
|
|
||||||
type: worker
|
|
||||||
properties:
|
|
||||||
image: busybox
|
|
||||||
cmd:
|
|
||||||
- sleep
|
|
||||||
- '1000'
|
|
||||||
```
|
|
||||||
|
|
||||||
## 步骤 4：部署 Application
|
|
||||||
|
|
||||||
```shell
|
|
||||||
kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/docs/examples/enduser/sample.yaml
|
|
||||||
```
|
|
||||||
```console
|
|
||||||
application.core.oam.dev/website created
|
|
||||||
```
|
|
||||||
|
|
||||||
你会得到 Application 变成`running`。
|
|
||||||
|
|
||||||
```shell
|
|
||||||
kubectl get application
|
|
||||||
```
|
|
||||||
```console
|
|
||||||
NAME COMPONENT TYPE PHASE HEALTHY STATUS AGE
|
|
||||||
website frontend webservice running true 4m54s
|
|
||||||
```
|
|
||||||
|
|
||||||
检查 Application 的详细信息。
|
|
||||||
|
|
||||||
```shell
|
|
||||||
kubectl get app website -o yaml
|
|
||||||
```
|
|
||||||
```console
|
|
||||||
apiVersion: core.oam.dev/v1beta1
|
|
||||||
kind: Application
|
|
||||||
metadata:
|
|
||||||
generation: 1
|
|
||||||
name: website
|
|
||||||
namespace: default
|
|
||||||
spec:
|
|
||||||
components:
|
|
||||||
- name: frontend
|
|
||||||
properties:
|
|
||||||
image: nginx
|
|
||||||
traits:
|
|
||||||
- properties:
|
|
||||||
cpuPercent: 60
|
|
||||||
max: 10
|
|
||||||
min: 1
|
|
||||||
type: cpuscaler
|
|
||||||
- properties:
|
|
||||||
image: fluentd
|
|
||||||
name: sidecar-test
|
|
||||||
type: sidecar
|
|
||||||
type: webservice
|
|
||||||
- name: backend
|
|
||||||
properties:
|
|
||||||
cmd:
|
|
||||||
- sleep
|
|
||||||
- "1000"
|
|
||||||
image: busybox
|
|
||||||
type: worker
|
|
||||||
status:
|
|
||||||
...
|
|
||||||
latestRevision:
|
|
||||||
name: website-v1
|
|
||||||
revision: 1
|
|
||||||
revisionHash: e9e062e2cddfe5fb
|
|
||||||
services:
|
|
||||||
- healthy: true
|
|
||||||
name: frontend
|
|
||||||
traits:
|
|
||||||
- healthy: true
|
|
||||||
type: cpuscaler
|
|
||||||
- healthy: true
|
|
||||||
type: sidecar
|
|
||||||
- healthy: true
|
|
||||||
name: backend
|
|
||||||
status: running
|
|
||||||
```
|
|
||||||
|
|
||||||
具体来说：
|
|
||||||
|
|
||||||
1. `status.latestRevision` 声明此部署的当前版本。
|
|
||||||
2. `status.services` 声明本次部署创建的组件和健康状态。
|
|
||||||
3. `status.status` 声明了这个部署的全局状态。
|
|
||||||
|
|
||||||
### 列出修订
|
|
||||||
|
|
||||||
更新应用程序实体时，KubeVela 将为此更改创建一个新修订。
|
|
||||||
|
|
||||||
```shell
|
|
||||||
kubectl get apprev -l app.oam.dev/name=website
|
|
||||||
```
|
|
||||||
```console
|
|
||||||
NAME AGE
|
|
||||||
website-v1 35m
|
|
||||||
```
|
|
||||||
|
|
||||||
此外，系统将根据附加的 [rollout plan](scopes/rollout-plan) 决定如何/是否部署应用程序。
|
|
||||||
|
|
@ -2,15 +2,15 @@
|
||||||
title: 云服务
|
title: 云服务
|
||||||
---
|
---
|
||||||
|
|
||||||
KubeVela 允许您在一致的 API 中声明您的应用程序所需的云服务。 目前，我们同时支持 Terraform 和 Crossplane。
|
KubeVela 允许你在一致的 API 中声明你的应用程序所需的云服务。 目前，我们同时支持 Terraform 和 Crossplane。
|
||||||
|
|
||||||
> 如果您对 KubeVela 中如何维护这些功能感兴趣，请查看 [云服务平台团队指南](../../platform-engineers/cloud-services)。
|
> 如果你对 KubeVela 中如何维护这些功能感兴趣，请查看 [云服务平台团队指南](../../platform-engineers/cloud-services)。
|
||||||
|
|
||||||
应用程序将通过 [Service Binding Trait](../traits/service-binding) 使用云服务。
|
应用程序将通过 [Service Binding Trait](../traits/service-binding) 使用云服务。
|
||||||
|
|
||||||
## Terraform
|
## Terraform
|
||||||
|
|
||||||
> ⚠️ 本节假设 [Terraform 相关功能](../../platform-engineers/terraform) 已安装在您的平台中。
|
> ⚠️ 本节假设 [Terraform 相关功能](../../platform-engineers/components/component-terraform) 已安装在你的平台中。
|
||||||
|
|
||||||
检查云资源 component 和 trait 的参数。
|
检查云资源 component 和 trait 的参数。
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,5 @@
|
||||||
|
---
|
||||||
|
title: Alibaba-ROS
|
||||||
|
---
|
||||||
|
|
||||||
|
TBD
|
||||||
|
|
@ -0,0 +1,5 @@
|
||||||
|
---
|
||||||
|
title: RDS
|
||||||
|
---
|
||||||
|
|
||||||
|
TBD
|
||||||
|
|
@ -0,0 +1,5 @@
|
||||||
|
---
|
||||||
|
title: SLS
|
||||||
|
---
|
||||||
|
|
||||||
|
TBD
|
||||||
|
|
@ -0,0 +1,5 @@
|
||||||
|
---
|
||||||
|
title: 默认组件
|
||||||
|
---
|
||||||
|
|
||||||
|
TBD
|
||||||
|
|
@ -0,0 +1,5 @@
|
||||||
|
---
|
||||||
|
title: Helm 组件
|
||||||
|
---
|
||||||
|
|
||||||
|
TBD
|
||||||
|
|
@ -0,0 +1,5 @@
|
||||||
|
---
|
||||||
|
title: Kustomize 组件
|
||||||
|
---
|
||||||
|
|
||||||
|
TBD
|
||||||
|
|
@ -6,10 +6,10 @@ KubeVela 中的组件旨在由用户带来。
|
||||||
|
|
||||||
## 1. 从能力中心获取
|
## 1. 从能力中心获取
|
||||||
|
|
||||||
KubeVela 允许您探索由平台团队维护的功能。
|
KubeVela 允许你探索由平台团队维护的功能。
|
||||||
kubectl vela 插件中有两个命令：`comp` 和 `trait`。
|
kubectl vela 插件中有两个命令：`comp` 和 `trait`。
|
||||||
|
|
||||||
<!-- 如果您尚未安装 kubectl vela 插件：请参阅 [这里](../../developers/references/kubectl-plugin#install-kubectl-vela-plugin)。 -->
|
<!-- 如果你尚未安装 kubectl vela 插件：请参阅 [这里](../../developers/references/kubectl-plugin#install-kubectl-vela-plugin)。 -->
|
||||||
|
|
||||||
### 1. 列表
|
### 1. 列表
|
||||||
|
|
||||||
|
|
@ -47,9 +47,9 @@ cloneset CloneSet Describes long-running, scalable, containerized ser
|
||||||
默认情况下，这两个命令将从 KubeVela 维护的 [repo](https://registry.kubevela.net) 中检索功能。
|
默认情况下，这两个命令将从 KubeVela 维护的 [repo](https://registry.kubevela.net) 中检索功能。
|
||||||
|
|
||||||
## 2. 自己设计
|
## 2. 自己设计
|
||||||
查看以下文档，了解如何以各种方法将您自己的组件引入系统。
|
查看以下文档，了解如何以各种方法将你自己的组件引入系统。
|
||||||
|
|
||||||
- [Helm](../../platform-engineers/helm/component) - Helm chart 是组件的一种自然形式，请注意，在这种情况下，您需要有一个有效的 Helm 存储库（例如 GitHub 存储库或 Helm 中心）来托管 chart。
|
- [Helm](../../platform-engineers/helm/component) - Helm chart 是组件的一种自然形式，请注意，在这种情况下，你需要有一个有效的 Helm 存储库（例如 GitHub 存储库或 Helm 中心）来托管 chart。
|
||||||
- [CUE](../../platform-engineers/cue/component) - CUE 是封装组件的强大方法，它不需要任何存储库。
|
- [CUE](../../platform-engineers/components/component-cue) - CUE 是封装组件的强大方法，它不需要任何存储库。
|
||||||
- [Simple Template](../../platform-engineers/kube/component) - 不是 Helm 或 CUE 专家？ 还提供了一种简单的模板方法来将任何 Kubernetes API 资源定义为一个组件。 请注意，在这种情况下仅支持键值样式参数。
|
- [Simple Template](../../platform-engineers/kube/component) - 不是 Helm 或 CUE 专家？ 还提供了一种简单的模板方法来将任何 Kubernetes API 资源定义为一个组件。 请注意，在这种情况下仅支持键值样式参数。
|
||||||
- [Cloud Services](../../platform-engineers/cloud-services) - KubeVela 允许您将云服务声明为应用程序的一部分，并在一致的 API 中提供它们。
|
- [Cloud Services](../../platform-engineers/cloud-services) - KubeVela 允许你将云服务声明为应用程序的一部分，并在一致的 API 中提供它们。
|
||||||
|
|
|
||||||
|
|
@ -1,370 +0,0 @@
|
||||||
---
|
|
||||||
title: Dry-Run / Live-Diff
|
|
||||||
---
|
|
||||||
|
|
||||||
KubeVela 支持两种方式调试 application：dry-run 和 live-diff。
|
|
||||||
|
|
||||||
|
|
||||||
## Dry-Run `Application`
|
|
||||||
|
|
||||||
Dry-run 将帮助我们了解哪些资源将被处理并部署到 Kubernetes 集群。另外，该命令支持模拟运行与KubeVela的控制器相同的逻辑并在本地输出结果。
|
|
||||||
|
|
||||||
比如，我们 dry-run 下面 application：
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
# app.yaml
|
|
||||||
apiVersion: core.oam.dev/v1beta1
|
|
||||||
kind: Application
|
|
||||||
metadata:
|
|
||||||
name: vela-app
|
|
||||||
spec:
|
|
||||||
components:
|
|
||||||
- name: express-server
|
|
||||||
type: webservice
|
|
||||||
properties:
|
|
||||||
image: crccheck/hello-world
|
|
||||||
port: 8000
|
|
||||||
traits:
|
|
||||||
- type: ingress
|
|
||||||
properties:
|
|
||||||
domain: testsvc.example.com
|
|
||||||
http:
|
|
||||||
"/": 8000
|
|
||||||
```
|
|
||||||
|
|
||||||
```shell
|
|
||||||
kubectl vela dry-run -f app.yaml
|
|
||||||
---
|
|
||||||
# Application(vela-app) -- Comopnent(express-server)
|
|
||||||
---
|
|
||||||
|
|
||||||
apiVersion: apps/v1
|
|
||||||
kind: Deployment
|
|
||||||
metadata:
|
|
||||||
labels:
|
|
||||||
app.oam.dev/appRevision: ""
|
|
||||||
app.oam.dev/component: express-server
|
|
||||||
app.oam.dev/name: vela-app
|
|
||||||
workload.oam.dev/type: webservice
|
|
||||||
spec:
|
|
||||||
selector:
|
|
||||||
matchLabels:
|
|
||||||
app.oam.dev/component: express-server
|
|
||||||
template:
|
|
||||||
metadata:
|
|
||||||
labels:
|
|
||||||
app.oam.dev/component: express-server
|
|
||||||
spec:
|
|
||||||
containers:
|
|
||||||
- image: crccheck/hello-world
|
|
||||||
name: express-server
|
|
||||||
ports:
|
|
||||||
- containerPort: 8000
|
|
||||||
|
|
||||||
---
|
|
||||||
apiVersion: v1
|
|
||||||
kind: Service
|
|
||||||
metadata:
|
|
||||||
labels:
|
|
||||||
app.oam.dev/appRevision: ""
|
|
||||||
app.oam.dev/component: express-server
|
|
||||||
app.oam.dev/name: vela-app
|
|
||||||
trait.oam.dev/resource: service
|
|
||||||
trait.oam.dev/type: ingress
|
|
||||||
name: express-server
|
|
||||||
spec:
|
|
||||||
ports:
|
|
||||||
- port: 8000
|
|
||||||
targetPort: 8000
|
|
||||||
selector:
|
|
||||||
app.oam.dev/component: express-server
|
|
||||||
|
|
||||||
---
|
|
||||||
apiVersion: networking.k8s.io/v1beta1
|
|
||||||
kind: Ingress
|
|
||||||
metadata:
|
|
||||||
labels:
|
|
||||||
app.oam.dev/appRevision: ""
|
|
||||||
app.oam.dev/component: express-server
|
|
||||||
app.oam.dev/name: vela-app
|
|
||||||
trait.oam.dev/resource: ingress
|
|
||||||
trait.oam.dev/type: ingress
|
|
||||||
name: express-server
|
|
||||||
spec:
|
|
||||||
rules:
|
|
||||||
- host: testsvc.example.com
|
|
||||||
http:
|
|
||||||
paths:
|
|
||||||
- backend:
|
|
||||||
serviceName: express-server
|
|
||||||
servicePort: 8000
|
|
||||||
path: /
|
|
||||||
|
|
||||||
---
|
|
||||||
```
|
|
||||||
|
|
||||||
当前示例中，application `vela-app` 依赖 KubeVela 内置的 component（`webservice`） 和 trait（`ingress`）。我们也可以通过参数 `-d ` 或者 `--definitions` 指定本地 definition 文件。
|
|
||||||
|
|
||||||
参数 `-d ` 或者 `--definitions` 允许用户从本地文件导入指定的 definitions 以供 application 使用。
|
|
||||||
参数 `dry-run` 会将优先使用用户指定的 capabilities 。
|
|
||||||
|
|
||||||
## Live-Diff `Application`
|
|
||||||
|
|
||||||
Live-diff 将帮助我们预览本次升级 application 会有哪些变更，同时不会对现有集群产生影响。
|
|
||||||
本功能对于生产环境变更非常有用，同时还能保证升级可控。
|
|
||||||
|
|
||||||
本功能会在线上正在运行的版本与本地待升级版本之间生成差异信息。
|
|
||||||
最终差异结果将展示 application 以及子资源（比如 components 以及 traits）的变更信息（added/modified/removed/no_change）。
|
|
||||||
|
|
||||||
假设我们在 dry-run 环节已经部署 application 。
|
|
||||||
随后，我们列出上面 application 的 revisions 信息。
|
|
||||||
|
|
||||||
```shell
|
|
||||||
$ kubectl get apprev -l app.oam.dev/name=vela-app
|
|
||||||
NAME AGE
|
|
||||||
vela-app-v1 50s
|
|
||||||
```
|
|
||||||
|
|
||||||
假设我们将更新该 application ：
|
|
||||||
|
|
||||||
```yaml
|
|
||||||
# new-app.yaml
|
|
||||||
apiVersion: core.oam.dev/v1beta1
|
|
||||||
kind: Application
|
|
||||||
metadata:
|
|
||||||
name: vela-app
|
|
||||||
spec:
|
|
||||||
components:
|
|
||||||
- name: express-server
|
|
||||||
type: webservice
|
|
||||||
properties:
|
|
||||||
image: crccheck/hello-world
|
|
||||||
port: 8080 # change port
|
|
||||||
cpu: 0.5 # add requests cpu units
|
|
||||||
- name: my-task # add a component
|
|
||||||
type: task
|
|
||||||
properties:
|
|
||||||
image: busybox
|
|
||||||
cmd: ["sleep", "1000"]
|
|
||||||
traits:
|
|
||||||
- type: ingress
|
|
||||||
properties:
|
|
||||||
domain: testsvc.example.com
|
|
||||||
http:
|
|
||||||
"/": 8080 # change port
|
|
||||||
```
|
|
||||||
|
|
||||||
执行 live-diff ：
|
|
||||||
|
|
||||||
```shell
|
|
||||||
kubectl vela live-diff -f new-app.yaml -r vela-app-v1
|
|
||||||
```
|
|
||||||
|
|
||||||
参数 `-r` 或者 `--revision` 用于指定正在运行中的 ApplicationRevision 名称，该版本将用于与更新版本进行比较。
|
|
||||||
|
|
||||||
参数 `-c` or `--context` 用于指定显示变更上下文行数，超出上线行数的未变更行将被省略。该功能对于如下场景非常有用：差异结果包含很多未更改的内容，而我们只想关注已更改的内容。
|
|
||||||
|
|
||||||
<details><summary> diff </summary>
|
|
||||||
|
|
||||||
```bash
|
|
||||||
---
|
|
||||||
# Application (vela-app) has been modified(*)
|
|
||||||
---
|
|
||||||
apiVersion: core.oam.dev/v1beta1
|
|
||||||
kind: Application
|
|
||||||
metadata:
|
|
||||||
creationTimestamp: null
|
|
||||||
name: vela-app
|
|
||||||
namespace: default
|
|
||||||
spec:
|
|
||||||
components:
|
|
||||||
- name: express-server
|
|
||||||
properties:
|
|
||||||
+ cpu: 0.5
|
|
||||||
image: crccheck/hello-world
|
|
||||||
- port: 8000
|
|
||||||
+ port: 8080
|
|
||||||
+ type: webservice
|
|
||||||
+ - name: my-task
|
|
||||||
+ properties:
|
|
||||||
+ cmd:
|
|
||||||
+ - sleep
|
|
||||||
+ - "1000"
|
|
||||||
+ image: busybox
|
|
||||||
traits:
|
|
||||||
- properties:
|
|
||||||
domain: testsvc.example.com
|
|
||||||
http:
|
|
||||||
- /: 8000
|
|
||||||
+ /: 8080
|
|
||||||
type: ingress
|
|
||||||
- type: webservice
|
|
||||||
+ type: task
|
|
||||||
status:
|
|
||||||
batchRollingState: ""
|
|
||||||
currentBatch: 0
|
|
||||||
rollingState: ""
|
|
||||||
upgradedReadyReplicas: 0
|
|
||||||
upgradedReplicas: 0
|
|
||||||
|
|
||||||
---
|
|
||||||
## Component (express-server) has been modified(*)
|
|
||||||
---
|
|
||||||
apiVersion: core.oam.dev/v1alpha2
|
|
||||||
kind: Component
|
|
||||||
metadata:
|
|
||||||
creationTimestamp: null
|
|
||||||
labels:
|
|
||||||
app.oam.dev/name: vela-app
|
|
||||||
name: express-server
|
|
||||||
spec:
|
|
||||||
workload:
|
|
||||||
apiVersion: apps/v1
|
|
||||||
kind: Deployment
|
|
||||||
metadata:
|
|
||||||
labels:
|
|
||||||
app.oam.dev/appRevision: ""
|
|
||||||
app.oam.dev/component: express-server
|
|
||||||
app.oam.dev/name: vela-app
|
|
||||||
workload.oam.dev/type: webservice
|
|
||||||
spec:
|
|
||||||
selector:
|
|
||||||
matchLabels:
|
|
||||||
app.oam.dev/component: express-server
|
|
||||||
template:
|
|
||||||
metadata:
|
|
||||||
labels:
|
|
||||||
app.oam.dev/component: express-server
|
|
||||||
spec:
|
|
||||||
containers:
|
|
||||||
- image: crccheck/hello-world
|
|
||||||
name: express-server
|
|
||||||
ports:
|
|
||||||
- - containerPort: 8000
|
|
||||||
+ - containerPort: 8080
|
|
||||||
status:
|
|
||||||
observedGeneration: 0
|
|
||||||
|
|
||||||
---
|
|
||||||
### Component (express-server) / Trait (ingress/service) has been removed(-)
|
|
||||||
---
|
|
||||||
- apiVersion: v1
|
|
||||||
- kind: Service
|
|
||||||
- metadata:
|
|
||||||
- labels:
|
|
||||||
- app.oam.dev/appRevision: ""
|
|
||||||
- app.oam.dev/component: express-server
|
|
||||||
- app.oam.dev/name: vela-app
|
|
||||||
- trait.oam.dev/resource: service
|
|
||||||
- trait.oam.dev/type: ingress
|
|
||||||
- name: express-server
|
|
||||||
- spec:
|
|
||||||
- ports:
|
|
||||||
- - port: 8000
|
|
||||||
- targetPort: 8000
|
|
||||||
- selector:
|
|
||||||
- app.oam.dev/component: express-server
|
|
||||||
|
|
||||||
---
|
|
||||||
### Component (express-server) / Trait (ingress/ingress) has been removed(-)
|
|
||||||
---
|
|
||||||
- apiVersion: networking.k8s.io/v1beta1
|
|
||||||
- kind: Ingress
|
|
||||||
- metadata:
|
|
||||||
- labels:
|
|
||||||
- app.oam.dev/appRevision: ""
|
|
||||||
- app.oam.dev/component: express-server
|
|
||||||
- app.oam.dev/name: vela-app
|
|
||||||
- trait.oam.dev/resource: ingress
|
|
||||||
- trait.oam.dev/type: ingress
|
|
||||||
- name: express-server
|
|
||||||
- spec:
|
|
||||||
- rules:
|
|
||||||
- - host: testsvc.example.com
|
|
||||||
- http:
|
|
||||||
- paths:
|
|
||||||
- - backend:
|
|
||||||
- serviceName: express-server
|
|
||||||
- servicePort: 8000
|
|
||||||
- path: /
|
|
||||||
|
|
||||||
---
|
|
||||||
## Component (my-task) has been added(+)
|
|
||||||
---
|
|
||||||
+ apiVersion: core.oam.dev/v1alpha2
|
|
||||||
+ kind: Component
|
|
||||||
+ metadata:
|
|
||||||
+ creationTimestamp: null
|
|
||||||
+ labels:
|
|
||||||
+ app.oam.dev/name: vela-app
|
|
||||||
+ name: my-task
|
|
||||||
+ spec:
|
|
||||||
+ workload:
|
|
||||||
+ apiVersion: batch/v1
|
|
||||||
+ kind: Job
|
|
||||||
+ metadata:
|
|
||||||
+ labels:
|
|
||||||
+ app.oam.dev/appRevision: ""
|
|
||||||
+ app.oam.dev/component: my-task
|
|
||||||
+ app.oam.dev/name: vela-app
|
|
||||||
+ workload.oam.dev/type: task
|
|
||||||
+ spec:
|
|
||||||
+ completions: 1
|
|
||||||
+ parallelism: 1
|
|
||||||
+ template:
|
|
||||||
+ spec:
|
|
||||||
+ containers:
|
|
||||||
+ - command:
|
|
||||||
+ - sleep
|
|
||||||
+ - "1000"
|
|
||||||
+ image: busybox
|
|
||||||
+ name: my-task
|
|
||||||
+ restartPolicy: Never
|
|
||||||
+ status:
|
|
||||||
+ observedGeneration: 0
|
|
||||||
|
|
||||||
---
|
|
||||||
### Component (my-task) / Trait (ingress/service) has been added(+)
|
|
||||||
---
|
|
||||||
+ apiVersion: v1
|
|
||||||
+ kind: Service
|
|
||||||
+ metadata:
|
|
||||||
+ labels:
|
|
||||||
+ app.oam.dev/appRevision: ""
|
|
||||||
+ app.oam.dev/component: my-task
|
|
||||||
+ app.oam.dev/name: vela-app
|
|
||||||
+ trait.oam.dev/resource: service
|
|
||||||
+ trait.oam.dev/type: ingress
|
|
||||||
+ name: my-task
|
|
||||||
+ spec:
|
|
||||||
+ ports:
|
|
||||||
+ - port: 8080
|
|
||||||
+ targetPort: 8080
|
|
||||||
+ selector:
|
|
||||||
+ app.oam.dev/component: my-task
|
|
||||||
|
|
||||||
---
|
|
||||||
### Component (my-task) / Trait (ingress/ingress) has been added(+)
|
|
||||||
---
|
|
||||||
+ apiVersion: networking.k8s.io/v1beta1
|
|
||||||
+ kind: Ingress
|
|
||||||
+ metadata:
|
|
||||||
+ labels:
|
|
||||||
+ app.oam.dev/appRevision: ""
|
|
||||||
+ app.oam.dev/component: my-task
|
|
||||||
+ app.oam.dev/name: vela-app
|
|
||||||
+ trait.oam.dev/resource: ingress
|
|
||||||
+ trait.oam.dev/type: ingress
|
|
||||||
+ name: my-task
|
|
||||||
+ spec:
|
|
||||||
+ rules:
|
|
||||||
+ - host: testsvc.example.com
|
|
||||||
+ http:
|
|
||||||
+ paths:
|
|
||||||
+ - backend:
|
|
||||||
+ serviceName: my-task
|
|
||||||
+ servicePort: 8080
|
|
||||||
+ path: /
|
|
||||||
```
|
|
||||||
|
|
||||||
</details>
|
|
||||||
|
|
@ -0,0 +1,5 @@
|
||||||
|
---
|
||||||
|
title: 本地试运行
|
||||||
|
---
|
||||||
|
|
||||||
|
|
||||||
|
|
@ -1,10 +1,10 @@
|
||||||
---
|
---
|
||||||
title: 聚合健康探针
|
title: 部署状态查看
|
||||||
---
|
---
|
||||||
|
|
||||||
`HealthyScope` 允许您为同一应用程序中的所有组件定义一个聚合的健康探测器。
|
The `HealthyScope` allows you to define an aggregated health probe for all components in same application.
|
||||||
|
|
||||||
1. 创建健康范围实例。
|
1.Create health scope instance.
|
||||||
```yaml
|
```yaml
|
||||||
apiVersion: core.oam.dev/v1alpha2
|
apiVersion: core.oam.dev/v1alpha2
|
||||||
kind: HealthScope
|
kind: HealthScope
|
||||||
|
|
@ -18,7 +18,7 @@ spec:
|
||||||
kind: Deployment
|
kind: Deployment
|
||||||
name: express-server
|
name: express-server
|
||||||
```
|
```
|
||||||
2. 创建落入此运行状况范围内的应用程序。
|
2. Create an application that drops in this health scope.
|
||||||
```yaml
|
```yaml
|
||||||
apiVersion: core.oam.dev/v1beta1
|
apiVersion: core.oam.dev/v1beta1
|
||||||
kind: Application
|
kind: Application
|
||||||
|
|
@ -35,7 +35,7 @@ spec:
|
||||||
scopes:
|
scopes:
|
||||||
healthscopes.core.oam.dev: health-check
|
healthscopes.core.oam.dev: health-check
|
||||||
```
|
```
|
||||||
3. 检查聚合健康探针的引用（`status.service.scopes`）。
|
3. Check the reference of the aggregated health probe (`status.service.scopes`).
|
||||||
```shell
|
```shell
|
||||||
kubectl get app vela-app -o yaml
|
kubectl get app vela-app -o yaml
|
||||||
```
|
```
|
||||||
|
|
@ -55,7 +55,7 @@ status:
|
||||||
kind: HealthScope
|
kind: HealthScope
|
||||||
name: health-check
|
name: health-check
|
||||||
```
|
```
|
||||||
4. 检查健康范围详细信息。
|
4.Check health scope detail.
|
||||||
```shell
|
```shell
|
||||||
kubectl get healthscope health-check -o yaml
|
kubectl get healthscope health-check -o yaml
|
||||||
```
|
```
|
||||||
|
|
@ -86,4 +86,4 @@ status:
|
||||||
total: 1
|
total: 1
|
||||||
```
|
```
|
||||||
|
|
||||||
它显示了此应用程序中所有组件的汇总运行状况。
|
It shows the aggregated health status for all components in this application.
|
||||||
|
|
@ -0,0 +1,4 @@
|
||||||
|
---
|
||||||
|
title: 版本对比
|
||||||
|
---
|
||||||
|
|
||||||
|
|
@ -0,0 +1,4 @@
|
||||||
|
---
|
||||||
|
title: 查看监控
|
||||||
|
---
|
||||||
|
|
||||||
|
|
@ -0,0 +1,5 @@
|
||||||
|
---
|
||||||
|
title: 管理交付环境
|
||||||
|
---
|
||||||
|
|
||||||
|
TBD
|
||||||
|
|
@ -1,8 +1,8 @@
|
||||||
---
|
---
|
||||||
title: Progressive Rollout RoadMap
|
title: 概述
|
||||||
---
|
---
|
||||||
|
|
||||||
Here are some working items on the roadmap
|
Here are some workitems on the roadmap
|
||||||
|
|
||||||
## Embed rollout in an application
|
## Embed rollout in an application
|
||||||
|
|
||||||
|
|
@ -1,67 +0,0 @@
|
||||||
---
|
|
||||||
title: Rollout Plan
|
|
||||||
---
|
|
||||||
在本文档中，我们将展示如何使用推出计划来滚动更新应用程序。
|
|
||||||
|
|
||||||
## 概述
|
|
||||||
|
|
||||||
默认情况下，当我们更新应用程序的属性时，KubeVela 会直接更新底层实例。 应用程序的可用性将通过 rollout trait（如果有）来保证。
|
|
||||||
|
|
||||||
虽然 KubeVela 也提供了滚动样式更新机制，但您可以在应用程序中指定`spec.rolloutPlan` 来实现。
|
|
||||||
|
|
||||||
## 例子
|
|
||||||
|
|
||||||
1. 将应用程序部署到集群
|
|
||||||
```yaml
|
|
||||||
apiVersion: core.oam.dev/v1beta1
|
|
||||||
kind: Application
|
|
||||||
metadata:
|
|
||||||
name: test-rolling
|
|
||||||
spec:
|
|
||||||
components:
|
|
||||||
- name: metrics-provider
|
|
||||||
type: worker
|
|
||||||
properties:
|
|
||||||
cmd:
|
|
||||||
- ./podinfo
|
|
||||||
- stress-cpu=1.0
|
|
||||||
image: stefanprodan/podinfo:4.0.6
|
|
||||||
port: 8080
|
|
||||||
rolloutPlan:
|
|
||||||
rolloutStrategy: "IncreaseFirst"
|
|
||||||
rolloutBatches:
|
|
||||||
- replicas: 50%
|
|
||||||
- replicas: 50%
|
|
||||||
targetSize: 6
|
|
||||||
```
|
|
||||||
|
|
||||||
2. 用户可以修改应用容器命令并申请
|
|
||||||
```yaml
|
|
||||||
apiVersion: core.oam.dev/v1beta1
|
|
||||||
kind: Application
|
|
||||||
metadata:
|
|
||||||
name: test-rolling
|
|
||||||
spec:
|
|
||||||
components:
|
|
||||||
- name: metrics-provider
|
|
||||||
type: worker
|
|
||||||
properties:
|
|
||||||
cmd:
|
|
||||||
- ./podinfo
|
|
||||||
- stress-cpu=2.0
|
|
||||||
image: stefanprodan/podinfo:4.0.6
|
|
||||||
port: 8080
|
|
||||||
rolloutPlan:
|
|
||||||
rolloutStrategy: "IncreaseFirst"
|
|
||||||
rolloutBatches:
|
|
||||||
- replicas: 50%
|
|
||||||
- replicas: 50%
|
|
||||||
targetSize: 6
|
|
||||||
```
|
|
||||||
|
|
||||||
用户可以检查应用程序的状态并看到部署完成，以及应用程序的 `status.rollout.rollingState` 变为 `rolloutSucceed`。
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
@ -1,11 +1,11 @@
|
||||||
---
|
---
|
||||||
title: 使用 Labels and Annotations
|
title: 组件标签
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|
||||||
## 列出 trait
|
## 列出 trait
|
||||||
|
|
||||||
`label` 和 `annotations` trait 允许您将标签和注释附加到组件。
|
`label` 和 `annotations` trait 允许你将标签和注释附加到组件。
|
||||||
|
|
||||||
```shell
|
```shell
|
||||||
# myapp.yaml
|
# myapp.yaml
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,5 @@
|
||||||
|
---
|
||||||
|
title: 自动扩缩容
|
||||||
|
---
|
||||||
|
|
||||||
|
TBD
|
||||||
|
|
@ -1,8 +1,8 @@
|
||||||
---
|
---
|
||||||
title: 使用 Ingress
|
title: 配置网关
|
||||||
---
|
---
|
||||||
|
|
||||||
> ⚠️ 本节要求您的运行时集群有一个有效的 ingress 控制器。
|
> ⚠️ 本节要求你的运行时集群有一个有效的 ingress 控制器。
|
||||||
|
|
||||||
`ingress` trait 通过有效域将组件暴露给公共 Internet。
|
`ingress` trait 通过有效域将组件暴露给公共 Internet。
|
||||||
|
|
||||||
|
|
@ -84,7 +84,7 @@ spec:
|
||||||
...
|
...
|
||||||
```
|
```
|
||||||
|
|
||||||
然后您将能够通过其域访问该应用程序。
|
然后你将能够通过其域访问该应用程序。
|
||||||
|
|
||||||
```
|
```
|
||||||
curl -H "Host:testsvc.example.com" http://<your ip address>/
|
curl -H "Host:testsvc.example.com" http://<your ip address>/
|
||||||
|
|
|
||||||
|
|
@ -67,4 +67,4 @@ backend 1/1 1 1 19h
|
||||||
frontend 2/2 2 2 19h
|
frontend 2/2 2 2 19h
|
||||||
```
|
```
|
||||||
|
|
||||||
要扩容或缩容，您只需要修改`scaler` trait 的`replicas` 字段并重新应用YAML。
|
要扩容或缩容，你只需要修改`scaler` trait 的`replicas` 字段并重新应用YAML。
|
||||||
|
|
@ -1,5 +1,5 @@
|
||||||
---
|
---
|
||||||
title: Metrics
|
title: 日志监控
|
||||||
---
|
---
|
||||||
|
|
||||||
## 描述
|
## 描述
|
||||||
|
|
|
||||||
|
|
@ -6,9 +6,9 @@ KubeVela 中的 Traits 被设计为模块化的构建块，它们是完全可定
|
||||||
|
|
||||||
## 1. 从能力中心获取
|
## 1. 从能力中心获取
|
||||||
|
|
||||||
KubeVela 允许您探索由平台团队维护的功能。 kubectl vela 中有两个命令插件：`comp` 和`trait`。
|
KubeVela 允许你探索由平台团队维护的功能。 kubectl vela 中有两个命令插件：`comp` 和`trait`。
|
||||||
|
|
||||||
<!-- 如果您尚未安装 kubectl vela 插件：请参阅 [这里](../../developers/references/kubectl-plugin#install-kubectl-vela-plugin)。 -->
|
<!-- 如果你尚未安装 kubectl vela 插件：请参阅 [这里](../../developers/references/kubectl-plugin#install-kubectl-vela-plugin)。 -->
|
||||||
|
|
||||||
### 1. 列表
|
### 1. 列表
|
||||||
|
|
||||||
|
|
@ -53,5 +53,5 @@ init-container ["webservice","worker"] add an init container with a shared v
|
||||||
|
|
||||||
## 2. 自己设计
|
## 2. 自己设计
|
||||||
|
|
||||||
查看 [本文档](../../platform-engineers/cue/trait) 了解如何在
|
查看 [本文档](../../platform-engineers/traits/trait) 了解如何在
|
||||||
KubeVela 平台。
|
KubeVela 平台。
|
||||||
|
|
@ -1,5 +1,5 @@
|
||||||
---
|
---
|
||||||
title: 使用 Service Binding
|
title: 云资源绑定
|
||||||
---
|
---
|
||||||
|
|
||||||
## 定义
|
## 定义
|
||||||
|
|
|
||||||
|
|
@ -1,5 +1,5 @@
|
||||||
---
|
---
|
||||||
title: 使用 Sidecar
|
title: 容器注入
|
||||||
---
|
---
|
||||||
|
|
||||||
在本章节中，我们会展示如何使用 `sidecar` trait 来收集日志。
|
在本章节中，我们会展示如何使用 `sidecar` trait 来收集日志。
|
||||||
|
|
|
||||||
|
|
@ -1,11 +1,11 @@
|
||||||
---
|
---
|
||||||
title: 使用 Cloud Volumes
|
title: 数据持久化
|
||||||
---
|
---
|
||||||
|
|
||||||
本节介绍如何将 Cloud Volumes 附加到组件。 例如，AWS ElasticBlockStore、
|
本节介绍如何将 Cloud Volumes 附加到组件。 例如，AWS ElasticBlockStore、
|
||||||
Azure Disk、阿里云OSS等。
|
Azure Disk、阿里云OSS等。
|
||||||
|
|
||||||
云卷不是 KubeVela 中的内置功能，因此您需要先启用这些特性。 让我们以 AWS EBS 为例。
|
云卷不是 KubeVela 中的内置功能，因此你需要先启用这些特性。 让我们以 AWS EBS 为例。
|
||||||
|
|
||||||
安装并检查 AWS EBS volume 特征的 `TraitDefinition`。
|
安装并检查 AWS EBS volume 特征的 `TraitDefinition`。
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,3 @@
|
||||||
|
---
|
||||||
|
title: 交付工作流
|
||||||
|
---
|
||||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue