kubevela
/
kubevela.github.io
mirror of https://github.com/kubevela/kubevela.github.io.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Revert "sync commit 89d8e37c7c11abc0e98fffd1338d25748e9ca0a9 from kubevela-refs/heads/release-1.0" 

This reverts commit 431bbb6131.
This commit is contained in:
yangsoon 2021-07-02 14:09:12 +08:00
parent 431bbb6131
commit 9d784760da
203 changed files with 12847 additions and 363 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

39
docs/advanced-install.md → docs/advanced-install.mdx
View File

@ -1,6 +1,8 @@
---
title: Other Install Topics
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
## Install KubeVela with cert-manager
@ -47,7 +49,44 @@ REVISION: 1
NOTES:
Welcome to use the KubeVela! Enjoy your shipping application journey!
```
## Install Kubectl Vela Plugin
Install vela kubectl plugin can help you to ship applications more easily!
<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>
For more usage please reference [kubectl plugin](./developers/references/kubectl-plugin).
## Upgrade
### Step 1. Update Helm repo

4
docs/cli/vela_cap_center_config.md
View File

@ -15,7 +15,7 @@ vela cap center config <centerName> <centerURL> [flags]
### Examples
```
vela cap center config mycenter https://github.com/oam-dev/catalog/cap-center
vela cap center config mycenter https://github.com/oam-dev/catalog/tree/master/registry
```
### Options
@ -35,4 +35,4 @@ vela cap center config mycenter https://github.com/oam-dev/catalog/cap-center
* [vela cap center](vela_cap_center) - Manage Capability Center
###### Auto generated by spf13/cobra on 20-Mar-2021
###### Auto generated by spf13/cobra on 6-May-2021

1
docs/concepts.md
View File

@ -43,5 +43,4 @@ Before releasing an application to production, it's important to test the code i
Here are some recommended next steps:
- Learn KubeVela's [core concepts](./concepts)
- Learn how to [deploy an application](end-user/application) in detail and understand how it works.

43
docs/developers/cap-center.md
View File

@ -11,11 +11,16 @@ KubeVela is able to discover OAM definition files in this repo automatically and
Add and sync a capability center in KubeVela:
```bash
$ vela cap center config my-center https://github.com/oam-dev/catalog/tree/master/registry
vela cap center config my-center https://github.com/oam-dev/catalog/tree/master/registry
```
```console
successfully sync 1/1 from my-center remote center
Successfully configured capability center my-center and sync from remote
$ vela cap center sync my-center
```
```bash
vela cap center sync my-center
```
```console
successfully sync 1/1 from my-center remote center
sync finished
```
@ -27,7 +32,9 @@ Now, this capability center `my-center` is ready to use.
You are allowed to add more capability centers and list them.
```bash
$ vela cap center ls
vela cap center ls
```
```console
NAME ADDRESS
my-center https://github.com/oam-dev/catalog/tree/master/registry
```
@ -37,7 +44,7 @@ my-center https://github.com/oam-dev/catalog/tree/master/registry
Or, remove one.
```bash
$ vela cap center remove my-center
vela cap center remove my-center
```
## List all available capabilities in capability center
@ -45,7 +52,9 @@ $ vela cap center remove my-center
Or, list all available capabilities in certain center.
```bash
$ vela cap ls my-center
vela cap ls my-center
```
```console
NAME CENTER TYPE DEFINITION STATUS APPLIES-TO
clonesetservice my-center componentDefinition clonesets.apps.kruise.io uninstalled []
```
@ -63,7 +72,9 @@ helm install kruise https://github.com/openkruise/kruise/releases/download/v0.7.
Install `clonesetservice` component from `my-center`.
```bash
$ vela cap install my-center/clonesetservice
vela cap install my-center/clonesetservice
```
```console
Installing component capability clonesetservice
Successfully installed capability clonesetservice from my-center
```
@ -73,7 +84,9 @@ Successfully installed capability clonesetservice from my-center
Let's check the `clonesetservice` appears in your platform firstly:
```bash
$ vela components
vela components
```
```console
NAME NAMESPACE WORKLOAD DESCRIPTION
clonesetservice vela-system clonesets.apps.kruise.io Describes long-running, scalable, containerized services
that have a stable network endpoint to receive external
@ -85,7 +98,7 @@ clonesetservice vela-system clonesets.apps.kruise.io Describes long-running, sca
Great! Now let's deploy an app via Appfile.
```bash
$ cat << EOF > vela.yaml
cat << EOF > vela.yaml
name: testapp
services:
testsvc:
@ -96,7 +109,9 @@ EOF
```
```bash
$ vela up
vela up
```
```console
Parsing vela appfile ...
Load Template ...
@ -118,7 +133,9 @@ Updating: core.oam.dev/v1alpha2, Kind=HealthScope in default
then you can Get a cloneset in your environment.
```shell
$ kubectl get clonesets.apps.kruise.io
kubectl get clonesets.apps.kruise.io
```
```console
NAME DESIRED UPDATED UPDATED_READY READY TOTAL AGE
testsvc 1 1 1 1 1 46s
```
@ -128,6 +145,8 @@ testsvc 1 1 1 1 1 46s
> NOTE: make sure no apps are using the capability before uninstalling.
```bash
$ vela cap uninstall my-center/clonesetservice
vela cap uninstall my-center/clonesetservice
```
```console
Successfully uninstalled capability clonesetservice
```

2
docs/developers/check-logs.md
View File

@ -3,7 +3,7 @@ title: Check Application Logs
---
```bash
$ vela logs testapp
vela logs testapp
```
It will let you select the container to get logs from. If there is only one container it will select automatically.

30
docs/developers/config-app.md
View File

@ -7,7 +7,9 @@ title: Configuring data/env in Application
## `vela config set`
```bash
$ vela config set test a=b c=d
vela config set test a=b c=d
```
```console
reading existing config data and merging with user input
config data saved successfully ✅
```
@ -15,7 +17,9 @@ config data saved successfully ✅
## `vela config get`
```bash
$ vela config get test
vela config get test
```
```console
Data:
a: b
c: d
@ -24,16 +28,20 @@ Data:
## `vela config del`
```bash
$ vela config del test
vela config del test
```
```console
config (test) deleted successfully
```
## `vela config ls`
```bash
$ vela config set test a=b
$ vela config set test2 c=d
$ vela config ls
vela config set test a=b
vela config set test2 c=d
vela config ls
```
```console
NAME
test
test2
@ -44,7 +52,7 @@ test2
The config data can be set as the env in applications.
```bash
$ vela config set demo DEMO_HELLO=helloworld
vela config set demo DEMO_HELLO=helloworld
```
Save the following to `vela.yaml` in current directory:
@ -59,7 +67,9 @@ services:
Then run:
```bash
$ vela up
vela up
```
```console
Parsing vela.yaml ...
Loading templates ...
@ -80,6 +90,8 @@ App has not been deployed, creating a new deployment...
Check env var:
```
$ vela exec testapp -- printenv | grep DEMO_HELLO
vela exec testapp -- printenv | grep DEMO_HELLO
```
```console
DEMO_HELLO=helloworld
```

28
docs/developers/config-enviroments.md
View File

@ -8,14 +8,18 @@ A typical set of deployment environment is `test`, `staging`, `prod`, etc.
## Create environment
```bash
$ vela env init demo --email my@email.com
vela env init demo --email my@email.com
```
```console
environment demo created, Namespace: default, Email: my@email.com
```
## Check the deployment environment metadata
```bash
$ vela env ls
vela env ls
```
```console
NAME CURRENT NAMESPACE EMAIL DOMAIN
default default
demo * default my@email.com
@ -28,12 +32,16 @@ By default, the environment will use `default` namespace in K8s.
You could change the config by executing the environment again.
```bash
$ vela env init demo --namespace demo
vela env init demo --namespace demo
```
```console
environment demo created, Namespace: demo, Email: my@email.com
```
```bash
$ vela env ls
vela env ls
```
```console
NAME CURRENT NAMESPACE EMAIL DOMAIN
default default
demo * demo my@email.com
@ -50,7 +58,9 @@ your app by this domain with an mTLS supported automatically.
For example, you could get the public IP from ingress service.
```bash
$ kubectl get svc -A | grep LoadBalancer
kubectl get svc -A | grep LoadBalancer
```
```console
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx-ingress-lb LoadBalancer 172.21.2.174 123.57.10.233 80:32740/TCP,443:32086/TCP 41d
```
@ -66,7 +76,9 @@ You could also use `123.57.10.233.xip.io` as your domain, if you don't have a cu
```bash
$ vela env init demo --domain 123.57.10.233.xip.io
vela env init demo --domain 123.57.10.233.xip.io
```
```console
environment demo updated, Namespace: demo, Email: my@email.com
```
@ -87,7 +99,9 @@ servcies:
```
```
$ curl http://123.57.10.233.xip.io/testapp
curl http://123.57.10.233.xip.io/testapp
```
```console
Hello World
```

2
docs/developers/exec-cmd.md
View File

@ -4,7 +4,7 @@ title: Execute Commands in Container
Run:
```
$ vela exec testapp -- /bin/sh
vela exec testapp -- /bin/sh
```
This open a shell within the container of testapp.

16
docs/developers/learn-appfile.md
View File

@ -88,8 +88,8 @@ In the following workflow, we will build and deploy an example NodeJS app under
git clone and go to the testapp directory:
```bash
$ git clone https://github.com/oam-dev/kubevela.git
$ cd kubevela/docs/examples/testapp
git clone https://github.com/oam-dev/kubevela.git
cd kubevela/docs/examples/testapp
```
The example contains NodeJS app code, Dockerfile to build the app.
@ -108,7 +108,9 @@ We are going to use it to build and deploy the app.
Run the following command:
```bash
$ vela up
vela up
```
```console
Parsing vela.yaml ...
Loading templates ...
@ -139,7 +141,9 @@ App has not been deployed, creating a new deployment...
Check the status of the service:
```bash
$ vela status testapp
vela status testapp
```
```console
About:
Name: testapp
@ -179,7 +183,7 @@ Add local option to `build`:
Then deploy the app to kind:
```bash
$ vela up
vela up
```
<details><summary>(Advanced) Check rendered manifests</summary>
@ -237,7 +241,7 @@ services:
Then deploy Appfile again to update the application:
```bash
$ vela up
vela up
```
Congratulations! You have just deployed an app using `Appfile`.

10
docs/developers/port-forward.md
View File

@ -5,7 +5,9 @@ title: Port Forwarding
Once your web services of the application deployed, you can access it locally via `port-forward`.
```bash
$ vela ls
vela ls
```
```console
NAME APP WORKLOAD TRAITS STATUS CREATED-TIME
express-server testapp webservice Deployed 2020-09-18 22:42:04 +0800 CST
```
@ -13,11 +15,13 @@ express-server testapp webservice Deployed 2020-09-18 22:42:04 +0800
It will directly open browser for you.
```bash
$ vela port-forward testapp
vela port-forward testapp
```
```console
Forwarding from 127.0.0.1:8080 -> 80
Forwarding from [::1]:8080 -> 80
Forward successfully! Opening browser ...
Handling connection for 8080
Handling connection for 8080
```
```

77
docs/developers/references/devex/faq.md
View File

@ -30,7 +30,9 @@ Also, KubeVela is by design a Kubernetes controller (i.e. works on server side),
Occasionally you might hit the issue as below. It happens when the last KubeVela release deletion hasn't completed.
```
$ vela install
vela install
```
```console
- Installing Vela Core Chart:
install chart vela-core, version 0.1.0, desc : A Helm chart for Kube Vela core, contains 35 file
Failed to install the chart with error: serviceaccounts "cert-manager-cainjector" is forbidden: unable to create new content in namespace cert-manager because it is being terminated
@ -44,7 +46,9 @@ Error: failed to create resource: serviceaccounts "cert-manager-cainjector" is f
Take a break and try again in a few seconds.
```
$ vela install
vela install
```
```console
- Installing Vela Core Chart:
Vela system along with OAM runtime already exist.
Automatically discover capabilities successfully ✅ Add(0) Update(0) Delete(8)
@ -65,7 +69,9 @@ TYPE CATEGORY DESCRIPTION
And manually apply all WorkloadDefinition and TraitDefinition manifests to have all capabilities back.
```
$ kubectl apply -f charts/vela-core/templates/defwithtemplate
kubectl apply -f charts/vela-core/templates/defwithtemplate
```
```console
traitdefinition.core.oam.dev/autoscale created
traitdefinition.core.oam.dev/scaler created
traitdefinition.core.oam.dev/metrics created
@ -74,8 +80,11 @@ traitdefinition.core.oam.dev/route created
workloaddefinition.core.oam.dev/task created
workloaddefinition.core.oam.dev/webservice created
workloaddefinition.core.oam.dev/worker created
$ vela workloads
```
```
vela workloads
```
```console
Automatically discover capabilities successfully ✅ Add(8) Update(0) Delete(0)
TYPE CATEGORY DESCRIPTION
@ -99,7 +108,9 @@ worker Long-running scalable backend worker without network endpoint
Occasionally you might hit the issue as below. It happens when there is an old OAM Kubernetes Runtime release, or you applied `ScopeDefinition` before.
```
$ vela install
vela install
```
```console
- Installing Vela Core Chart:
install chart vela-core, version 0.1.0, desc : A Helm chart for Kube Vela core, contains 35 file
Failed to install the chart with error: ScopeDefinition "healthscopes.core.oam.dev" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; annotation validation error: key "meta.helm.sh/release-name" must equal "kubevela": current value is "oam"; annotation validation error: key "meta.helm.sh/release-namespace" must equal "vela-system": current value is "oam-system"
@ -113,10 +124,15 @@ $ vela install
Delete `ScopeDefinition` "healthscopes.core.oam.dev" and try again.
```
$ kubectl delete ScopeDefinition "healthscopes.core.oam.dev"
kubectl delete ScopeDefinition "healthscopes.core.oam.dev"
```
```console
scopedefinition.core.oam.dev "healthscopes.core.oam.dev" deleted
$ vela install
```
```
vela install
```
```console
- Installing Vela Core Chart:
install chart vela-core, version 0.1.0, desc : A Helm chart for Kube Vela core, contains 35 file
Successfully installed the chart, status: deployed, last deployed time = 2020-12-03 16:26:41.491426 +0800 CST m=+4.026069452
@ -141,7 +157,9 @@ TYPE CATEGORY DESCRIPTION
When you look into the logs of Pod kubevela-vela-core and found the issue as below.
```
$ kubectl get pod -n vela-system -l app.kubernetes.io/name=vela-core
kubectl get pod -n vela-system -l app.kubernetes.io/name=vela-core
```
```console
NAME READY STATUS RESTARTS AGE
kubevela-vela-core-f8b987775-wjg25 0/1 - 0 35m
```
@ -152,7 +170,7 @@ kubevela-vela-core-f8b987775-wjg25 0/1 - 0 35m
You can use github container registry instead.
```
$ docker pull ghcr.io/oam-dev/kubevela/vela-core:latest
docker pull ghcr.io/oam-dev/kubevela/vela-core:latest
```
### Warning: Namespace cert-manager exists
@ -161,7 +179,9 @@ If you hit the issue as below, an `cert-manager` release might exist whose names
with KubeVela.
```
$ vela install
vela install
```
```console
- Installing Vela Core Chart:
install chart vela-core, version 0.1.0, desc : A Helm chart for Kube Vela core, contains 35 file
Failed to install the chart with error: Namespace "cert-manager" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; label validation error: missing key "app.kubernetes.io/managed-by": must be set to "Helm"; annotation validation error: missing key "meta.helm.sh/release-name": must be set to "kubevela"; annotation validation error: missing key "meta.helm.sh/release-namespace": must be set to "vela-system"
@ -180,13 +200,21 @@ Try these steps to fix the problem.
- Install KubeVela again
```
$ helm delete cert-manager -n cert-manager
helm delete cert-manager -n cert-manager
```
```console
release "cert-manager" uninstalled
$ kubectl delete ns cert-manager
```
```
kubectl delete ns cert-manager
```
```console
namespace "cert-manager" deleted
$ vela install
```
```
vela install
```
```console
- Installing Vela Core Chart:
install chart vela-core, version 0.1.0, desc : A Helm chart for Kube Vela core, contains 35 file
Successfully installed the chart, status: deployed, last deployed time = 2020-12-04 10:46:46.782617 +0800 CST m=+4.248889379
@ -249,12 +277,17 @@ is enabled with command `kubectl top nodes` or `kubectl top pods`.
If the output is similar as below, the metrics is enabled.
```shell
$ kubectl top nodes
kubectl top nodes
```
```console
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
cn-hongkong.10.0.1.237 288m 7% 5378Mi 78%
cn-hongkong.10.0.1.238 351m 8% 5113Mi 74%
$ kubectl top pods
```
```
kubectl top pods
```
```console
NAME CPU(cores) MEMORY(bytes)
php-apache-65f444bf84-cjbs5 0m 1Mi
wordpress-55c59ccdd5-lf59d 1m 66Mi
@ -279,7 +312,7 @@ Please refer to [metrics server debug guide](https://help.aliyun.com/document_de
Install metrics server as below, or you can install the [latest version](https://github.com/kubernetes-sigs/metrics-server#installation).
```shell
$ kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.3.7/components.yaml
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.3.7/components.yaml
```
Also add the following part under `.spec.template.spec.containers` in the yaml file loaded by `kubectl edit deploy -n kube-system metrics-server`.
@ -297,7 +330,7 @@ command:
Enable it with following command.
```shell
$ minikube addons enable metrics-server
minikube addons enable metrics-server
```

41
docs/developers/references/kubectl-plugin.mdx Normal file
View File

@ -0,0 +1,41 @@
---
title: 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
See [advanced-install](../../advanced-install#install-kubectl-vela-plugin)
## 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:
comp Show components in capability registry
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
trait Show traits in capability registry
version Prints out build version information
Flags:
-h, --help help for vela
Use "kubectl vela [command] --help" for more information about a command.
```

30
docs/end-user/application.md
View File

@ -14,6 +14,8 @@ 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.
@ -23,7 +25,9 @@ worker Deployment Describes long-running, scalable, containerize
To show the specification for given component, you could use `vela show`.
```shell
$ kubectl vela show webservice
kubectl vela show webservice
```
```console
# Properties
+------------------+----------------------------------------------------------------------------------+-----------------------+----------+---------+
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
@ -73,7 +77,9 @@ spec:
Traits are platform provided features that could *overlay* a given component with extra operational behaviors.
```shell
$ kubectl get trait -n vela-system
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.
@ -84,7 +90,9 @@ sidecar [webservice worker] Inject a sideca
Let's check the specification of `sidecar` trait.
```shell
$ kubectl vela show sidecar
kubectl vela show sidecar
```
```console
# Properties
+---------+-----------------------------------------+----------+----------+---------+
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
@ -137,14 +145,18 @@ spec:
## Step 4: Deploy the Application
```shell
$ kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/docs/examples/enduser/sample.yaml
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
kubectl get application
```
```console
NAME COMPONENT TYPE PHASE HEALTHY STATUS AGE
website frontend webservice running true 4m54s
```
@ -152,7 +164,9 @@ website frontend webservice running true 4m54s
Check the details of the application.
```shell
$ kubectl get app website -o yaml
kubectl get app website -o yaml
```
```console
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
@ -212,7 +226,9 @@ Specifically:
When updating an application entity, KubeVela will create a new revision for this change.
```shell
$ kubectl get apprev -l app.oam.dev/name=website
kubectl get apprev -l app.oam.dev/name=website
```
```console
NAME AGE
website-v1 35m
```

27
docs/end-user/components/cloud-services.md
View File

@ -15,7 +15,9 @@ The cloud services will be consumed by the application via [Service Binding Trai
Check the parameters of cloud resource components and trait.
```shell
$ kubectl vela show alibaba-rds
kubectl vela show alibaba-rds
```
```console
# Properties
+----------------------------+-------------------------------------------------------------------------+-----------------------------------------------------------+----------+---------+
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
@ -34,8 +36,11 @@ $ kubectl vela show alibaba-rds
| namespace | The secret namespace which the cloud resource connection will be written to | string | false | |
+-----------+-----------------------------------------------------------------------------+--------+----------+---------+
$ kubectl vela show service-binding
```
```shell
kubectl vela show service-binding
```
```console
# Properties
+-------------+------------------------------------------------+------------------+----------+---------+
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
@ -106,8 +111,9 @@ spec:
Check the parameters of cloud service component:
```shell
$ kubectl vela show alibaba-rds
kubectl vela show alibaba-rds
```
```console
# Properties
+---------------+------------------------------------------------+--------+----------+--------------------+
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
@ -172,11 +178,16 @@ spec:
Deploy and verify the application (by either provider is OK).
```shell
$ kubectl get application
kubectl get application
```
```console
NAME AGE
webapp 46m
$ kubectl port-forward deployment/express-server 80:80
```
```shell
kubectl port-forward deployment/express-server 80:80
```
```console
Forwarding from 127.0.0.1:80 -> 80
Forwarding from [::1]:80 -> 80
Handling connection for 80

42
docs/end-user/components/more.md
View File

@ -4,6 +4,48 @@ title: Want More?
Components in KubeVela are designed to be brought by users.
## 1. Get from capability center
KubeVela allows you to explore capabilities maintained by platform team.
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).
### 1. list
For example, let's try to list all available components in a registry:
```shell
$ kubectl vela comp --discover
Showing components from registry: https://registry.kubevela.net
NAME REGITSRY DEFINITION
cloneset default clonesets.apps.kruise.io
kruise-statefulset default statefulsets.apps.kruise.io
openfaas default functions.openfaas.com
````
Note that the `--discover` flag means show all components not in your cluster.
### 2. install
Then you can install a component like:
```shell
$ kubectl vela comp get cloneset
Installing component capability cloneset
Successfully install trait: cloneset
```
### 3.verify
```shell
$ kubectl get componentdefinition -n vela-system
NAME WORKLOAD-KIND DESCRIPTION
cloneset CloneSet Describes long-running, scalable, containerized services that have a stable network endpoint to receive external network traffic from customers. It was implemented by OpenKruise Cloneset.
...(other componentDefinition)
```
By default, the two commands will retrieve capabilities from [repo](https://registry.kubevela.net) maintained by KubeVela.
## 2. Designed by yourself
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.

8
docs/end-user/debug.md
View File

@ -35,6 +35,8 @@ spec:
```shell
kubectl vela dry-run -f app.yaml
```
```console
---
# Application(vela-app) -- Comopnent(express-server)
---
@ -124,7 +126,9 @@ Assume you have just deployed the application in dry-run section.
Then you can list the revisions of the Application.
```shell
$ kubectl get apprev -l app.oam.dev/name=vela-app
kubectl get apprev -l app.oam.dev/name=vela-app
```
```console
NAME AGE
vela-app-v1 50s
```
@ -373,4 +377,4 @@ while you just want to focus on the changed ones.
+ path: /
```
</details>
</details>

4
docs/end-user/scopes/health.md
View File

@ -37,7 +37,7 @@ spec:
```
3. Check the reference of the aggregated health probe (`status.service.scopes`).
```shell
$ kubectl get app vela-app -o yaml
kubectl get app vela-app -o yaml
```
```yaml
apiVersion: core.oam.dev/v1beta1
@ -57,7 +57,7 @@ status:
```
4.Check health scope detail.
```shell
$ kubectl get healthscope health-check -o yaml
kubectl get healthscope health-check -o yaml
```
```yaml
apiVersion: core.oam.dev/v1alpha2

1
docs/end-user/scopes/rollout-plan.md
View File

@ -64,3 +64,4 @@ application's `status.rollout.rollingState` becomes `rolloutSucceed`.

12
docs/end-user/traits/annotations-and-labels.md
View File

@ -38,7 +38,9 @@ kubectl apply -f myapp.yaml
On runtime cluster, check the workload has been created successfully.
```bash
$ kubectl get deployments
kubectl get deployments
```
```console
NAME READY UP-TO-DATE AVAILABLE AGE
express-server 1/1 1 1 15s
```
@ -46,13 +48,17 @@ express-server 1/1 1 1 15s
Check the `labels`.
```bash
$ kubectl get deployments express-server -o jsonpath='{.spec.template.metadata.labels}'
kubectl get deployments express-server -o jsonpath='{.spec.template.metadata.labels}'
```
```console
{"app.oam.dev/component":"express-server","release": "stable"}
```
Check the `annotations`.
```bash
$ kubectl get deployments express-server -o jsonpath='{.spec.template.metadata.annotations}'
kubectl get deployments express-server -o jsonpath='{.spec.template.metadata.annotations}'
```
```console
{"description":"web application"}
```

20
docs/end-user/traits/ingress.md
View File

@ -7,7 +7,9 @@ title: Ingress
The `ingress` trait exposes a component to public Internet via a valid domain.
```shell
$ kubectl vela show ingress
kubectl vela show ingress
```
```console
# Properties
+--------+------------------------------------------------------------------------------+----------------+----------+---------+
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
@ -41,14 +43,18 @@ spec:
```
```bash
$ kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/docs/examples/vela-app.yaml
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
```
Check the status until we see `status` is `running` and services are `healthy`:
```bash
$ kubectl get application first-vela-app -w
kubectl get application first-vela-app -w
```
```console
NAME COMPONENT TYPE PHASE HEALTHY STATUS AGE
first-vela-app express-server webservice healthChecking 14s
first-vela-app express-server webservice running true 42s
@ -57,7 +63,9 @@ first-vela-app express-server webservice running true
Check the trait detail for the its visiting url:
```shell
$ kubectl get application first-vela-app -o yaml
kubectl get application first-vela-app -o yaml
```
```console
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
@ -79,7 +87,9 @@ spec:
Then you will be able to visit this application via its domain.
```
$ curl -H "Host:testsvc.example.com" http://<your ip address>/
curl -H "Host:testsvc.example.com" http://<your ip address>/
```
```console
<xmp>
Hello World

54
docs/end-user/traits/more.md
View File

@ -4,4 +4,56 @@ title: Want More?
Traits in KubeVela are designed as modularized building blocks, they are fully customizable and pluggable.
Check [this documentation](../../platform-engineers/cue/trait) about how to design and enable your own traits in KubeVela platform.
## 1. Get from capability canter
KubeVela allows you to explore capabilities maintained by platform team. 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).
### 1. list
For example, let's try to list all available traits in registry:
```shell
$ kubectl vela trait --discover
Showing traits from registry: https://registry.kubevela.net
NAME REGISTRY DEFINITION APPLIES-TO
service-account default [webservice worker]
env default [webservice worker]
flagger-rollout default canaries.flagger.app [webservice]
init-container default [webservice worker]
keda-scaler default scaledobjects.keda.sh [deployments.apps]
metrics default metricstraits.standard.oam.dev [webservice backend task]
node-affinity default [webservice worker]
route default routes.standard.oam.dev [webservice]
virtualgroup default [webservice worker]
```
Note that the `--discover` flag means show all traits not in your cluster.
### 2. install
Then you can install a trait like:
```shell
$ kubectl vela trait get init-container
Installing component capability init-container
Successfully install trait: init-container
```
### 3.verify
```shell
$ kubectl get traitdefinition -n vela-system
NAME APPLIES-TO DESCRIPTION
init-container ["webservice","worker"] add an init container with a shared volume.
...(other trait definitions)
```
By default, the two commands will retrieve capabilities
from [repo](https://registry.kubevela.net) maintained by KubeVela.
## 2. Designed by yourself
Check [this documentation](../../platform-engineers/cue/trait) about how to design and enable your own traits in
KubeVela platform.

14
docs/end-user/traits/scaler.md
View File

@ -5,7 +5,9 @@ title: Manual Scaling
The `scaler` trait allows you to scale your component instance manually.
```shell
$ kubectl vela show scaler
kubectl vela show scaler
```
```console
# Properties
+----------+--------------------------------+------+----------+---------+
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
@ -48,17 +50,21 @@ spec:
Apply the sample application:
```shell
$ kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/docs/examples/enduser/sample-manual.yaml
kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/docs/examples/enduser/sample-manual.yaml
```
```console
application.core.oam.dev/website configured
```
In runtime cluster, you can see the underlying deployment of `frontend` component has 2 replicas now.
```shell
$ kubectl get deploy -l app.oam.dev/name=website
kubectl get deploy -l app.oam.dev/name=website
```
```console
NAME READY UP-TO-DATE AVAILABLE AGE
backend 1/1 1 1 19h
frontend 2/2 2 2 19h
```
To scale up or scale down, you just need to modify the `replicas` field of `scaler` trait and re-apply the YAML.
To scale up or scale down, you just need to modify the `replicas` field of `scaler` trait and re-apply the YAML.

66
docs/end-user/traits/service-binding.md
View File

@ -2,57 +2,10 @@
title: Service Binding
---
Service binding trait will bind data from Kubernetes `Secret` to the application container's ENV.
# Description
Service binding trait will bind data from Kubernetes `Secret` to the application container's ENV.
```yaml
apiVersion: core.oam.dev/v1beta1
kind: TraitDefinition
metadata:
annotations:
definition.oam.dev/description: "binding cloud resource secrets to pod env"
name: service-binding
spec:
appliesToWorkloads:
- webservice
- worker
schematic:
cue:
template: |
patch: {
spec: template: spec: {
// +patchKey=name
containers: [{
name: context.name
// +patchKey=name
env: [
for envName, v in parameter.envMappings {
name: envName
valueFrom: {
secretKeyRef: {
name: v.secret
if v["key"] != _|_ {
key: v.key
}
if v["key"] == _|_ {
key: envName
}
}
}
},
]
}]
}
}
parameter: {
// +usage=The mapping of environment variables to secret
envMappings: [string]: [string]: string
}
```
With the help of this `service-binding` trait, you can explicitly set parameter `envMappings` to mapping all
environment names with secret key. Here is an example.
## Sample
```yaml
apiVersion: core.oam.dev/v1beta1
@ -90,3 +43,16 @@ spec:
secretName: db-conn
```
For more detailed samples, please reference to [cloud resource](../components/cloud-services)
## Specification
```console
# Properties
+-------------+------------------------------------------------+------------------+----------+---------+
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
+-------------+------------------------------------------------+------------------+----------+---------+
| envMappings | The mapping of environment variables to secret | map[string]{...} | true | |
+-------------+------------------------------------------------+------------------+----------+---------+
```

14
docs/end-user/traits/sidecar.md
View File

@ -7,7 +7,9 @@ The `sidecar` trait allows you to attach a sidecar container to the component.
## Show the Usage of Sidecar
```shell
$ kubectl vela show sidecar
kubectl vela show sidecar
```
```console
# Properties
+---------+-----------------------------------------+-----------------------+----------+---------+
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
@ -80,7 +82,9 @@ kubectl apply -f app.yaml
On runtime cluster, check the name of running pod.
```shell
$ kubectl get pod
kubectl get pod
```
```console
NAME READY STATUS RESTARTS AGE
log-gen-worker-76945f458b-k7n9k 2/2 Running 0 90s
```
@ -88,7 +92,9 @@ log-gen-worker-76945f458b-k7n9k 2/2 Running 0 90s
And check the logging output of sidecar.
```shell
$ kubectl logs -f log-gen-worker-76945f458b-k7n9k count-log
kubectl logs -f log-gen-worker-76945f458b-k7n9k count-log
```
```console
0: Fri Apr 16 11:08:45 UTC 2021
1: Fri Apr 16 11:08:46 UTC 2021
2: Fri Apr 16 11:08:47 UTC 2021
@ -99,4 +105,4 @@ $ kubectl logs -f log-gen-worker-76945f458b-k7n9k count-log
7: Fri Apr 16 11:08:52 UTC 2021
8: Fri Apr 16 11:08:53 UTC 2021
9: Fri Apr 16 11:08:54 UTC 2021
```
```

6
docs/end-user/traits/volumes.md
View File

@ -10,11 +10,13 @@ Cloud volumes are not built-in capabilities in KubeVela so you need to enable th
Install and check the `TraitDefinition` for AWS EBS volume trait.
```shell
$ kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/docs/examples/app-with-volumes/td-awsEBS.yaml
kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/docs/examples/app-with-volumes/td-awsEBS.yaml
```
```shell
$ kubectl vela show aws-ebs-volume
kubectl vela show aws-ebs-volume
```
```console
+-----------+----------------------------------------------------------------+--------+----------+---------+
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
+-----------+----------------------------------------------------------------+--------+----------+---------+

10
docs/install.mdx
View File

@ -5,7 +5,7 @@ title: Installation
import Tabs from '@theme/Tabs';
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](./advanced-install/#upgrade).
## 1. Choose Control Plane Cluster
@ -15,7 +15,7 @@ Requirements:
KubeVela relies on Kubernetes as control plane. The control plane could be any managed Kubernetes offering or your own cluster. The only requirement is please ensure [ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/) is installed and enabled.
For for local deployment and test, you could use `minikube` or `kind`.
For local deployment and test, you could use `minikube` or `kind`.
<Tabs
className="unique-tabs"
@ -82,7 +82,7 @@ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/mast
1. Add helm chart repo for KubeVela
```shell script
helm repo add kubevela https://kubevelacharts.oss-accelerate.aliyuncs.com/core
helm repo add kubevela https://charts.kubevela.net/core
```
2. Update the chart repo
@ -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 could be [installed as kubectl plugin](./kubectl-plugin.mdx), or install as standalone binary.
KubeVela CLI could be [installed as kubectl plugin](./advanced-install#install-kubectl-vela-plugin), or install as standalone binary.
<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.
> See the [advanced installation guide](./advanced-install) to learn more about installation details.
> See the [advanced installation guide](./advanced-install) to learn more about installation details.

29
docs/introduction.md
View File

@ -8,19 +8,19 @@ slug: /
## 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 hybrid environments. We’ve seen the lack of such 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 a deployment of a modern microservice application is a highly opinionated and fragmented process today. Thus, most solutions aim to solve above problem (although built with Kubernetes) are essentially restricted systems and barely extensible. As the needs of your application grow, they are almost certain to outgrow the capabilities of such systems. Application teams complain they are too rigid and slow in response to feature requests or improvements. The platform team do want to help but the engineering effort is daunting: any simple API change in the platform could easily become a marathon negotiation around the opinionated abstraction design.
On the other hand, modeling the deployment of a microservice application is a highly opinionated and fragmented process. Thus, many solutions tried to solve above problem so far essentially became restricted systems and barely extensible (regardless of whether they are built with Kubernetes or not). As the needs of your application grow, they are almost certain to outgrow the capabilities of such systems. Application teams complain they are too rigid and slow in response to feature requests or improvements. The platform team do want to help but the engineering effort is daunting: any simple change to such platform could easily become a marathon negotiation around the design of its abstraction.
## What is KubeVela?
KubeVela is a modern application platform that aims to make deploying and managing applications across hybrid, multi-cloud environments easier and faster by doing the following:
KubeVela is a modern application platform that makes deploying and managing applications across today's hybrid, multi-cloud environments easier and faster without any restriction or limitation. This is achieved by doing the following:
**Application Centric** - KubeVela introduces consistent yet application centric API to capture a full deployment of microservices on top of hybrid environments. No infrastructure level concern, simply deploy.
**Application Centric** - KubeVela introduces declarative yet higher level API (known as [OAM](https://oam.dev/)) to model a full deployment of microservices across hybrid environments in consistent approach. No infrastructure level concerns, simply deploy.
**Natively Extensible** - KubeVela uses CUE to glue capabilities provided by runtime infrastructure and expose them to users via self-service API. When users' needs grow, these API can naturally expand in programmable approach.
**Natively Extensible** - KubeVela backend is implemented with [CUE](https://cuelang.org/). Whenever your needs grow, KubeVela's capabilities can naturally expand in a IaC-style approach. No restrictions, simply programming.
**Runtime Agnostic** - KubeVela is built with Kubernetes as control plane but adaptable to any runtime as data-plane. It can deploy (and manage) diverse workload types such as container, cloud functions, databases, or even EC2 instances across hybrid environments.
**Runtime Agnostic** - KubeVela relies on Kubernetes as control plane but it's adaptable to any runtime infrastructures. It can deploy and manage diverse workload types including container, cloud functions, databases, or even EC2 instances across hybrid environments.
## Architecture
@ -30,7 +30,7 @@ The overall architecture of KubeVela is shown as below:
### Control Plane
Control plane is where KubeVela itself lives in. As the project's name implies, KubeVela by design leverages Kubernetes as control plane. This is the key of how KubeVela brings full *automation* and strong *determinism* to application delivery at scale. Users will interact with KubeVela via the application centric API to model the application deployment, and KubeVela will distribute it to target *runtime infrastructure* per policies and rules declared by users.
Control plane is where KubeVela itself lives in. As the project's name implies, KubeVela by design leverages Kubernetes as control plane. This is the key of how KubeVela guarantees full *automation* and strong *determinism* to application delivery at scale. Users will interact with KubeVela via the application centric API to model the application deployment, and KubeVela will distribute it to target *runtime infrastructure* per policies and rules declared by users.
### Runtime Infrastructures
@ -44,34 +44,31 @@ The typical examples are Heroku and Cloud Foundry. They provide full application
Though the biggest difference lies in **flexibility**.
KubeVela enables you to serve end users with programmable building blocks (based on [CUE](https://cuelang.org/)) which are fully flexible and can be extended at any time. Comparing to this mechanism, traditional PaaS systems are highly restricted, i.e. they have to enforce constraints in the type of supported applications and capabilities, and as application needs grows, you always outgrow the capabilities of the PaaS system - this will never happen in KubeVela platform.
So think of KubeVela as a Heroku but it is fully extensible when your needs grow.
KubeVela is fully programmable. All capabilities in KubeVela are LEGO-sytle CUE modules and can be extended at any time when your needs grow. Comparing to this mechanism, traditional PaaS systems are highly restricted, i.e. they have to enforce constraints in the type of supported applications and capabilities, and as application needs grows, you always outgrow the capabilities of the PaaS system - this will never happen in KubeVela platform.
### KubeVela vs. Serverless
Serverless platform such as AWS Lambda provides extraordinary user experience and agility to deploy serverless applications. However, those platforms impose even more constraints in extensibility. They are arguably "hard-coded" PaaS.
KubeVela can easily deploy both Kubernetes based serverless workloads such as Knative/OpenFaaS, or cloud functions such as AWS Lambda. Simply register what you want to deploy as a "component".
KubeVela can easily deploy both Kubernetes based serverless workloads such as Knative/OpenFaaS, or cloud based functions such as AWS Lambda.
### KubeVela vs. Platform agnostic developer tools
The typical example is Hashicorp's Waypoint. Waypoint is a developer facing tool which introduces a consistent workflow (i.e., build, deploy, release) to ship applications on top of different platforms.
KubeVela can be integrated with such tools seamlessly. In this case, developers would use the Waypoint workflow as the UI to deploy and manage applications across hybrid environments with KubeVela's abstractions (e.g. applications, components, traits etc).
KubeVela can be integrated with such tools seamlessly. In this case, developers would use the Waypoint workflow as the UI to deploy and release applications with KubeVela as the underlying deployment platform.
### KubeVela vs. Helm
Helm is a package manager for Kubernetes that provides package, install, and upgrade a set of YAML files for Kubernetes as a unit.
KubeVela as a modern deployment system can naturally deploys Helm charts across hybrid environments. For example, you could easily use KubeVela to declare and deploy an application which is composed by a WordPress Helm chart and a AWS RDS instance defined by Terraform, or distribute the Helm chart to multiple clusters.
KubeVela as a modern deployment system can naturally deploy Helm charts. For example, you could use KubeVela to define an application that is composed by a WordPress chart and a AWS RDS Terraform module, orchestrate the components' topology, and then deploy them to multiple environments following certain strategy.
KubeVela also leverages Helm to manage the capability addons in runtime clusters.
Furthermore, KubeVela also supports other encapsulation formats including Kustomize etc.
### KubeVela vs. Kubernetes
KubeVela is a Kubernetes add-on for building developer-centric deployment system. It leverages [Open Application Model](https://github.com/oam-dev/spec) and the native Kubernetes extensibility to resolve a hard problem - making shipping applications enjoyable on Kubernetes.
KubeVela is a Kubernetes add-on for building modern application deployment system. 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

75
docs/kubectl-plugin.mdx
View File

@ -1,75 +0,0 @@
---
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.
```

1
docs/platform-engineers/crossplane.md
View File

@ -9,6 +9,7 @@ These cloud services are provided by Crossplane.
## Prepare Crossplane
<details>
Please Refer to [Installation](https://github.com/crossplane/provider-alibaba/releases/tag/v0.5.0)
to install Crossplane Alibaba provider v0.5.0.

46
docs/platform-engineers/cue/basic.md
View File

@ -12,7 +12,7 @@ The reasons for KubeVela supports CUE as a first-class solution to design abstra
- **CUE is designed for large scale configuration.** CUE has the ability to understand a
configuration worked on by engineers across a whole company and to safely change a value that modifies thousands of objects in a configuration. This aligns very well with KubeVela's original goal to define and ship production level applications at web scale.
- **CUE supports first-class code generation and automation.** CUE can integrate with existing tools and workflows naturally while other tools would have to build complex custom solutions. For example, generate OpenAPI schemas wigh Go code. This is how KubeVela build developer tools and GUI interfaces based on the CUE templates.
- **CUE supports first-class code generation and automation.** CUE can integrate with existing tools and workflows naturally while other tools would have to build complex custom solutions. For example, generate OpenAPI schemas with Go code. This is how KubeVela build developer tools and GUI interfaces based on the CUE templates.
- **CUE integrates very well with Go.**
KubeVela is built with GO just like most projects in Kubernetes system. CUE is also implemented in and exposes a rich API in Go. KubeVela integrates with CUE as its core library and works as a Kubernetes controller. With the help of CUE, KubeVela can easily handle data constraint problems.
@ -57,7 +57,7 @@ CUE has powerful CLI commands. Let's keep the data in a file named `first.cue` a
cue fmt first.cue
```
* Schema Check, besides `cue fmt`, you can also use `vue vet` to check schema.
* Schema Check, besides `cue fmt`, you can also use `cue vet` to check schema.
```shell
cue vet first.cue
```
@ -66,7 +66,9 @@ CUE has powerful CLI commands. Let's keep the data in a file named `first.cue` a
You can see the results don't contain `a: float` and `b: int`, because these two variables are calculated.
While the `e: string` doesn't have definitive results, so it keeps as it is.
```shell
$ cue eval first.cue
cue eval first.cue
```
```console
a: 1.5
b: 1
d: [1, 2, 3]
@ -78,13 +80,17 @@ CUE has powerful CLI commands. Let's keep the data in a file named `first.cue` a
* Render for specified result. For example, we want only know the result of `b` in the file, then we can specify the parameter `-e`.
```shell
$ cue eval -e b first.cue
cue eval -e b first.cue
```
```console
1
```
* Export the result. `cue export` will export the result with final value. It will report an error if some variables are not definitive.
```shell
$ cue export first.cue
cue export first.cue
```
```console
e: cannot convert incomplete value "string" to JSON:
./first.cue:9:4
```
@ -94,7 +100,9 @@ CUE has powerful CLI commands. Let's keep the data in a file named `first.cue` a
```
Then, the command will work. By default, the result will be rendered in json format.
```shell
$ cue export first.cue
cue export first.cue
```
```console
{
"a": 1.5,
"b": 1,
@ -112,7 +120,9 @@ CUE has powerful CLI commands. Let's keep the data in a file named `first.cue` a
* Export the result in YAML format.
```shell
$ cue export first.cue --out yaml
cue export first.cue --out yaml
```
```console
a: 1.5
b: 1
d:
@ -126,7 +136,9 @@ CUE has powerful CLI commands. Let's keep the data in a file named `first.cue` a
* Export the result for specified variable.
```shell
$ cue export -e g first.cue
cue export -e g first.cue
```
```console
{
"h": "abc"
}
@ -177,7 +189,9 @@ j: null
Let's name it `second.cue`. Then the `cue export` won't complain as the `#abc` is a type not incomplete value.
```shell
$ cue export second.cue
cue export second.cue
```
```console
{}
```
@ -251,7 +265,9 @@ parameter:{
5. Finally, let's export it in yaml:
```shell
$ cue export deployment.cue -e template --out yaml
cue export deployment.cue -e template --out yaml
```
```console
apiVersion: apps/v1
kind: Deployment
spec:
@ -345,7 +361,9 @@ Saving it in `third.cue` file.
You can evaluate the result by using `cue eval`:
```shell
$ cue eval third.cue
cue eval third.cue
```
```console
a: 1
b: 3
c: 3
@ -369,7 +387,9 @@ Saving it in `fourth.cue` file.
You can evaluate the result by using `cue eval`:
```shell
$ cue eval fourth.cue
cue eval fourth.cue
```
```console
price: 200
feel: "bad"
```
@ -545,4 +565,4 @@ output: {
parameter: {
name: "myapp"
}
```
```

12
docs/platform-engineers/cue/component.md
View File

@ -354,15 +354,21 @@ spec:
It will generate and manage below API resources in target cluster:
```shell
$ kubectl get deployment
kubectl get deployment
```
```console
NAME READY UP-TO-DATE AVAILABLE AGE
hello-world-v1 1/1 1 1 15s
```
$ kubectl get svc
```shell
kubectl get svc
```
```console
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
hello-world-trait-7bdcff98f7 ClusterIP <your ip> <none> 8000/TCP 32s
```
## 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](./basic) documentation about why we support CUE as first-class templating solution and more details about using CUE efficiently.

104
docs/platform-engineers/cue/patch-trait.md
View File

@ -2,7 +2,7 @@
title: Patch Traits
---
**Patch** is a very common pattern of trait definitions, i.e. the app operators can amend/path attributes to the component instance (normally the workload) to enable certain operational features such as sidecar or node affinity rules (and this should be done **before** the resources applied to target cluster).
**Patch** is a very common pattern of trait definitions, i.e. the app operators can amend/patch attributes to the component instance (normally the workload) to enable certain operational features such as sidecar or node affinity rules (and this should be done **before** the resources applied to target cluster).
This pattern is extremely useful when the component definition is provided by third-party component provider (e.g. software distributor) so app operators do not have privilege to change its template.
@ -19,8 +19,7 @@ metadata:
name: node-affinity
spec:
appliesToWorkloads:
- webservice
- worker
- deployments.apps
podDisruptive: true
schematic:
cue:
@ -97,15 +96,17 @@ By default, patch trait in KubeVela leverages the CUE `merge` operation. It has
### Strategy Patch
The `strategy patch` is useful for patching array list.
Strategy Patch is effective by adding annotation, and supports the following two ways
> Note that this is not a standard CUE feature, KubeVela enhanced CUE in this case.
With `//+patchKey=<key_name>` annotation, merging logic of two array lists will not follow the CUE behavior. Instead, it will treat the list as object and use a strategy merge approach:
#### 1. With `+patchKey=<key_name>` annotation
This is useful for patching array list, merging logic of two array lists will not follow the CUE behavior. Instead, it will treat the list as object and use a strategy merge approach:
- if a duplicated key is found, the patch data will be merge with the existing values;
- if no duplication found, the patch will append into the array list.
The example of strategy patch trait will like below:
The example of strategy patch trait with 'patchKey' will like below:
```yaml
apiVersion: core.oam.dev/v1beta1
@ -116,8 +117,7 @@ metadata:
name: sidecar
spec:
appliesToWorkloads:
- webservice
- worker
- deployments.apps
podDisruptive: true
schematic:
cue:
@ -146,8 +146,7 @@ metadata:
name: expose
spec:
appliesToWorkloads:
- webservice
- worker
- deployments.apps
podDisruptive: true
schematic:
cue:
@ -174,6 +173,76 @@ spec:
So the above trait which attaches a Service to given component instance will patch an corresponding label to the workload first and then render the Service resource based on template in `outputs`.
#### 2. With `+patchStrategy=retainkeys` annotation
Similar to strategy [retainkeys](https://kubernetes.io/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/#use-strategic-merge-patch-to-update-a-deployment-using-the-retainkeys-strategy) in K8s strategic merge patch
In some scenarios that the entire object needs to be replaced, retainkeys strategy is the best choice. the example as follows:
Assume the Deployment is the base resource
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: retainkeys-demo
spec:
selector:
matchLabels:
app: nginx
strategy:
type: rollingUpdate
rollingUpdate:
maxSurge: 30%
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: retainkeys-demo-ctr
image: nginx
```
Now want to replace rollingUpdate strategy with a new strategy, you can write the patch trait like below
```yaml
apiVersion: core.oam.dev/v1alpha2
kind: TraitDefinition
metadata:
name: recreate
spec:
appliesToWorkloads:
- deployments.apps
extension:
template: |-
patch: {
spec: {
// +patchStrategy=retainKeys
strategy: type: "Recreate"
}
}
```
Then the base resource becomes as follows
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: retainkeys-demo
spec:
selector:
matchLabels:
app: nginx
strategy:
type: Recreate
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: retainkeys-demo-ctr
image: nginx
```
## More Use Cases of Patch Trait
Patch trait is in general pretty useful to separate operational concerns from the component definition, here are some more examples.
@ -191,8 +260,7 @@ metadata:
name: virtualgroup
spec:
appliesToWorkloads:
- webservice
- worker
- deployments.apps
podDisruptive: true
schematic:
cue:
@ -242,8 +310,7 @@ metadata:
name: kautoscale
spec:
appliesToWorkloads:
- webservice
- worker
- deployments.apps
podDisruptive: false
schematic:
cue:
@ -279,8 +346,7 @@ metadata:
name: env
spec:
appliesToWorkloads:
- webservice
- worker
- deployments.apps
podDisruptive: true
schematic:
cue:
@ -321,8 +387,7 @@ metadata:
name: service-account
spec:
appliesToWorkloads:
- webservice
- worker
- deployments.apps
podDisruptive: true
schematic:
cue:
@ -368,8 +433,7 @@ metadata:
name: init-container
spec:
appliesToWorkloads:
- webservice
- worker
- deployments.apps
podDisruptive: true
schematic:
cue:

2
docs/platform-engineers/cue/status.md
View File

@ -27,7 +27,7 @@ context:{
}
```
Trait will not have the `context.ouput`, other fields are the same.
Trait will not have the `context.output`, other fields are the same.
The example of health check likes below:

40
docs/platform-engineers/debug-test-cue.md
View File

@ -132,10 +132,10 @@ parameter: {
}
```
After everything is done, there's a script [`hack/vela-templates/mergedef.sh`](https://github.com/oam-dev/kubevela/blob/master/hack/vela-templates/mergedef.sh) to merge the `def.yaml` and `def.cue` into a completed Definition Object.
After everything is done, there's a script [`vela-templates/mergedef.sh`](https://github.com/oam-dev/kubevela/blob/master/vela-templates/mergedef.sh) to merge the `def.yaml` and `def.cue` into a completed Definition Object.
```shell
$ ./hack/vela-templates/mergedef.sh def.yaml def.cue > microservice-def.yaml
./vela-templates/mergedef.sh def.yaml def.cue > microservice-def.yaml
```
## Debug CUE template
@ -143,7 +143,9 @@ $ ./hack/vela-templates/mergedef.sh def.yaml def.cue > microservice-def.yaml
### Use `cue vet` to Validate
```shell
$ cue vet def.cue
cue vet def.cue
```
```console
output.metadata.name: reference "context" not found:
./def.cue:6:14
output.spec.selector.matchLabels.app: reference "context" not found:
@ -174,14 +176,18 @@ context: {
Then execute the command:
```shell
$ cue vet def.cue
cue vet def.cue
```
```console
some instances are incomplete; use the -c flag to show errors or suppress this message
```
The `reference "context" not found` error is gone, but `cue vet` only validates the data type which is not enough to ensure the login in template is correct. Hence we need to use `cue vet -c` for complete validation:
```shell
$ cue vet def.cue -c
cue vet def.cue -c
```
```console
context.name: incomplete value string
output.metadata.name: incomplete value string
output.spec.selector.matchLabels.app: incomplete value string
@ -226,7 +232,9 @@ cue vet def.cue -c
The `cue export` can export rendered result in YAMl foramt:
```shell
$ cue export -e output def.cue --out yaml
cue export -e output def.cue --out yaml
```
```console
apiVersion: apps/v1
kind: Deployment
metadata:
@ -250,7 +258,9 @@ spec:
```
```shell
$ cue export -e outputs.service def.cue --out yaml
cue export -e outputs.service def.cue --out yaml
```
```console
apiVersion: v1
kind: Service
metadata:
@ -286,7 +296,9 @@ There are two kinds of ways to import internal `kube` packages.
2. Import them with third-party packages style. You can run `vela system cue-packages` to list all build-in `kube` packages
to know the `third-party packages` supported currently.
```shell
$ vela system cue-packages
vela system cue-packages
```
```console
DEFINITION-NAME IMPORT-PATH USAGE
#Deployment k8s.io/apps/v1 Kube Object for apps/v1.Deployment
#Service k8s.io/core/v1 Kube Object for v1.Service
@ -318,7 +330,7 @@ touch def.cue
In KubeVela, we don't need to download these packages as they're automatically generated from K8s API.
But for local test, we need to use `cue get go` to fetch Go packages and convert them to CUE format files.
So, by using K8s `Deployment` and `Serivice`, we need download and convert to CUE definitions for the `core` and `apps` Kubernetes modules like below:
So, by using K8s `Deployment` and `Service`, we need download and convert to CUE definitions for the `core` and `apps` Kubernetes modules like below:
```shell
cue get go k8s.io/api/core/v1
@ -520,7 +532,9 @@ parameter: {
Use `cue export` to see the export result.
```shell
$ cue export def.cue --out yaml
cue export def.cue --out yaml
```
```console
output:
metadata:
name: test
@ -576,7 +590,7 @@ When CUE template is good, we can use `vela system dry-run` to dry run and check
First, we need use `mergedef.sh` to merge the definition and cue files.
```shell
$ mergedef.sh def.yaml def.cue > componentdef.yaml
mergedef.sh def.yaml def.cue > componentdef.yaml
```
Then, let's create an Application named `test-app.yaml`.
@ -604,7 +618,9 @@ spec:
Dry run the application by using `vela system dry-run`.
```shell
$ vela system dry-run -f test-app.yaml -d componentdef.yaml
vela system dry-run -f test-app.yaml -d componentdef.yaml
```
```console
---
# Application(boutique) -- Comopnent(frontend)
---

22
docs/platform-engineers/definition-and-templates.md
View File

@ -70,7 +70,6 @@ metadata:
spec:
appliesToWorkloads:
- deployments.apps
- webservice
conflictsWith:
- service
workloadRefPath: spec.wrokloadRef
@ -85,16 +84,15 @@ This field defines the constraints that what kinds of workloads this trait is al
- It accepts an array of string as value.
- Each item in the array refers to one or a group of workload types to which this trait is allowded to apply.
There are four approaches to denote one or a group of workload types.
There are three approaches to denote one or a group of workload types.
- `ComponentDefinition` name, e.g., `webservice`, `worker`
- `ComponentDefinition` definition reference (CRD name), e.g., `deployments.apps`
- Resource group of `ComponentDefinition` definition reference prefixed with `*.`, e.g., `*.apps`, `*.oam.dev`. This means the trait is allowded to apply to any workloads in this group.
- `*` means this trait is allowded to apply to any workloads
If this field is omitted, it means this trait is allowded to apply to any workload types.
KubeVela will raise an error if a trait is applied to a workload which is NOT included in the `appliesToWorkloads`.
KubeVela will raise an error if a trait is applied to a workload type which is NOT included in the `appliesToWorkloads`.
##### `.spec.conflictsWith`
@ -118,7 +116,7 @@ This field defines the field path of the trait which is used to store the refere
If this field is set, KubeVela core will automatically fill the workload reference into target field of the trait. Then the trait controller can get the workload reference from the trait latter. So this field usually accompanies with the traits whose controllers relying on the workload reference at runtime.
Please check [scaler](https://github.com/oam-dev/kubevela/blob/master/charts/vela-core/templates/defwithtemplate/manualscale.yaml) trait as a demonstration of how to set this field.
Please check [scaler](https://github.com/oam-dev/kubevela/blob/master/charts/vela-core/templates/defwithtemplate/scaler.yaml) trait as a demonstration of how to set this field.
##### `.spec.podDisruptive`
@ -242,7 +240,9 @@ In KubeVela, definition entities are mutable. Each time a `ComponentDefinition`
For example, we can design a new parameter named `args` for the `webservice` component definition by applying a new definition with same name as below.
```shell
$ kubectl vela show webservice
kubectl vela show webservice
```
```console
# Properties
+-------+----------------------------------------------------+----------+----------+---------+
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
@ -258,7 +258,9 @@ kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/docs/
The change will take effect immediately.
```shell
$ kubectl vela show webservice
kubectl vela show webservice
```
```console
# Properties
+-------+----------------------------------------------------+----------+----------+---------+
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
@ -271,7 +273,9 @@ $ kubectl vela show webservice
We will see a new definition revision will be automatically generated, `v2` is the latest version, `v1` is the previous one.
```shell
$ kubectl get definitionrevision -l="componentdefinition.oam.dev/name=webservice" -n vela-system
kubectl get definitionrevision -l="componentdefinition.oam.dev/name=webservice" -n vela-system
```
```console
NAME REVISION HASH TYPE
webservice-v1 1 3f6886d9832021ba Component
webservice-v2 2 b3b9978e7164d973 Component
@ -316,4 +320,4 @@ spec:
- '1000'
args:
- wait
```
```

12
docs/platform-engineers/helm/component.md
View File

@ -65,18 +65,24 @@ The component `properties` is exactly the [overlay values](https://github.com/ca
Deploy the application and after several minutes (it may take time to fetch Helm chart), you can check the Helm release is installed.
```shell
$ helm ls -A
helm ls -A
```
```console
myapp-demo-podinfo default 1 2021-03-05 02:02:18.692317102 +0000 UTC deployed podinfo-5.1.4 5.1.4
```
Check the workload defined in the chart has been created successfully.
```shell
$ kubectl get deploy
kubectl get deploy
```
```console
NAME READY UP-TO-DATE AVAILABLE AGE
myapp-demo-podinfo 1/1 1 1 66m
```
Check the values (`image.tag = 5.1.2`) from application's `properties` are assigned to the chart.
```shell
$ kubectl get deployment myapp-demo-podinfo -o json | jq '.spec.template.spec.containers[0].image'
kubectl get deployment myapp-demo-podinfo -o json | jq '.spec.template.spec.containers[0].image'
```
```console
"ghcr.io/stefanprodan/podinfo:5.1.2"
```

34
docs/platform-engineers/helm/trait.md
View File

@ -4,7 +4,7 @@ title: Attach Traits
Traits in KubeVela can be attached to Helm based component seamlessly.
In this sample application below, we add two traits, [scaler](https://github.com/oam-dev/kubevela/blob/master/charts/vela-core/templates/defwithtemplate/manualscale.yaml)
In this sample application below, we add two traits, [scaler](https://github.com/oam-dev/kubevela/blob/master/charts/vela-core/templates/defwithtemplate/scaler.yaml)
and [virtualgroup](https://github.com/oam-dev/kubevela/blob/master/docs/examples/helm-module/virtual-group-td.yaml) to a Helm based component.
```yaml
@ -40,18 +40,24 @@ spec:
Check the `scaler` trait takes effect.
```shell
$ kubectl get manualscalertrait
kubectl get manualscalertrait
```
```console
NAME AGE
demo-podinfo-scaler-d8f78c6fc 13m
```
```shell
$ kubectl get deployment myapp-demo-podinfo -o json | jq .spec.replicas
kubectl get deployment myapp-demo-podinfo -o json | jq .spec.replicas
```
```console
4
```
Check the `virtualgroup` trait.
```shell
$ kubectl get deployment myapp-demo-podinfo -o json | jq .spec.template.metadata.labels
kubectl get deployment myapp-demo-podinfo -o json | jq .spec.template.metadata.labels
```
```console
{
"app.cluster.virtual.group": "my-group1",
"app.kubernetes.io/name": "myapp-demo-podinfo"
@ -93,25 +99,33 @@ Apply the new configuration and check the results after several minutes.
Check the new values (`image.tag = 5.1.3`) from application's `properties` are assigned to the chart.
```shell
$ kubectl get deployment myapp-demo-podinfo -o json | jq '.spec.template.spec.containers[0].image'
kubectl get deployment myapp-demo-podinfo -o json | jq '.spec.template.spec.containers[0].image'
```
```console
"ghcr.io/stefanprodan/podinfo:5.1.3"
```
Under the hood, Helm makes an upgrade to the release (revision 1 => 2).
```shell
$ helm ls -A
helm ls -A
```
```console
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
myapp-demo-podinfo default 2 2021-03-15 08:52:00.037690148 +0000 UTC deployed podinfo-5.1.4 5.1.4
```
Check the `scaler` trait.
```shell
$ kubectl get deployment myapp-demo-podinfo -o json | jq .spec.replicas
kubectl get deployment myapp-demo-podinfo -o json | jq .spec.replicas
```
```console
2
```
Check the `virtualgroup` trait.
```shell
$ kubectl get deployment myapp-demo-podinfo -o json | jq .spec.template.metadata.labels
kubectl get deployment myapp-demo-podinfo -o json | jq .spec.template.metadata.labels
```
```console
{
"app.cluster.virtual.group": "my-group2",
"app.kubernetes.io/name": "myapp-demo-podinfo"
@ -147,7 +161,9 @@ spec:
Apply the application and check `manualscalertrait` has been deleted.
```shell
$ kubectl get manualscalertrait
kubectl get manualscalertrait
```
```console
No resources found
```

4
docs/platform-engineers/keda.md
View File

@ -46,7 +46,7 @@ This is how you claim and register KEDA `ScaledObject`'s API resource (`scaledob
### 3. Define `appliesToWorkloads`
A trait can be attached to specified workload types or all (i.e. `"*"` means your trait can work with any workload type).
A trait can be attached to specified workload types or all (i.e. `"*"` or omitted means your trait can work with any workload type).
For the case of KEAD, we will only allow user to attach it to Kubernetes workload type. So we claim it as below:
@ -105,7 +105,7 @@ This is a CUE based template which only exposes `type` and `value` as trait prop
As long as the definition file is ready, you just need to apply it to Kubernetes.
```bash
$ kubectl apply -f https://raw.githubusercontent.com/oam-dev/catalog/master/registry/keda-scaler.yaml
kubectl apply -f https://raw.githubusercontent.com/oam-dev/catalog/master/registry/keda-scaler.yaml
```
And the new trait will immediately become available for end users to use in `Application` resource.

8
docs/platform-engineers/kube/component.md
View File

@ -79,13 +79,17 @@ Since parameters only support basic data type, values in `properties` should be
Deploy the `Application` and verify the running workload instance.
```shell
$ kubectl get deploy
kubectl get deploy
```
```console
NAME READY UP-TO-DATE AVAILABLE AGE
mycomp 1/1 1 1 66m
```
And check the parameter works.
```shell
$ kubectl get deployment mycomp -o json | jq '.spec.template.spec.containers[0].image'
kubectl get deployment mycomp -o json | jq '.spec.template.spec.containers[0].image'
```
```console
"nginx:1.14.0"
```

26
docs/platform-engineers/kube/trait.md
View File

@ -5,7 +5,7 @@ title: Attach Traits
All traits in the KubeVela system works well with the simple template based Component.
In this sample, we will attach two traits,
[scaler](https://github.com/oam-dev/kubevela/blob/master/charts/vela-core/templates/defwithtemplate/manualscale.yaml)
[scaler](https://github.com/oam-dev/kubevela/blob/master/charts/vela-core/templates/defwithtemplate/scaler.yaml)
and
[virtualgroup](https://github.com/oam-dev/kubevela/blob/master/docs/examples/kube-module/virtual-group-td.yaml) to a component
@ -37,18 +37,24 @@ Deploy the application and verify traits work.
Check the `scaler` trait.
```shell
$ kubectl get manualscalertrait
kubectl get manualscalertrait
```
```console
NAME AGE
demo-podinfo-scaler-3x1sfcd34 2m
```
```shell
$ kubectl get deployment mycomp -o json | jq .spec.replicas
kubectl get deployment mycomp -o json | jq .spec.replicas
```
```console
2
```
Check the `virtualgroup` trait.
```shell
$ kubectl get deployment mycomp -o json | jq .spec.template.metadata.labels
kubectl get deployment mycomp -o json | jq .spec.template.metadata.labels
```
```console
{
"app.cluster.virtual.group": "my-group1",
"app.kubernetes.io/name": "myapp"
@ -91,19 +97,25 @@ Apply the new configuration and check the results after several seconds.
Check the new property value.
```shell
$ kubectl get deployment mycomp -o json | jq '.spec.template.spec.containers[0].image'
kubectl get deployment mycomp -o json | jq '.spec.template.spec.containers[0].image'
```
```console
"nginx:1.14.1"
```
Check the `scaler` trait.
```shell
$ kubectl get deployment mycomp -o json | jq .spec.replicas
kubectl get deployment mycomp -o json | jq .spec.replicas
```
```console
4
```
Check the `virtualgroup` trait.
```shell
$ kubectl get deployment mycomp -o json | jq .spec.template.metadata.labels
kubectl get deployment mycomp -o json | jq .spec.template.metadata.labels
```
```console
{
"app.cluster.virtual.group": "my-group2",
"app.kubernetes.io/name": "myapp"

40
docs/platform-engineers/openapi-v3-json-schema.md
View File

@ -9,17 +9,33 @@ KubeVela will automatically generate OpenAPI v3 JSON schema based on its paramet
## List Schema
This `ConfigMap` will have a common label `definition.oam.dev=schema`, so you can find easily by:
KubeVela support generate different versions of Component/Trait Definition.
Thus, we use `ConfigMap` to store the parameter information of different versions of Definition.
This `ConfigMap` will have a common label `definition.oam.dev=schema`, the default `ConfigMap` without a version suffix will point to the latest version,
you can find easily by:
```shell
$ kubectl get configmap -n vela-system -l definition.oam.dev=schema
NAME DATA AGE
schema-ingress 1 19s
schema-scaler 1 19s
schema-task 1 19s
schema-webservice 1 19s
schema-worker 1 20s
kubectl get configmap -n vela-system -l definition.oam.dev=schema
```
```console
NAME DATA AGE
schema-ingress 1 46m
schema-scaler 1 50m
schema-webservice 1 2m26s
schema-webservice-v1 1 40s
schema-worker 1 1m45s
schema-worker-v1 1 55s
schema-worker-v2 1 20s
```
For the sack of convenience, we also specify a unified label for the `ConfigMap` which stores the parameter information of the same Definition.
And we can list the ConfigMap which stores the parameter of the same Definition by specifying the label like `definition.oam.dev/name=definitionName`, where the `definitionName` is the specific name of your component or trait.
```shell
kubectl get configmap -l definition.oam.dev/name=worker
```
```console
NAME DATA AGE
schema-worker 1 1m50s
schema-worker-v1 1 1m
schema-worker-v2 1 25s
```
The `ConfigMap` name is in the format of `schema-<your-definition-name>`,
@ -28,7 +44,9 @@ and the data key is `openapi-v3-json-schema`.
For example, we can use the following command to get the JSON schema of `webservice`.
```shell
$ kubectl get configmap schema-webservice -n vela-system -o yaml
kubectl get configmap schema-webservice -n vela-system -o yaml
```
```console
apiVersion: v1
kind: ConfigMap
metadata:

8
docs/platform-engineers/overview.md
View File

@ -108,7 +108,7 @@ Hence, the `properties` section of `backend` only exposes two parameters to fill
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, `TraitDefiniton` also allows you to define *template* for operational features.
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:
@ -121,8 +121,7 @@ metadata:
name: hpa
spec:
appliesToWorkloads:
- webservice
- worker
- deployments.apps
schematic:
cue:
template: |
@ -168,8 +167,7 @@ metadata:
name: sidecar
spec:
appliesToWorkloads:
- webservice
- worker
- deployments.apps
schematic:
cue:
template: |-

8
docs/platform-engineers/terraform.md
View File

@ -10,10 +10,10 @@ These cloud services are provided by Terraform.
<details>
Download the latest chart, like `terraform-controller-chart-0.1.4.tgz`, from the latest [releases list](https://github.com/oam-dev/terraform-controller/releases) and install it.
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
$ helm install terraform-controller terraform-controller-0.1.2.tgz
$ helm install terraform-controller terraform-controller-0.1.8.tgz
NAME: terraform-controller
LAST DEPLOYED: Mon Apr 26 15:55:35 2021
NAMESPACE: default
@ -30,7 +30,7 @@ Please refer to [Terraform controller getting started](https://github.com/oam-de
</details>
## Register `alibaba-rds` Component
### Register `alibaba-rds` Component
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.
@ -140,4 +140,4 @@ spec:
}
```
```

12
docs/quick-start-appfile.md
View File

@ -15,7 +15,9 @@ Make sure you have finished and verified the installation following [this guide]
## Step 2: Deploy Your First Application
```bash
$ vela up -f https://raw.githubusercontent.com/oam-dev/kubevela/master/docs/examples/vela.yaml
vela up -f https://raw.githubusercontent.com/oam-dev/kubevela/master/docs/examples/vela.yaml
```
```console
Parsing vela.yaml ...
Loading templates ...
@ -35,7 +37,9 @@ App has not been deployed, creating a new deployment...
Check the status until we see `Routes` are ready:
```bash
$ vela status first-vela-app
vela status first-vela-app
```
```console
About:
Name: first-vela-app
@ -58,7 +62,9 @@ Services:
**In [kind cluster setup](./install#kind)**, 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/
```
```console
<xmp>
Hello World

16
docs/quick-start.md
View File

@ -10,8 +10,10 @@ Make sure you have finished and verified the installation following [this guide]
## Step 2: Deploy Your First Application
```bash
$ kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/docs/examples/vela-app.yaml
```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
```
@ -19,8 +21,10 @@ Above command will apply an application to KubeVela and let it distribute the ap
Check the status until we see `status` is `running` and services are `healthy`:
```bash
$ kubectl get application first-vela-app -o yaml
```bash script
kubectl get application first-vela-app -o yaml
```
```console
apiVersion: core.oam.dev/v1beta1
kind: Application
...
@ -38,8 +42,10 @@ status:
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>/
```
$ curl -H "Host:testsvc.example.com" http://<your ip address>/
```console
<xmp>
Hello World

BIN
docs/resources/arch.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 429 KiB

After

Width:  |  Height:  |  Size: 415 KiB

5
docs/roadmap.md
View File

@ -1,5 +0,0 @@
---
title: KubeVela Roadmap
---
Please visit [roadmap docs page](https://github.com/oam-dev/kubevela/tree/master/docs/en/roadmap/).

36
docs/roadmap/2021-06-roadmap.md Normal file
View File

@ -0,0 +1,36 @@
---
title: Roadmap
---
Date: 2021-04-01 to 2021-06-30
## Core Platform
1. Implement Application serverside Kustomize and Workflow.
2. KubeVela as a control plane.
- Application Controller deploy resources directly to remote clusters and instead of using AppContext
- AppRollout should be able to work in runtime cluster or rollout remote cluster resources
3. Multi-cluster and Multi-environment support, applications can deploy in different environments which
contains different clusters with different strategies.
4. Better Helm and Kustomize support, users can deploy a helm chart or a git repo directly without any more effort.
5. Support built-in Application monitoring.
6. Support more rollout strategies.
- blue-green
- traffic management rollout
- canary
- A/B
7. Support a general CUE controller which can glue more than K8s CRDs, it should support more protocol such as restful API,
go function call, etc.
8. Discoverable capability registries with more back integrations(file server/github/OSS).
## User Experience
1. Develop tools and CI integration.
2. Refine our docs and website.
## Third-party integrations
1. Integrate with Open Cluster Management.
2. Integrate with Flux CD
3. Integrate with Dapr to enable end-to-end microservice application development and deployment workflow.
4. Integrate with Tilt for local development.

21
docs/roadmap/2021-09-roadmap.md Normal file
View File

@ -0,0 +1,21 @@
---
title: Roadmap
---
Date: 2021-07-01 to 2021-09-30
## Core Platform
1. Support more built-in capabilities and cloud resources with unified experience, such as monitoring, auto-scaling, middle ware plugins.
2. Auto binding for cloud resources.
3. Support more security policy( integrate with OPA, CIS, Popeye ).
TBD: more features to be added
## User Experience
1. Support Dashboard for deploying KubeVela Application.
2. Support velacp as non-K8s APIServer for CI integration.
## Third-party integrations

5
docs/roadmap/README.md
View File

@ -2,5 +2,10 @@
title: KubeVela Roadmap
---
- [2021 Fall Roadmap](./2021-09-roadmap)
- [2021 Summer Roadmap](./2021-06-roadmap)
- [2021 Spring Roadmap](./2021-03-roadmap)
- [2020 Winter Roadmap](./2020-12-roadmap)
To learn more details, please visit the [up to date github page](https://github.com/oam-dev/kubevela/tree/master/docs/en/roadmap/)
and [github issues list](https://github.com/oam-dev/kubevela/issues).

3
sidebars.js
View File

@ -168,13 +168,14 @@ module.exports = {
'cli/vela_cap',
],
},
'developers/references/kubectl-plugin'
],
},
{
type: 'category',
label: 'Roadmap',
items: [
'roadmap',
'roadmap/README',
],
},
{

27
versioned_docs/version-v1.0/README.md Normal file
View File

@ -0,0 +1,27 @@
![alt](resources/KubeVela-03.png)
*Make shipping applications more enjoyable.*
# KubeVela
KubeVela is a modern application platform that makes deploying and managing applications across today's hybrid, multi-cloud environments easier and faster.
## Community
- Slack: [CNCF Slack](https://slack.cncf.io/) #kubevela channel
- Gitter: [Discussion](https://gitter.im/oam-dev/community)
- Bi-weekly Community Call: [Meeting Notes](https://docs.google.com/document/d/1nqdFEyULekyksFHtFvgvFAYE-0AMHKoS3RMnaKsarjs)
## Installation
Installation guide is available on [this section](./install).
## Quick Start
Quick start is available on [this section](./quick-start).
## Contributing
Check out [CONTRIBUTING](https://github.com/oam-dev/kubevela/blob/master/CONTRIBUTING.md) to see how to develop with KubeVela.
## Code of Conduct
KubeVela adopts the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md).

162
versioned_docs/version-v1.0/advanced-install.mdx Normal file
View File

@ -0,0 +1,162 @@
---
title: Other Install Topics
---
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
## Install KubeVela with cert-manager
KubeVela can use cert-manager generate certs for your application if it's available. Note that you need to install cert-manager **before** the KubeVela chart.
```shell script
helm repo add jetstack https://charts.jetstack.io
helm repo update
helm install cert-manager jetstack/cert-manager --namespace cert-manager --version v1.2.0 --create-namespace --set installCRDs=true
```
Install kubevela with enabled certmanager:
```shell script
helm install --create-namespace -n vela-system --set admissionWebhooks.certManager.enabled=true kubevela kubevela/vela-core
```
## Install Pre-release
Add flag `--devel` in command `helm search` to choose a pre-release
version in format `<next_version>-rc-master`. It means a release candidate version build on `master` branch,
such as `0.4.0-rc-master`.
```shell script
helm search repo kubevela/vela-core -l --devel
```
```console
NAME CHART VERSION APP VERSION DESCRIPTION
kubevela/vela-core 0.4.0-rc-master 0.4.0-rc-master A Helm chart for KubeVela core
kubevela/vela-core 0.3.2 0.3.2 A Helm chart for KubeVela core
kubevela/vela-core 0.3.1 0.3.1 A Helm chart for KubeVela core
```
And try the following command to install it.
```shell script
helm install --create-namespace -n vela-system kubevela kubevela/vela-core --version <next_version>-rc-master
```
```console
NAME: kubevela
LAST DEPLOYED: Thu Apr 1 19:41:30 2021
NAMESPACE: vela-system
STATUS: deployed
REVISION: 1
NOTES:
Welcome to use the KubeVela! Enjoy your shipping application journey!
```
## Install Kubectl Vela Plugin
Install vela kubectl plugin can help you to ship applications more easily!
<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>
For more usage please reference [kubectl plugin](./developers/references/kubectl-plugin).
## Upgrade
### Step 1. Update Helm repo
You can explore the newly released chart versions of KubeVela by run:
```shell
helm repo update
helm search repo kubevela/vela-core -l
```
### Step 2. Upgrade KubeVela CRDs
```shell
kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/charts/vela-core/crds/core.oam.dev_componentdefinitions.yaml
kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/charts/vela-core/crds/core.oam.dev_workloaddefinitions.yaml
kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/charts/vela-core/crds/core.oam.dev_traitdefinitions.yaml
kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/charts/vela-core/crds/core.oam.dev_applications.yaml
kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/charts/vela-core/crds/core.oam.dev_approllouts.yaml
kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/charts/vela-core/crds/core.oam.dev_applicationrevisions.yaml
kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/charts/vela-core/crds/core.oam.dev_scopedefinitions.yaml
kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/charts/vela-core/crds/core.oam.dev_appdeployments.yaml
kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/charts/vela-core/crds/core.oam.dev_applicationcontexts.yaml
```
> Tips: If you see errors like `* is invalid: spec.scope: Invalid value: "Namespaced": filed is immutable`. Please delete the CRD which reports error and re-apply the kubevela crds.
```shell
kubectl delete crd \
scopedefinitions.core.oam.dev \
traitdefinitions.core.oam.dev \
workloaddefinitions.core.oam.dev
```
### Step 3. Upgrade KubeVela Helm chart
```shell
helm upgrade --install --create-namespace --namespace vela-system kubevela kubevela/vela-core --version <the_new_version>
```
## Clean Up
Run:
```shell script
helm uninstall -n vela-system kubevela
rm -r ~/.vela
```
This will uninstall KubeVela server component and its dependency components.
This also cleans up local CLI cache.
Then clean up CRDs (CRDs are not removed via helm by default):
```shell script
kubectl delete crd \
appdeployments.core.oam.dev \
applicationconfigurations.core.oam.dev \
applicationcontexts.core.oam.dev \
applicationrevisions.core.oam.dev \
applications.core.oam.dev \
approllouts.core.oam.dev \
componentdefinitions.core.oam.dev \
components.core.oam.dev \
containerizedworkloads.core.oam.dev \
healthscopes.core.oam.dev \
manualscalertraits.core.oam.dev \
podspecworkloads.standard.oam.dev \
scopedefinitions.core.oam.dev \
traitdefinitions.core.oam.dev \
workloaddefinitions.core.oam.dev
```

41
versioned_docs/version-v1.0/cli/vela.md Normal file
View File

@ -0,0 +1,41 @@
---
title: vela
---
```
vela [flags]
```
### Options
```
-e, --env string specify environment name for application
-h, --help help for vela
```
### SEE ALSO
* [vela cap](vela_cap) - Manage capability centers and installing/uninstalling capabilities
* [vela completion](vela_completion) - Output shell completion code for the specified shell (bash or zsh)
* [vela config](vela_config) - Manage configurations
* [vela delete](vela_delete) - Delete an application
* [vela env](vela_env) - Manage environments
* [vela exec](vela_exec) - Execute command in a container
* [vela export](vela_export) - Export deploy manifests from appfile
* [vela help](vela_help) - Help about any command
* [vela init](vela_init) - Create scaffold for an application
* [vela logs](vela_logs) - Tail logs for application
* [vela ls](vela_ls) - List applications
* [vela port-forward](vela_port-forward) - Forward local ports to services in an application
* [vela show](vela_show) - Show the reference doc for a workload type or trait
* [vela status](vela_status) - Show status of an application
* [vela system](vela_system) - System management utilities
* [vela template](vela_template) - Manage templates
* [vela traits](vela_traits) - List traits
* [vela up](vela_up) - Apply an appfile
* [vela version](vela_version) - Prints out build version information
* [vela workloads](vela_workloads) - List workloads
###### Auto generated by spf13/cobra on 20-Mar-2021

31
versioned_docs/version-v1.0/cli/vela_cap.md Normal file
View File

@ -0,0 +1,31 @@
---
title: vela cap
---
Manage capability centers and installing/uninstalling capabilities
### Synopsis
Manage capability centers and installing/uninstalling capabilities
### Options
```
-h, --help help for cap
```
### Options inherited from parent commands
```
-e, --env string specify environment name for application
```
### SEE ALSO
* [vela](vela) -
* [vela cap center](vela_cap_center) - Manage Capability Center
* [vela cap install](vela_cap_install) - Install capability into cluster
* [vela cap ls](vela_cap_ls) - List capabilities from cap-center
* [vela cap uninstall](vela_cap_uninstall) - Uninstall capability from cluster
###### Auto generated by spf13/cobra on 20-Mar-2021

31
versioned_docs/version-v1.0/cli/vela_cap_center.md Normal file
View File

@ -0,0 +1,31 @@
---
title: vela cap center
---
Manage Capability Center
### Synopsis
Manage Capability Center with config, sync, list
### Options
```
-h, --help help for center
```
### Options inherited from parent commands
```
-e, --env string specify environment name for application
```
### SEE ALSO
* [vela cap](vela_cap) - Manage capability centers and installing/uninstalling capabilities
* [vela cap center config](vela_cap_center_config) - Configure (add if not exist) a capability center, default is local (built-in capabilities)
* [vela cap center ls](vela_cap_center_ls) - List all capability centers
* [vela cap center remove](vela_cap_center_remove) - Remove specified capability center
* [vela cap center sync](vela_cap_center_sync) - Sync capabilities from remote center, default to sync all centers
###### Auto generated by spf13/cobra on 20-Mar-2021

38
versioned_docs/version-v1.0/cli/vela_cap_center_config.md Normal file
View File

@ -0,0 +1,38 @@
---
title: vela cap center config
---
Configure (add if not exist) a capability center, default is local (built-in capabilities)
### Synopsis
Configure (add if not exist) a capability center, default is local (built-in capabilities)
```
vela cap center config <centerName> <centerURL> [flags]
```
### Examples
```
vela cap center config mycenter https://github.com/oam-dev/catalog/tree/master/registry
```
### Options
```
-h, --help help for config
-t, --token string Github Repo token
```
### Options inherited from parent commands
```
-e, --env string specify environment name for application
```
### SEE ALSO
* [vela cap center](vela_cap_center) - Manage Capability Center
###### Auto generated by spf13/cobra on 6-May-2021

37
versioned_docs/version-v1.0/cli/vela_cap_center_ls.md Normal file
View File

@ -0,0 +1,37 @@
---
title: vela cap center ls
---
List all capability centers
### Synopsis
List all configured capability centers
```
vela cap center ls [flags]
```
### Examples
```
vela cap center ls
```
### Options
```
-h, --help help for ls
```
### Options inherited from parent commands
```
-e, --env string specify environment name for application
```
### SEE ALSO
* [vela cap center](vela_cap_center) - Manage Capability Center
###### Auto generated by spf13/cobra on 20-Mar-2021

37
versioned_docs/version-v1.0/cli/vela_cap_center_remove.md Normal file
View File

@ -0,0 +1,37 @@
---
title: vela cap center remove
---
Remove specified capability center
### Synopsis
Remove specified capability center
```
vela cap center remove <centerName> [flags]
```
### Examples
```
vela cap center remove mycenter
```
### Options
```
-h, --help help for remove
```
### Options inherited from parent commands
```
-e, --env string specify environment name for application
```
### SEE ALSO
* [vela cap center](vela_cap_center) - Manage Capability Center
###### Auto generated by spf13/cobra on 20-Mar-2021

37
versioned_docs/version-v1.0/cli/vela_cap_center_sync.md Normal file
View File

@ -0,0 +1,37 @@
---
title: vela cap center sync
---
Sync capabilities from remote center, default to sync all centers
### Synopsis
Sync capabilities from remote center, default to sync all centers
```
vela cap center sync [centerName] [flags]
```
### Examples
```
vela cap center sync mycenter
```
### Options
```
-h, --help help for sync
```
### Options inherited from parent commands
```
-e, --env string specify environment name for application
```
### SEE ALSO
* [vela cap center](vela_cap_center) - Manage Capability Center
###### Auto generated by spf13/cobra on 20-Mar-2021

38
versioned_docs/version-v1.0/cli/vela_cap_install.md Normal file
View File

@ -0,0 +1,38 @@
---
title: vela cap install
---
Install capability into cluster
### Synopsis
Install capability into cluster
```
vela cap install <center>/<name> [flags]
```
### Examples
```
vela cap install mycenter/route
```
### Options
```
-h, --help help for install
-t, --token string Github Repo token
```
### Options inherited from parent commands
```
-e, --env string specify environment name for application
```
### SEE ALSO
* [vela cap](vela_cap) - Manage capability centers and installing/uninstalling capabilities
###### Auto generated by spf13/cobra on 20-Mar-2021

37
versioned_docs/version-v1.0/cli/vela_cap_ls.md Normal file
View File

@ -0,0 +1,37 @@
---
title: vela cap ls
---
List capabilities from cap-center
### Synopsis
List capabilities from cap-center
```
vela cap ls [cap-center] [flags]
```
### Examples
```
vela cap ls
```
### Options
```
-h, --help help for ls
```
### Options inherited from parent commands
```
-e, --env string specify environment name for application
```
### SEE ALSO
* [vela cap](vela_cap) - Manage capability centers and installing/uninstalling capabilities
###### Auto generated by spf13/cobra on 20-Mar-2021

38
versioned_docs/version-v1.0/cli/vela_cap_uninstall.md Normal file
View File

@ -0,0 +1,38 @@
---
title: vela cap uninstall
---
Uninstall capability from cluster
### Synopsis
Uninstall capability from cluster
```
vela cap uninstall <name> [flags]
```
### Examples
```
vela cap uninstall route
```
### Options
```
-h, --help help for uninstall
-t, --token string Github Repo token
```
### Options inherited from parent commands
```
-e, --env string specify environment name for application
```
### SEE ALSO
* [vela cap](vela_cap) - Manage capability centers and installing/uninstalling capabilities
###### Auto generated by spf13/cobra on 20-Mar-2021

32
versioned_docs/version-v1.0/cli/vela_completion.md Normal file
View File

@ -0,0 +1,32 @@
---
title: vela completion
---
Output shell completion code for the specified shell (bash or zsh)
### Synopsis
Output shell completion code for the specified shell (bash or zsh).
The shell code must be evaluated to provide interactive completion
of vela commands.
### Options
```
-h, --help help for completion
```
### Options inherited from parent commands
```
-e, --env string specify environment name for application
```
### SEE ALSO
* [vela](vela) -
* [vela completion bash](vela_completion_bash) - generate autocompletions script for bash
* [vela completion zsh](vela_completion_zsh) - generate autocompletions script for zsh
###### Auto generated by spf13/cobra on 20-Mar-2021

41
versioned_docs/version-v1.0/cli/vela_completion_bash.md Normal file
View File

@ -0,0 +1,41 @@
---
title: vela completion bash
---
generate autocompletions script for bash
### Synopsis
Generate the autocompletion script for Vela for the bash shell.
To load completions in your current shell session:
$ source <(vela completion bash)
To load completions for every new session, execute once:
Linux:
$ vela completion bash > /etc/bash_completion.d/vela
MacOS:
$ vela completion bash > /usr/local/etc/bash_completion.d/vela
```
vela completion bash
```
### Options
```
-h, --help help for bash
```
### Options inherited from parent commands
```
-e, --env string specify environment name for application
```
### SEE ALSO
* [vela completion](vela_completion) - Output shell completion code for the specified shell (bash or zsh)
###### Auto generated by spf13/cobra on 20-Mar-2021

38
versioned_docs/version-v1.0/cli/vela_completion_zsh.md Normal file
View File

@ -0,0 +1,38 @@
---
title: vela completion zsh
---
generate autocompletions script for zsh
### Synopsis
Generate the autocompletion script for Vela for the zsh shell.
To load completions in your current shell session:
$ source <(vela completion zsh)
To load completions for every new session, execute once:
$ vela completion zsh > "${fpath[1]}/_vela"
```
vela completion zsh
```
### Options
```
-h, --help help for zsh
```
### Options inherited from parent commands
```
-e, --env string specify environment name for application
```
### SEE ALSO
* [vela completion](vela_completion) - Output shell completion code for the specified shell (bash or zsh)
###### Auto generated by spf13/cobra on 20-Mar-2021

37
versioned_docs/version-v1.0/cli/vela_components.md Normal file
View File

@ -0,0 +1,37 @@
---
title: vela components
---
List components
### Synopsis
List components
```
vela components
```
### Examples
```
vela components
```
### Options
```
-h, --help help for workloads
```
### Options inherited from parent commands
```
-e, --env string specify environment name for application
```
### SEE ALSO
* [vela](vela) -
###### Auto generated by spf13/cobra on 20-Mar-2021

31
versioned_docs/version-v1.0/cli/vela_config.md Normal file
View File

@ -0,0 +1,31 @@
---
title: vela config
---
Manage configurations
### Synopsis
Manage configurations
### Options
```
-h, --help help for config
```
### Options inherited from parent commands
```
-e, --env string specify environment name for application
```
### SEE ALSO
* [vela](vela) -
* [vela config del](vela_config_del) - Delete config
* [vela config get](vela_config_get) - Get data for a config
* [vela config ls](vela_config_ls) - List configs
* [vela config set](vela_config_set) - Set data for a config
###### Auto generated by spf13/cobra on 20-Mar-2021

37
versioned_docs/version-v1.0/cli/vela_config_del.md Normal file
View File

@ -0,0 +1,37 @@
---
title: vela config del
---
Delete config
### Synopsis
Delete config
```
vela config del
```
### Examples
```
vela config del <config-name>
```
### Options
```
-h, --help help for del
```
### Options inherited from parent commands
```
-e, --env string specify environment name for application
```
### SEE ALSO
* [vela config](vela_config) - Manage configurations
###### Auto generated by spf13/cobra on 20-Mar-2021

37
versioned_docs/version-v1.0/cli/vela_config_get.md Normal file
View File

@ -0,0 +1,37 @@
---
title: vela config get
---
Get data for a config
### Synopsis
Get data for a config
```
vela config get
```
### Examples
```
vela config get <config-name>
```
### Options
```
-h, --help help for get
```
### Options inherited from parent commands
```
-e, --env string specify environment name for application
```
### SEE ALSO
* [vela config](vela_config) - Manage configurations
###### Auto generated by spf13/cobra on 20-Mar-2021

37
versioned_docs/version-v1.0/cli/vela_config_ls.md Normal file
View File

@ -0,0 +1,37 @@
---
title: vela config ls
---
List configs
### Synopsis
List all configs
```
vela config ls
```
### Examples
```
vela config ls
```
### Options
```
-h, --help help for ls
```
### Options inherited from parent commands
```
-e, --env string specify environment name for application
```
### SEE ALSO
* [vela config](vela_config) - Manage configurations
###### Auto generated by spf13/cobra on 20-Mar-2021

37
versioned_docs/version-v1.0/cli/vela_config_set.md Normal file
View File

@ -0,0 +1,37 @@
---
title: vela config set
---
Set data for a config
### Synopsis
Set data for a config
```
vela config set
```
### Examples
```
vela config set <config-name> KEY=VALUE K2=V2
```
### Options
```
-h, --help help for set
```
### Options inherited from parent commands
```
-e, --env string specify environment name for application
```
### SEE ALSO
* [vela config](vela_config) - Manage configurations
###### Auto generated by spf13/cobra on 20-Mar-2021

38
versioned_docs/version-v1.0/cli/vela_delete.md Normal file
View File

@ -0,0 +1,38 @@
---
title: vela delete
---
Delete an application
### Synopsis
Delete an application
```
vela delete APP_NAME
```
### Examples
```
vela delete frontend
```
### Options
```
-h, --help help for delete
--svc string delete only the specified service in this app
```
### Options inherited from parent commands
```
-e, --env string specify environment name for application
```
### SEE ALSO
* [vela](vela) -
###### Auto generated by spf13/cobra on 20-Mar-2021

31
versioned_docs/version-v1.0/cli/vela_env.md Normal file
View File

@ -0,0 +1,31 @@
---
title: vela env
---
Manage environments
### Synopsis
Manage environments
### Options
```
-h, --help help for env
```
### Options inherited from parent commands
```
-e, --env string specify environment name for application
```
### SEE ALSO
* [vela](vela) -
* [vela env delete](vela_env_delete) - Delete environment
* [vela env init](vela_env_init) - Create environments
* [vela env ls](vela_env_ls) - List environments
* [vela env set](vela_env_set) - Set an environment
###### Auto generated by spf13/cobra on 20-Mar-2021

37
versioned_docs/version-v1.0/cli/vela_env_delete.md Normal file
View File

@ -0,0 +1,37 @@
---
title: vela env delete
---
Delete environment
### Synopsis
Delete environment
```
vela env delete
```
### Examples
```
vela env delete test
```
### Options
```
-h, --help help for delete
```
### Options inherited from parent commands
```
-e, --env string specify environment name for application
```
### SEE ALSO
* [vela env](vela_env) - Manage environments
###### Auto generated by spf13/cobra on 20-Mar-2021

40
versioned_docs/version-v1.0/cli/vela_env_init.md Normal file
View File

@ -0,0 +1,40 @@
---
title: vela env init
---
Create environments
### Synopsis
Create environment and set the currently using environment
```
vela env init <envName>
```
### Examples
```
vela env init test --namespace test --email my@email.com
```
### Options
```
--domain string specify domain your applications
--email string specify email for production TLS Certificate notification
-h, --help help for init
--namespace string specify K8s namespace for env
```
### Options inherited from parent commands
```
-e, --env string specify environment name for application
```
### SEE ALSO
* [vela env](vela_env) - Manage environments
###### Auto generated by spf13/cobra on 20-Mar-2021

37
versioned_docs/version-v1.0/cli/vela_env_ls.md Normal file
View File

@ -0,0 +1,37 @@
---
title: vela env ls
---
List environments
### Synopsis
List all environments
```
vela env ls
```
### Examples
```
vela env ls [env-name]
```
### Options
```
-h, --help help for ls
```
### Options inherited from parent commands
```
-e, --env string specify environment name for application
```
### SEE ALSO
* [vela env](vela_env) - Manage environments
###### Auto generated by spf13/cobra on 20-Mar-2021

37
versioned_docs/version-v1.0/cli/vela_env_set.md Normal file
View File

@ -0,0 +1,37 @@
---
title: vela env set
---
Set an environment
### Synopsis
Set an environment as the current using one
```
vela env set
```
### Examples
```
vela env set test
```
### Options
```
-h, --help help for set
```
### Options inherited from parent commands
```
-e, --env string specify environment name for application
```
### SEE ALSO
* [vela env](vela_env) - Manage environments
###### Auto generated by spf13/cobra on 20-Mar-2021

35
versioned_docs/version-v1.0/cli/vela_exec.md Normal file
View File

@ -0,0 +1,35 @@
---
title: vela exec
---
Execute command in a container
### Synopsis
Execute command in a container
```
vela exec [flags] APP_NAME -- COMMAND [args...]
```
### Options
```
-h, --help help for exec
--pod-running-timeout duration The length of time (like 5s, 2m, or 3h, higher than zero) to wait until at least one pod is running (default 1m0s)
-i, --stdin Pass stdin to the container (default true)
-s, --svc string service name
-t, --tty Stdin is a TTY (default true)
```
### Options inherited from parent commands
```
-e, --env string specify environment name for application
```
### SEE ALSO
* [vela](vela) -
###### Auto generated by spf13/cobra on 20-Mar-2021

32
versioned_docs/version-v1.0/cli/vela_export.md Normal file
View File

@ -0,0 +1,32 @@
---
title: vela export
---
Export deploy manifests from appfile
### Synopsis
Export deploy manifests from appfile
```
vela export
```
### Options
```
-f, -- string specify file path for appfile
-h, --help help for export
```
### Options inherited from parent commands
```
-e, --env string specify environment name for application
```
### SEE ALSO
* [vela](vela) -
###### Auto generated by spf13/cobra on 20-Mar-2021

27
versioned_docs/version-v1.0/cli/vela_help.md Normal file
View File

@ -0,0 +1,27 @@
---
title: vela help
---
Help about any command
```
vela help [command]
```
### Options
```
-h, --help help for help
```
### Options inherited from parent commands
```
-e, --env string specify environment name for application
```
### SEE ALSO
* [vela](vela) -
###### Auto generated by spf13/cobra on 20-Mar-2021

38
versioned_docs/version-v1.0/cli/vela_init.md Normal file
View File

@ -0,0 +1,38 @@
---
title: vela init
---
Create scaffold for an application
### Synopsis
Create scaffold for an application
```
vela init
```
### Examples
```
vela init
```
### Options
```
-h, --help help for init
--render-only Rendering vela.yaml in current dir and do not deploy
```
### Options inherited from parent commands
```
-e, --env string specify environment name for application
```
### SEE ALSO
* [vela](vela) -
###### Auto generated by spf13/cobra on 20-Mar-2021

32
versioned_docs/version-v1.0/cli/vela_logs.md Normal file
View File

@ -0,0 +1,32 @@
---
title: vela logs
---
Tail logs for application
### Synopsis
Tail logs for application
```
vela logs [flags]
```
### Options
```
-h, --help help for logs
-o, --output string output format for logs, support: [default, raw, json] (default "default")
```
### Options inherited from parent commands
```
-e, --env string specify environment name for application
```
### SEE ALSO
* [vela](vela) -
###### Auto generated by spf13/cobra on 20-Mar-2021

38
versioned_docs/version-v1.0/cli/vela_ls.md Normal file
View File

@ -0,0 +1,38 @@
---
title: vela ls
---
List applications
### Synopsis
List all applications in cluster
```
vela ls
```
### Examples
```
vela ls
```
### Options
```
-h, --help help for ls
-n, --namespace string specify the namespace the application want to list, default is the current env namespace
```
### Options inherited from parent commands
```
-e, --env string specify environment name for application
```
### SEE ALSO
* [vela](vela) -
###### Auto generated by spf13/cobra on 20-Mar-2021

40
versioned_docs/version-v1.0/cli/vela_port-forward.md Normal file
View File

@ -0,0 +1,40 @@
---
title: vela port-forward
---
Forward local ports to services in an application
### Synopsis
Forward local ports to services in an application
```
vela port-forward APP_NAME [flags]
```
### Examples
```
port-forward APP_NAME [options] [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N]
```
### Options
```
--address strings Addresses to listen on (comma separated). Only accepts IP addresses or localhost as a value. When localhost is supplied, vela will try to bind on both 127.0.0.1 and ::1 and will fail if neither of these addresses are available to bind. (default [localhost])
-h, --help help for port-forward
--pod-running-timeout duration The length of time (like 5s, 2m, or 3h, higher than zero) to wait until at least one pod is running (default 1m0s)
--route forward ports from route trait service
```
### Options inherited from parent commands
```
-e, --env string specify environment name for application
```
### SEE ALSO
* [vela](vela) -
###### Auto generated by spf13/cobra on 20-Mar-2021

38
versioned_docs/version-v1.0/cli/vela_show.md Normal file
View File

@ -0,0 +1,38 @@
---
title: vela show
---
Show the reference doc for a workload type or trait
### Synopsis
Show the reference doc for a workload type or trait
```
vela show [flags]
```
### Examples
```
show webservice
```
### Options
```
-h, --help help for show
--web start web doc site
```
### Options inherited from parent commands
```
-e, --env string specify environment name for application
```
### SEE ALSO
* [vela](vela) -
###### Auto generated by spf13/cobra on 20-Mar-2021

38
versioned_docs/version-v1.0/cli/vela_status.md Normal file
View File

@ -0,0 +1,38 @@
---
title: vela status
---
Show status of an application
### Synopsis
Show status of an application, including workloads and traits of each service.
```
vela status APP_NAME [flags]
```
### Examples
```
vela status APP_NAME
```
### Options
```
-h, --help help for status
-s, --svc string service name
```
### Options inherited from parent commands
```
-e, --env string specify environment name for application
```
### SEE ALSO
* [vela](vela) -
###### Auto generated by spf13/cobra on 20-Mar-2021

29
versioned_docs/version-v1.0/cli/vela_system.md Normal file
View File

@ -0,0 +1,29 @@
---
title: vela system
---
System management utilities
### Synopsis
System management utilities
### Options
```
-h, --help help for system
```
### Options inherited from parent commands
```
-e, --env string specify environment name for application
```
### SEE ALSO
* [vela](vela) -
* [vela system dry-run](vela_system_dry-run) - Dry Run an application, and output the conversion result to stdout
* [vela system info](vela_system_info) - Show vela client and cluster chartPath
###### Auto generated by spf13/cobra on 20-Mar-2021

35
versioned_docs/version-v1.0/cli/vela_system_cue-packages.md Normal file
View File

@ -0,0 +1,35 @@
## vela system cue-packages
List cue package
### Synopsis
List cue package
```
vela system cue-packages
```
### Examples
```
vela system cue-packages
```
### Options
```
-h, --help help for cue-packages
```
### Options inherited from parent commands
```
-e, --env string specify environment name for application
```
### SEE ALSO
* [vela system](vela_system) - System management utilities
###### Auto generated by spf13/cobra on 2-May-2021

38
versioned_docs/version-v1.0/cli/vela_system_dry-run.md Normal file
View File

@ -0,0 +1,38 @@
---
title: vela system dry-run
---
Dry Run an application, and output the conversion result to stdout
### Synopsis
Dry Run an application, and output the conversion result to stdout
```
vela system dry-run
```
### Examples
```
vela dry-run
```
### Options
```
-f, --file string application file name (default "./app.yaml")
-h, --help help for dry-run
```
### Options inherited from parent commands
```
-e, --env string specify environment name for application
```
### SEE ALSO
* [vela system](vela_system) - System management utilities
###### Auto generated by spf13/cobra on 20-Mar-2021

31
versioned_docs/version-v1.0/cli/vela_system_info.md Normal file
View File

@ -0,0 +1,31 @@
---
title: vela system info
---
Show vela client and cluster chartPath
### Synopsis
Show vela client and cluster chartPath
```
vela system info [flags]
```
### Options
```
-h, --help help for info
```
### Options inherited from parent commands
```
-e, --env string specify environment name for application
```
### SEE ALSO
* [vela system](vela_system) - System management utilities
###### Auto generated by spf13/cobra on 20-Mar-2021

39
versioned_docs/version-v1.0/cli/vela_system_live-diff.md Normal file
View File

@ -0,0 +1,39 @@
## vela system live-diff
Dry-run an application, and do diff on a specific app revison
### Synopsis
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.
```
vela system live-diff
```
### Examples
```
vela live-diff -f app-v2.yaml -r app-v1 --context 10
```
### Options
```
-r, --Revision string specify an application Revision name, by default, it will compare with the latest Revision
-c, --context int output number lines of context around changes, by default show all unchanged lines (default -1)
-d, --definition string specify a file or directory containing capability definitions, they will only be used in dry-run rather than applied to K8s cluster
-f, --file string application file name (default "./app.yaml")
-h, --help help for live-diff
```
### Options inherited from parent commands
```
-e, --env string specify environment name for application
```
### SEE ALSO
* [vela system](vela_system) - System management utilities
###### Auto generated by spf13/cobra on 2-May-2021

28
versioned_docs/version-v1.0/cli/vela_template.md Normal file
View File

@ -0,0 +1,28 @@
---
title: vela template
---
Manage templates
### Synopsis
Manage templates
### Options
```
-h, --help help for template
```
### Options inherited from parent commands
```
-e, --env string specify environment name for application
```
### SEE ALSO
* [vela](vela) -
* [vela template context](vela_template_context) - Show context parameters
###### Auto generated by spf13/cobra on 20-Mar-2021

37
versioned_docs/version-v1.0/cli/vela_template_context.md Normal file
View File

@ -0,0 +1,37 @@
---
title: vela template context
---
Show context parameters
### Synopsis
Show context parameter
```
vela template context
```
### Examples
```
vela template context
```
### Options
```
-h, --help help for context
```
### Options inherited from parent commands
```
-e, --env string specify environment name for application
```
### SEE ALSO
* [vela template](vela_template) - Manage templates
###### Auto generated by spf13/cobra on 20-Mar-2021

37
versioned_docs/version-v1.0/cli/vela_traits.md Normal file
View File

@ -0,0 +1,37 @@
---
title: vela traits
---
List traits
### Synopsis
List traits
```
vela traits
```
### Examples
```
vela traits
```
### Options
```
-h, --help help for traits
```
### Options inherited from parent commands
```
-e, --env string specify environment name for application
```
### SEE ALSO
* [vela](vela) -
###### Auto generated by spf13/cobra on 20-Mar-2021

32
versioned_docs/version-v1.0/cli/vela_up.md Normal file
View File

@ -0,0 +1,32 @@
---
title: vela up
---
Apply an appfile
### Synopsis
Apply an appfile
```
vela up
```
### Options
```
-f, -- string specify file path for appfile
-h, --help help for up
```
### Options inherited from parent commands
```
-e, --env string specify environment name for application
```
### SEE ALSO
* [vela](vela) -
###### Auto generated by spf13/cobra on 20-Mar-2021

31
versioned_docs/version-v1.0/cli/vela_version.md Normal file
View File

@ -0,0 +1,31 @@
---
title: vela version
---
Prints out build version information
### Synopsis
Prints out build version information
```
vela version [flags]
```
### Options
```
-h, --help help for version
```
### Options inherited from parent commands
```
-e, --env string specify environment name for application
```
### SEE ALSO
* [vela](vela) -
###### Auto generated by spf13/cobra on 20-Mar-2021

37
versioned_docs/version-v1.0/cli/vela_workloads.md Normal file
View File

@ -0,0 +1,37 @@
---
title: vela workloads
---
List workloads
### Synopsis
List workloads
```
vela workloads
```
### Examples
```
vela workloads
```
### Options
```
-h, --help help for workloads
```
### Options inherited from parent commands
```
-e, --env string specify environment name for application
```
### SEE ALSO
* [vela](vela) -
###### Auto generated by spf13/cobra on 20-Mar-2021

46
versioned_docs/version-v1.0/concepts.md Normal file
View File

@ -0,0 +1,46 @@
---
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:
![alt](resources/concepts.png)
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:
![alt](resources/how-it-works.png)
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.

152
versioned_docs/version-v1.0/developers/cap-center.md Normal file
View File

@ -0,0 +1,152 @@
---
title: Managing Capabilities
---
In KubeVela, developers can install more capabilities (i.e. new component types and traits) from any GitHub repo that contains OAM definition files. We call these GitHub repos as _Capability Centers_.
KubeVela is able to discover OAM definition files in this repo automatically and sync them to your own KubeVela platform.
## Add a capability center
Add and sync a capability center in KubeVela:
```bash
vela cap center config my-center https://github.com/oam-dev/catalog/tree/master/registry
```
```console
successfully sync 1/1 from my-center remote center
Successfully configured capability center my-center and sync from remote
```
```bash
vela cap center sync my-center
```
```console
successfully sync 1/1 from my-center remote center
sync finished
```
Now, this capability center `my-center` is ready to use.
## List capability centers
You are allowed to add more capability centers and list them.
```bash
vela cap center ls
```
```console
NAME ADDRESS
my-center https://github.com/oam-dev/catalog/tree/master/registry
```
## [Optional] Remove a capability center
Or, remove one.
```bash
vela cap center remove my-center
```
## List all available capabilities in capability center
Or, list all available capabilities in certain center.
```bash
vela cap ls my-center
```
```console
NAME CENTER TYPE DEFINITION STATUS APPLIES-TO
clonesetservice my-center componentDefinition clonesets.apps.kruise.io uninstalled []
```
## Install a capability from capability center
Now let's try to install the new component named `clonesetservice` from `my-center` to your own KubeVela platform.
You need to install OpenKruise first.
```shell
helm install kruise https://github.com/openkruise/kruise/releases/download/v0.7.0/kruise-chart.tgz
```
Install `clonesetservice` component from `my-center`.
```bash
vela cap install my-center/clonesetservice
```
```console
Installing component capability clonesetservice
Successfully installed capability clonesetservice from my-center
```
## Use the newly installed capability
Let's check the `clonesetservice` appears in your platform firstly:
```bash
vela components
```
```console
NAME NAMESPACE WORKLOAD DESCRIPTION
clonesetservice vela-system clonesets.apps.kruise.io Describes long-running, scalable, containerized services
that have a stable network endpoint to receive external
network traffic from customers. If workload type is skipped
for any service defined in Appfile, it will be defaulted to
`webservice` type.
```
Great! Now let's deploy an app via Appfile.
```bash
cat << EOF > vela.yaml
name: testapp
services:
testsvc:
type: clonesetservice
image: crccheck/hello-world
port: 8000
EOF
```
```bash
vela up
```
```console
Parsing vela appfile ...
Load Template ...
Rendering configs for service (testsvc)...
Writing deploy config to (.vela/deploy.yaml)
Applying application ...
Checking if app has been deployed...
App has not been deployed, creating a new deployment...
Updating: core.oam.dev/v1alpha2, Kind=HealthScope in default
✅ App has been deployed 🚀🚀🚀
Port forward: vela port-forward testapp
SSH: vela exec testapp
Logging: vela logs testapp
App status: vela status testapp
Service status: vela status testapp --svc testsvc
```
then you can Get a cloneset in your environment.
```shell
kubectl get clonesets.apps.kruise.io
```
```console
NAME DESIRED UPDATED UPDATED_READY READY TOTAL AGE
testsvc 1 1 1 1 1 46s
```
## Uninstall a capability
> NOTE: make sure no apps are using the capability before uninstalling.
```bash
vela cap uninstall my-center/clonesetservice
```
```console
Successfully uninstalled capability clonesetservice
```

Some files were not shown because too many files have changed in this diff Show More