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

sync commit 2c9cf94817aafc88a02f328364534a728cb71d90 from kubevela-v1.0.6

This commit is contained in:
kubevela-bot 2021-06-08 11:45:06 +00:00
parent ac8ea9df84
commit 6f65aa5d1e
99 changed files with 1635 additions and 726 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

0
0 Normal file
View File

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>

34
docs/end-user/scopes/appdeploy.md
View File

@ -105,7 +105,7 @@ You must run all commands in that directory.
1. Create an Application
```bash
$ cat <<EOF | kubectl apply -f -
cat <<EOF | kubectl apply -f -
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
@ -126,7 +126,9 @@ You must run all commands in that directory.
This will create `example-app-v1` AppRevision. Check it:
```bash
$ kubectl get applicationrevisions.core.oam.dev
kubectl get applicationrevisions.core.oam.dev
```
```console
NAME AGE
example-app-v1 116s
```
@ -136,7 +138,7 @@ You must run all commands in that directory.
1. Then use the above AppRevision to create an AppDeployment.
```bash
$ kubectl apply -f appdeployment-1.yaml
kubectl apply -f appdeployment-1.yaml
```
> Note: in order to AppDeployment to work, your workload object must have a `spec.replicas` field for scaling.
@ -144,7 +146,9 @@ You must run all commands in that directory.
1. Now you can check that there will 1 deployment and 2 pod instances deployed
```bash
$ kubectl get deploy
kubectl get deploy
```
```console
NAME READY UP-TO-DATE AVAILABLE AGE
testsvc-v1 2/2 2 0 27s
```
@ -152,7 +156,7 @@ You must run all commands in that directory.
1. Update Application properties:
```bash
$ cat <<EOF | kubectl apply -f -
cat <<EOF | kubectl apply -f -
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
@ -173,7 +177,9 @@ You must run all commands in that directory.
This will create a new `example-app-v2` AppRevision. Check it:
```bash
$ kubectl get applicationrevisions.core.oam.dev
kubectl get applicationrevisions.core.oam.dev
```
```console
NAME
example-app-v1
example-app-v2
@ -182,16 +188,16 @@ You must run all commands in that directory.
1. Then use the two AppRevisions to update the AppDeployment:
```bash
$ kubectl apply -f appdeployment-2.yaml
kubectl apply -f appdeployment-2.yaml
```
(Optional) If you have Istio installed, you can apply the AppDeployment with traffic split:
```bash
# set up gateway if not yet
$ kubectl apply -f gateway.yaml
kubectl apply -f gateway.yaml
$ kubectl apply -f appdeployment-2-traffic.yaml
kubectl apply -f appdeployment-2-traffic.yaml
```
Note that for traffic split to work, your must set the following pod labels in workload cue templates (see [webservice.cue](https://github.com/oam-dev/kubevela/blob/master/hack/vela-templates/cue/webservice.cue)):
@ -204,7 +210,9 @@ You must run all commands in that directory.
1. Now you can check that there will 1 deployment and 1 pod per revision.
```bash
$ kubectl get deploy
kubectl get deploy
```
```console
NAME READY UP-TO-DATE AVAILABLE AGE
testsvc-v1 1/1 1 1 2m14s
testsvc-v2 1/1 1 1 8s
@ -214,7 +222,9 @@ You must run all commands in that directory.
```bash
# run this in another terminal
$ kubectl -n istio-system port-forward service/istio-ingressgateway 8080:80
kubectl -n istio-system port-forward service/istio-ingressgateway 8080:80
```
```console
Forwarding from 127.0.0.1:8080 -> 8080
Forwarding from [::1]:8080 -> 8080
@ -225,6 +235,6 @@ You must run all commands in that directory.
1. Cleanup:
```bash
kubectl delete appdeployments.core.oam.dev --all
kubectl delete appdeployments.core.oam.dev --all
kubectl delete applications.core.oam.dev --all
```

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

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.

23
docs/introduction.md
View File

@ -8,17 +8,17 @@ 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 hybrid 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 system level design and implementation.
## 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 introducing another layer of restriction. 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 consistent yet higher level API to capture a full deployment of microservices on top of hybrid environments. No infrastructure level concern, 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 uses [CUE](https://cuelang.org/) as super glue to assemble capabilities provided by runtime infrastructures and expose them to users via application-centric APIs. When users' needs grow, these APIs can naturally expand in programmable approach.
**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.
@ -44,7 +44,7 @@ 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.
KubeVela enables you to serve end users with programmable building blocks (based on CUE) 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.
@ -52,26 +52,23 @@ So think of KubeVela as a Heroku but it is fully extensible when your needs grow
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. Simply register them as a "component" in KubeVela platform.
### 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 manage applications across hybrid environments leveraging KubeVela as core deployment engine.
### 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 also leverages Helm to manage the capability addons in runtime clusters.
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, attach traits to the chart, or distribute the chart to multiple clusters. KubeVela itself also leverages Helm to manage the capability addons in runtime Kubernetes clusters.
### 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.

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

@ -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.

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

@ -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:

38
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
@ -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)
---

20
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`
@ -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"
```

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

@ -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"
```

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

@ -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:

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

@ -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

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

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

39
versioned_docs/version-v1.0/advanced-install.md → versioned_docs/version-v1.0/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
versioned_docs/version-v1.0/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
versioned_docs/version-v1.0/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
versioned_docs/version-v1.0/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
versioned_docs/version-v1.0/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
versioned_docs/version-v1.0/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
versioned_docs/version-v1.0/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
versioned_docs/version-v1.0/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
versioned_docs/version-v1.0/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
versioned_docs/version-v1.0/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
versioned_docs/version-v1.0/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
versioned_docs/version-v1.0/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
versioned_docs/version-v1.0/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
versioned_docs/version-v1.0/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
versioned_docs/version-v1.0/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
versioned_docs/version-v1.0/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>

34
versioned_docs/version-v1.0/end-user/scopes/appdeploy.md
View File

@ -105,7 +105,7 @@ You must run all commands in that directory.
1. Create an Application
```bash
$ cat <<EOF | kubectl apply -f -
cat <<EOF | kubectl apply -f -
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
@ -126,7 +126,9 @@ You must run all commands in that directory.
This will create `example-app-v1` AppRevision. Check it:
```bash
$ kubectl get applicationrevisions.core.oam.dev
kubectl get applicationrevisions.core.oam.dev
```
```console
NAME AGE
example-app-v1 116s
```
@ -136,7 +138,7 @@ You must run all commands in that directory.
1. Then use the above AppRevision to create an AppDeployment.
```bash
$ kubectl apply -f appdeployment-1.yaml
kubectl apply -f appdeployment-1.yaml
```
> Note: in order to AppDeployment to work, your workload object must have a `spec.replicas` field for scaling.
@ -144,7 +146,9 @@ You must run all commands in that directory.
1. Now you can check that there will 1 deployment and 2 pod instances deployed
```bash
$ kubectl get deploy
kubectl get deploy
```
```console
NAME READY UP-TO-DATE AVAILABLE AGE
testsvc-v1 2/2 2 0 27s
```
@ -152,7 +156,7 @@ You must run all commands in that directory.
1. Update Application properties:
```bash
$ cat <<EOF | kubectl apply -f -
cat <<EOF | kubectl apply -f -
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
@ -173,7 +177,9 @@ You must run all commands in that directory.
This will create a new `example-app-v2` AppRevision. Check it:
```bash
$ kubectl get applicationrevisions.core.oam.dev
kubectl get applicationrevisions.core.oam.dev
```
```console
NAME
example-app-v1
example-app-v2
@ -182,16 +188,16 @@ You must run all commands in that directory.
1. Then use the two AppRevisions to update the AppDeployment:
```bash
$ kubectl apply -f appdeployment-2.yaml
kubectl apply -f appdeployment-2.yaml
```
(Optional) If you have Istio installed, you can apply the AppDeployment with traffic split:
```bash
# set up gateway if not yet
$ kubectl apply -f gateway.yaml
kubectl apply -f gateway.yaml
$ kubectl apply -f appdeployment-2-traffic.yaml
kubectl apply -f appdeployment-2-traffic.yaml
```
Note that for traffic split to work, your must set the following pod labels in workload cue templates (see [webservice.cue](https://github.com/oam-dev/kubevela/blob/master/hack/vela-templates/cue/webservice.cue)):
@ -204,7 +210,9 @@ You must run all commands in that directory.
1. Now you can check that there will 1 deployment and 1 pod per revision.
```bash
$ kubectl get deploy
kubectl get deploy
```
```console
NAME READY UP-TO-DATE AVAILABLE AGE
testsvc-v1 1/1 1 1 2m14s
testsvc-v2 1/1 1 1 8s
@ -214,7 +222,9 @@ You must run all commands in that directory.
```bash
# run this in another terminal
$ kubectl -n istio-system port-forward service/istio-ingressgateway 8080:80
kubectl -n istio-system port-forward service/istio-ingressgateway 8080:80
```
```console
Forwarding from 127.0.0.1:8080 -> 8080
Forwarding from [::1]:8080 -> 8080
@ -225,6 +235,6 @@ You must run all commands in that directory.
1. Cleanup:
```bash
kubectl delete appdeployments.core.oam.dev --all
kubectl delete appdeployments.core.oam.dev --all
kubectl delete applications.core.oam.dev --all
```

4
versioned_docs/version-v1.0/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

12
versioned_docs/version-v1.0/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
versioned_docs/version-v1.0/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
versioned_docs/version-v1.0/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
versioned_docs/version-v1.0/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
versioned_docs/version-v1.0/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
versioned_docs/version-v1.0/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
versioned_docs/version-v1.0/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
versioned_docs/version-v1.0/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.

23
versioned_docs/version-v1.0/introduction.md
View File

@ -8,17 +8,17 @@ 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 hybrid 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 system level design and implementation.
## 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 introducing another layer of restriction. 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 consistent yet higher level API to capture a full deployment of microservices on top of hybrid environments. No infrastructure level concern, 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 uses [CUE](https://cuelang.org/) as super glue to assemble capabilities provided by runtime infrastructures and expose them to users via application-centric APIs. When users' needs grow, these APIs can naturally expand in programmable approach.
**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.
@ -44,7 +44,7 @@ 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.
KubeVela enables you to serve end users with programmable building blocks (based on CUE) 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.
@ -52,26 +52,23 @@ So think of KubeVela as a Heroku but it is fully extensible when your needs grow
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. Simply register them as a "component" in KubeVela platform.
### 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 manage applications across hybrid environments leveraging KubeVela as core deployment engine.
### 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 also leverages Helm to manage the capability addons in runtime clusters.
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, attach traits to the chart, or distribute the chart to multiple clusters. KubeVela itself also leverages Helm to manage the capability addons in runtime Kubernetes clusters.
### 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
versioned_docs/version-v1.0/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
versioned_docs/version-v1.0/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.

42
versioned_docs/version-v1.0/platform-engineers/cue/basic.md
View File

@ -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
versioned_docs/version-v1.0/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.

102
versioned_docs/version-v1.0/platform-engineers/cue/patch-trait.md
View File

@ -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:

38
versioned_docs/version-v1.0/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
@ -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)
---

20
versioned_docs/version-v1.0/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`
@ -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
versioned_docs/version-v1.0/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"
```

32
versioned_docs/version-v1.0/platform-engineers/helm/trait.md
View File

@ -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
versioned_docs/version-v1.0/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
versioned_docs/version-v1.0/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"
```

24
versioned_docs/version-v1.0/platform-engineers/kube/trait.md
View File

@ -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
versioned_docs/version-v1.0/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:

6
versioned_docs/version-v1.0/platform-engineers/overview.md
View File

@ -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
versioned_docs/version-v1.0/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
versioned_docs/version-v1.0/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
versioned_docs/version-v1.0/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

5
versioned_docs/version-v1.0/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
versioned_docs/version-v1.0/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
versioned_docs/version-v1.0/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
versioned_docs/version-v1.0/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).

6
versioned_sidebars/version-v1.0-sidebars.json
View File

@ -397,6 +397,10 @@
"id": "version-v1.0/cli/vela_cap"
}
]
},
{
"type": "doc",
"id": "version-v1.0/developers/references/kubectl-plugin"
}
]
},
@ -407,7 +411,7 @@
"items": [
{
"type": "doc",
"id": "version-v1.0/roadmap"
"id": "version-v1.0/roadmap/README"
}
]
},