sync commit 61d7aff01c2020c9994fac085006c34a855da6c9 from kubevela-v1.1.0-alpha.3
This commit is contained in:
kubevela-bot
parent
73da31fdb8
commit
feeff8d013
|
|
@ -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,32 +4,15 @@ title: How it Works
|
|||
|
||||
In this documentation, we will explain the core idea of KubeVela and clarify some technical terms that are widely used in the project.
|
||||
|
||||
## Architecture
|
||||
|
||||
The overall architecture of KubeVela is shown as below:
|
||||
|
||||
|
||||
|
||||
### Control Plane Cluster
|
||||
|
||||
The main part of KubeVela. It is the component that users will interact with and where the KubeVela controllers are running on. Control plane cluster will deploy the application to multiple *runtime clusters*.
|
||||
|
||||
### Runtime Clusters
|
||||
|
||||
Runtime clusters are where the applications are actually running on. The needed addons in runtime cluster are automatically discovered and installed with leverage of [CRD Lifecycle Management (CLM)](https://github.com/cloudnativeapp/CLM).
|
||||
|
||||
|
||||
## API
|
||||
|
||||
On control plane cluster, KubeVela introduces [Open Application Model (OAM)](https://oam.dev) as the higher level API. Hence users of KubeVela only work on application level with a consistent experience, regardless of the complexity of heterogeneous runtime environments.
|
||||
|
||||
This API could be explained as below:
|
||||
On control plane, KubeVela introduces [Open Application Model (OAM)](https://oam.dev) as the main API to model a full deployment of modern microservices application. This API could be explained as below:
|
||||
|
||||
|
||||
|
||||
In detail:
|
||||
- Components - deployable/provisionable entities that compose your application.
|
||||
- e.g. a Helm chart, a Kubernetes workload, a CUE or Terraform module, or a cloud database instance etc.
|
||||
- e.g. a Helm chart, a Kubernetes workload, a Terraform module, or a cloud database instance etc.
|
||||
- Traits - attachable features that will *overlay* given component with operational behaviors.
|
||||
- e.g. autoscaling rules, rollout strategies, ingress rules, sidecars, security policies etc.
|
||||
- Application - full description of your application deployment assembled with components and traits.
|
||||
|
|
@ -45,24 +28,19 @@ To ensure simple yet consistent user experience across hybrid environments. Kube
|
|||
- **Application Team**
|
||||
- Choose a environment, assemble the application with components and traits per needs, and deploy it to target environment.
|
||||
|
||||
> Note that either platform team or application team application will only talk to the control plane cluster. KubeVela is designed to hide the details of runtime clusters except for debugging or verifying purpose.
|
||||
> Note that either platform team or application team application will only talk to the control plane cluster. KubeVela is designed to hide the details of runtime infrastructures except for debugging or verifying purpose.
|
||||
|
||||
Below is how this workflow looks like:
|
||||
|
||||
|
||||
|
||||
All the capability building blocks can be updated or extended easily at any time since they are fully programmable (currently support CUE, Terraform and Helm).
|
||||
All the capability building blocks can be updated or extended easily at any time since they are fully programmable via CUE.
|
||||
|
||||
## Environment
|
||||
Before releasing an application to production, it's important to test the code in testing/staging workspaces. In KubeVela, we describe these workspaces as "environments". Each environment has its own configuration (e.g., domain, Kubernetes cluster and namespace, configuration data, access control policy, etc.) to allow user to create different deployment environments such as "test" and "production".
|
||||
|
||||
Currently, a KubeVela `environment` only maps to a Kubernetes namespace. In the future, a `environment` will contain multiple clusters.
|
||||
|
||||
## What's Next
|
||||
|
||||
Here are some recommended next steps:
|
||||
|
||||
- Learn how to [deploy an application](end-user/application) and understand how it works.
|
||||
- Join `#kubevela` channel in CNCF [Slack](https://cloud-native.slack.com) and/or [Gitter](https://gitter.im/oam-dev/community)
|
||||
|
||||
Welcome onboard and sail Vela!
|
||||
- Learn how to [deploy an application](end-user/application) in detail and understand how it works.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
```
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
```
|
||||
|
|
|
|||
|
|
@ -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
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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`.
|
||||
|
|
|
|||
|
|
@ -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,7 +15,9 @@ 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
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
```
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
```
|
||||
|
|
@ -2,7 +2,7 @@
|
|||
title: Application
|
||||
---
|
||||
|
||||
This documentation will walk through how to use KubeVela to design a simple application without any placement rule.
|
||||
This documentation will walk through how to use KubeVela to design a simple application without any polices or placement rule defined.
|
||||
|
||||
> Note: since you didn't declare placement rule, KubeVela will deploy this application directly to the control plane cluster (i.e. the cluster your `kubectl` is talking to). This is also the same case if you are using local cluster such as KinD or MiniKube to play KubeVela.
|
||||
|
||||
|
|
@ -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,18 +77,22 @@ 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] configure k8s HPA with CPU metrics for Deployment
|
||||
ingress [webservice worker] Configures K8s ingress and service to enable web traffic for your service. Please use route trait in cap center for advanced usage.
|
||||
scaler [webservice worker] Configures replicas for your service.
|
||||
sidecar [webservice worker] inject a sidecar container into your app
|
||||
cpuscaler [webservice worker] Automatically scale the component based on CPU usage.
|
||||
ingress [webservice worker] Enable public web traffic for the component.
|
||||
scaler [webservice worker] Manually scale the component.
|
||||
sidecar [webservice worker] Inject a sidecar container to the component.
|
||||
```
|
||||
|
||||
Let's check the specification of `sidecar` trait.
|
||||
|
||||
```shell
|
||||
$ kubectl vela show sidecar
|
||||
kubectl vela show sidecar
|
||||
```
|
||||
```console
|
||||
# Properties
|
||||
+---------+-----------------------------------------+----------+----------+---------+
|
||||
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
|
||||
|
|
@ -116,7 +124,7 @@ spec:
|
|||
properties:
|
||||
image: nginx
|
||||
traits:
|
||||
- type: cpuscaler # Assign a HPA to scale the component by CPU usage
|
||||
- type: cpuscaler # Automatically scale the component by CPU usage after deployed
|
||||
properties:
|
||||
min: 1
|
||||
max: 10
|
||||
|
|
@ -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,54 +226,11 @@ 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
|
||||
```
|
||||
|
||||
Furthermore, the system will decide how to/whether to rollout the application based on the attached [rollout plan](scopes/rollout-plan).
|
||||
|
||||
### Verify
|
||||
<details>
|
||||
|
||||
On the runtime cluster, you could see a Kubernetes Deployment named `frontend` is running, with port exposed, and with a container `fluentd` injected.
|
||||
|
||||
```shell
|
||||
$ kubectl get deploy frontend
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
frontend 1/1 1 1 97s
|
||||
```
|
||||
|
||||
```shell
|
||||
$ kubectl get deploy frontend -o yaml
|
||||
...
|
||||
spec:
|
||||
containers:
|
||||
- image: nginx
|
||||
imagePullPolicy: Always
|
||||
name: frontend
|
||||
ports:
|
||||
- containerPort: 80
|
||||
protocol: TCP
|
||||
- image: fluentd
|
||||
imagePullPolicy: Always
|
||||
name: sidecar-test
|
||||
...
|
||||
```
|
||||
|
||||
Another Deployment is also running named `backend`.
|
||||
|
||||
```shell
|
||||
$ kubectl get deploy backend
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
backend 1/1 1 1 111s
|
||||
```
|
||||
|
||||
An HPA was also created by the `cpuscaler` trait.
|
||||
|
||||
```shell
|
||||
$ kubectl get HorizontalPodAutoscaler frontend
|
||||
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
|
||||
frontend Deployment/frontend <unknown>/50% 1 10 1 101m
|
||||
```
|
||||
</details>
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
```
|
||||
|
|
|
|||
|
|
@ -4,10 +4,9 @@ title: Advanced Rollout Plan
|
|||
|
||||
The rollout plan feature in KubeVela is essentially provided by `AppRollout` API.
|
||||
|
||||
## AppRollout
|
||||
## AppRollout Specification
|
||||
|
||||
Below is an example for rolling update an application from v1 to v2 in three batches. The
|
||||
first batch contains only 1 pod while the rest of the batches split the rest.
|
||||
The following describes all the available fields of a AppRollout:
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
|
|
@ -15,18 +14,55 @@ kind: AppRollout
|
|||
metadata:
|
||||
name: rolling-example
|
||||
spec:
|
||||
# SourceAppRevisionName contains the name of the appRevisionName that we need to upgrade from.
|
||||
# it can be empty only when you want to scale an application. +optional
|
||||
sourceAppRevisionName: test-rolling-v1
|
||||
|
||||
# TargetAppRevisionName contains the name of the appRevisionName that we need to upgrade to.
|
||||
targetAppRevisionName: test-rolling-v2
|
||||
|
||||
# The list of component to upgrade in the application.
|
||||
# We only support single component application so far. +optional
|
||||
componentList:
|
||||
- metrics-provider
|
||||
# RolloutPlan is the details on how to rollout the resources
|
||||
rolloutPlan:
|
||||
|
||||
# RolloutStrategy defines strategies for the rollout plan
|
||||
# the value can be IncreaseFirst or DecreaseFirst
|
||||
# Defaults to IncreaseFirst. +optional
|
||||
rolloutStrategy: "IncreaseFirst"
|
||||
|
||||
# The exact distribution among batches.
|
||||
# its size has to be exactly the same as the NumBatches (if set)
|
||||
# The total number cannot exceed the targetSize or the size of the source resource
|
||||
# We will IGNORE the last batch's replica field if it's a percentage since round errors can lead to inaccurate sum
|
||||
# We highly recommend to leave the last batch's replica field empty
|
||||
rolloutBatches:
|
||||
|
||||
# Replicas is the number of pods to upgrade in this batch
|
||||
# it can be an absolute number (ex: 5) or a percentage of total pods
|
||||
# we will ignore the percentage of the last batch to just fill the gap
|
||||
# Below is an example the first batch contains only 1 pod while the rest of the batches split the rest.
|
||||
- replicas: 1
|
||||
- replicas: 50%
|
||||
- replicas: 50%
|
||||
|
||||
# All pods in the batches up to the batchPartition (included) will have
|
||||
# the target resource specification while the rest still have the source resource
|
||||
# This is designed for the operators to manually rollout
|
||||
# Default is the the number of batches which will rollout all the batches. +optional
|
||||
batchPartition: 1
|
||||
|
||||
# Paused the rollout
|
||||
# defaults to false. +optional
|
||||
paused: false
|
||||
|
||||
# The size of the target resource. In rollout operation it's the same as the size of the source resource.
|
||||
# when use rollout to scale an application targetSize is the target source you want scale to. +optional
|
||||
targetSize: 4
|
||||
```
|
||||
|
||||
## Basic Usage
|
||||
|
||||
1. Deploy application
|
||||
|
|
@ -76,7 +112,7 @@ spec:
|
|||
- replicas: 50%
|
||||
targetSize: 5
|
||||
```
|
||||
Use can check the status of the ApplicationRollout and wait for the rollout to complete.
|
||||
User can check the status of the ApplicationRollout and wait for the rollout to complete.
|
||||
|
||||
3. User can continue to modify the application image tag and apply.This will generate new AppRevision `test-rolling-v2`
|
||||
```yaml
|
||||
|
|
@ -207,6 +243,39 @@ Using `AppRollout` separately can enable some advanced use case.
|
|||
- replicas: 2
|
||||
```
|
||||
|
||||
### Scale the application
|
||||
|
||||
Before using AppRollout to scale an application, we must be aware of the real status of workload now. Check the workload status.
|
||||
|
||||
```shell
|
||||
$ kubectl get deploy metrics-provider-v3
|
||||
NAME READY UP-TO-DATE AVAILABLE AGE
|
||||
metrics-provider-v3 5/5 5 5 10m
|
||||
```
|
||||
|
||||
Last target appRevision is `test-rolling-v3` and the workload have 5 replicas currently.
|
||||
|
||||
8. Apply the appRollout increase the replicas nums of workload to 7.
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: AppRollout
|
||||
metadata:
|
||||
name: rolling-example
|
||||
spec:
|
||||
# sourceAppRevisionName is empty means this is a scale operation
|
||||
targetAppRevisionName: test-rolling-v3
|
||||
componentList:
|
||||
- metrics-provider
|
||||
rolloutPlan:
|
||||
rolloutStrategy: "IncreaseFirst"
|
||||
rolloutBatches:
|
||||
# split two batches to scale. First batch increase 1 pod and second increase 1.
|
||||
- replicas: 1
|
||||
- replicas: 1
|
||||
# targetSize means that final total size of workload is 7
|
||||
targetSize: 7
|
||||
```
|
||||
|
||||
## More Details About `AppRollout`
|
||||
|
||||
### Design Principles and Goals
|
||||
|
|
@ -227,7 +296,6 @@ We design KubeVela rollout solutions with the following principles in mind
|
|||
- Finally, the controllers can support all the rollout/upgrade needs of an application running
|
||||
in a production environment including Blue/Green, Canary and A/B testing.
|
||||
|
||||
|
||||
### State Transition
|
||||
Here is the high level state transition graph
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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"}
|
||||
```
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -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,14 +50,18 @@ 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
|
||||
|
|
|
|||
|
|
@ -2,57 +2,10 @@
|
|||
title: Service Binding
|
||||
---
|
||||
|
||||
# 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 | |
|
||||
+-------------+------------------------------------------------+------------------+----------+---------+
|
||||
```
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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 |
|
||||
+-----------+----------------------------------------------------------------+--------+----------+---------+
|
||||
|
|
|
|||
|
|
@ -5,17 +5,17 @@ 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 Kubernetes Cluster
|
||||
## 1. Choose Control Plane Cluster
|
||||
|
||||
Requirements:
|
||||
- Kubernetes cluster >= v1.15.0
|
||||
- `kubectl` installed and configured
|
||||
|
||||
KubeVela is a simple custom controller that can be installed on any Kubernetes cluster including managed offerings or your own clusters. The only requirement is please ensure [ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/) is installed and enabled.
|
||||
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"
|
||||
|
|
|
|||
|
|
@ -8,66 +8,74 @@ 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 abstraction layer. Kubernetes, although excellent in abstracting low-level infrastructure details, does introduce extra complexity to application developers, namely understanding the concepts of pods, port exposing, privilege escalation, resource claims, CRD, and so on. We’ve seen the nontrivial learning curve and the lack of developer-facing abstraction have impacted user experiences, slowed down productivity, led to unexpected errors or misconfigurations in production. People start to question the value of this revolution: "why am I bothered with all these details?".
|
||||
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, abstracting Kubernetes to serve developers' requirements is a highly opinionated process, and the resultant abstractions would only make sense had the decision makers been the platform team. Unfortunately, the platform team today face the following dilemma:
|
||||
|
||||
*There is no tool or framework for them to build user friendly yet highly extensible abstractions for application management*.
|
||||
|
||||
Thus, many application platforms today are essentially restricted abstractions with in-house add-on mechanisms despite the extensibility of Kubernetes. This makes extending such platforms for developers' requirements or to wider scenarios almost impossible, not to mention taking the full advantage of the rich Kubernetes ecosystems.
|
||||
|
||||
In the end, developers complain those platforms 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?
|
||||
|
||||
For platform team, KubeVela serves as a framework that relieves the pains of building modern application platforms 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.
|
||||
|
||||
With KubeVela, the platform team finally have the tooling supports to design easy-to-use application platform with high confidence and low turn around time.
|
||||
## Architecture
|
||||
|
||||
For end-users (e.g. application team), this platform will enable them to design and ship applications to hybrid environments with minimal effort, and instead of managing a handful infrastructure details, a simple application definition that can be easily integrated with any CI/CD pipeline is all they need.
|
||||
The overall architecture of KubeVela is shown as below:
|
||||
|
||||
|
||||
|
||||
### Control Plane
|
||||
|
||||
Control plane is where KubeVela itself lives in. As the project's name implies, KubeVela by design leverages Kubernetes as control plane. This is the key of how KubeVela brings full *automation* and strong *determinism* to application delivery at scale. Users will interact with KubeVela via the application centric API to model the application deployment, and KubeVela will distribute it to target *runtime infrastructure* per policies and rules declared by users.
|
||||
|
||||
### Runtime Infrastructures
|
||||
|
||||
Runtime infrastructures are where the applications are actually running on. KubeVela allows you to model and deploy applications to any Kubernetes based infrastructure (either local, managed offerings, or IoT/Edge/On-Premise ones), or to public cloud platforms.
|
||||
|
||||
## Comparisons
|
||||
|
||||
### KubeVela vs. Platform-as-a-Service (PaaS)
|
||||
|
||||
The typical examples are Heroku and Cloud Foundry. They provide full application management capabilities and aim to improve developer experience and efficiency. In this context, KubeVela shares the same goal.
|
||||
The typical examples are Heroku and Cloud Foundry. They provide full application deployment and management capabilities and aim to improve developer experience and efficiency. In this context, KubeVela shares the same goal.
|
||||
|
||||
Though the biggest difference lies in **flexibility**.
|
||||
|
||||
KubeVela enables you to serve end users with programmable building blocks which are fully flexible and coded by yourself. 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 that is fully extensible to serve your needs as you grow.
|
||||
So think of KubeVela as a Heroku but it is fully extensible when your needs grow.
|
||||
|
||||
### KubeVela vs. Serverless
|
||||
|
||||
Serverless platform such as AWS Lambda provides extraordinary user experience and agility to deploy serverless applications. However, those platforms impose even more constraints in extensibility. They are arguably "hard-coded" PaaS.
|
||||
|
||||
KubeVela can easily deploy Kubernetes based serverless workloads such as Knative, OpenFaaS by referencing them as new components. Even for AWS Lambda, KubeVela can also deploy such workload leveraging Terraform based 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 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. A common example is 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.
|
||||
|
||||
## Getting Started
|
||||
## What's Next
|
||||
|
||||
Now let's [get started](./quick-start) with KubeVela!
|
||||
Here are some recommended next steps:
|
||||
- [Get started](./quick-start) with KubeVela.
|
||||
- Learn KubeVela's [core concepts](./concepts).
|
||||
- Learn how to [deploy an application](end-user/application) in detail and understand how it works.
|
||||
- Join `#kubevela` channel in CNCF [Slack](https://cloud-native.slack.com) and/or [Gitter](https://gitter.im/oam-dev/community)
|
||||
|
||||
Welcome onboard and sail Vela!
|
||||
|
|
@ -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.
|
||||
```
|
||||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ The reasons for KubeVela supports CUE as a first-class solution to design abstra
|
|||
|
||||
- **CUE is designed for large scale configuration.** CUE has the ability to understand a
|
||||
configuration worked on by engineers across a whole company and to safely change a value that modifies thousands of objects in a configuration. This aligns very well with KubeVela's original goal to define and ship production level applications at web scale.
|
||||
- **CUE supports first-class code generation and automation.** CUE can integrate with existing tools and workflows naturally while other tools would have to build complex custom solutions. For example, generate OpenAPI schemas wigh Go code. This is how KubeVela build developer tools and GUI interfaces based on the CUE templates.
|
||||
- **CUE supports first-class code generation and automation.** CUE can integrate with existing tools and workflows naturally while other tools would have to build complex custom solutions. For example, generate OpenAPI schemas with Go code. This is how KubeVela build developer tools and GUI interfaces based on the CUE templates.
|
||||
- **CUE integrates very well with Go.**
|
||||
KubeVela is built with GO just like most projects in Kubernetes system. CUE is also implemented in and exposes a rich API in Go. KubeVela integrates with CUE as its core library and works as a Kubernetes controller. With the help of CUE, KubeVela can easily handle data constraint problems.
|
||||
|
||||
|
|
@ -57,7 +57,7 @@ CUE has powerful CLI commands. Let's keep the data in a file named `first.cue` a
|
|||
cue fmt first.cue
|
||||
```
|
||||
|
||||
* Schema Check, besides `cue fmt`, you can also use `vue vet` to check schema.
|
||||
* Schema Check, besides `cue fmt`, you can also use `cue vet` to check schema.
|
||||
```shell
|
||||
cue vet first.cue
|
||||
```
|
||||
|
|
@ -66,7 +66,9 @@ CUE has powerful CLI commands. Let's keep the data in a file named `first.cue` a
|
|||
You can see the results don't contain `a: float` and `b: int`, because these two variables are calculated.
|
||||
While the `e: string` doesn't have definitive results, so it keeps as it is.
|
||||
```shell
|
||||
$ cue eval first.cue
|
||||
cue eval first.cue
|
||||
```
|
||||
```console
|
||||
a: 1.5
|
||||
b: 1
|
||||
d: [1, 2, 3]
|
||||
|
|
@ -78,13 +80,17 @@ CUE has powerful CLI commands. Let's keep the data in a file named `first.cue` a
|
|||
|
||||
* Render for specified result. For example, we want only know the result of `b` in the file, then we can specify the parameter `-e`.
|
||||
```shell
|
||||
$ cue eval -e b first.cue
|
||||
cue eval -e b first.cue
|
||||
```
|
||||
```console
|
||||
1
|
||||
```
|
||||
|
||||
* Export the result. `cue export` will export the result with final value. It will report an error if some variables are not definitive.
|
||||
```shell
|
||||
$ cue export first.cue
|
||||
cue export first.cue
|
||||
```
|
||||
```console
|
||||
e: cannot convert incomplete value "string" to JSON:
|
||||
./first.cue:9:4
|
||||
```
|
||||
|
|
@ -94,7 +100,9 @@ CUE has powerful CLI commands. Let's keep the data in a file named `first.cue` a
|
|||
```
|
||||
Then, the command will work. By default, the result will be rendered in json format.
|
||||
```shell
|
||||
$ cue export first.cue
|
||||
cue export first.cue
|
||||
```
|
||||
```console
|
||||
{
|
||||
"a": 1.5,
|
||||
"b": 1,
|
||||
|
|
@ -112,7 +120,9 @@ CUE has powerful CLI commands. Let's keep the data in a file named `first.cue` a
|
|||
|
||||
* Export the result in YAML format.
|
||||
```shell
|
||||
$ cue export first.cue --out yaml
|
||||
cue export first.cue --out yaml
|
||||
```
|
||||
```console
|
||||
a: 1.5
|
||||
b: 1
|
||||
d:
|
||||
|
|
@ -126,7 +136,9 @@ CUE has powerful CLI commands. Let's keep the data in a file named `first.cue` a
|
|||
|
||||
* Export the result for specified variable.
|
||||
```shell
|
||||
$ cue export -e g first.cue
|
||||
cue export -e g first.cue
|
||||
```
|
||||
```console
|
||||
{
|
||||
"h": "abc"
|
||||
}
|
||||
|
|
@ -177,7 +189,9 @@ j: null
|
|||
Let's name it `second.cue`. Then the `cue export` won't complain as the `#abc` is a type not incomplete value.
|
||||
|
||||
```shell
|
||||
$ cue export second.cue
|
||||
cue export second.cue
|
||||
```
|
||||
```console
|
||||
{}
|
||||
```
|
||||
|
||||
|
|
@ -251,7 +265,9 @@ parameter:{
|
|||
5. Finally, let's export it in yaml:
|
||||
|
||||
```shell
|
||||
$ cue export deployment.cue -e template --out yaml
|
||||
cue export deployment.cue -e template --out yaml
|
||||
```
|
||||
```console
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
spec:
|
||||
|
|
@ -345,7 +361,9 @@ Saving it in `third.cue` file.
|
|||
You can evaluate the result by using `cue eval`:
|
||||
|
||||
```shell
|
||||
$ cue eval third.cue
|
||||
cue eval third.cue
|
||||
```
|
||||
```console
|
||||
a: 1
|
||||
b: 3
|
||||
c: 3
|
||||
|
|
@ -369,7 +387,9 @@ Saving it in `fourth.cue` file.
|
|||
You can evaluate the result by using `cue eval`:
|
||||
|
||||
```shell
|
||||
$ cue eval fourth.cue
|
||||
cue eval fourth.cue
|
||||
```
|
||||
```console
|
||||
price: 200
|
||||
feel: "bad"
|
||||
```
|
||||
|
|
|
|||
|
|
@ -354,11 +354,17 @@ 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
|
||||
```
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: Patch Traits
|
||||
---
|
||||
|
||||
**Patch** is a very common pattern of trait definitions, i.e. the app operators can amend/path attributes to the component instance (normally the workload) to enable certain operational features such as sidecar or node affinity rules (and this should be done **before** the resources applied to target cluster).
|
||||
**Patch** is a very common pattern of trait definitions, i.e. the app operators can amend/patch attributes to the component instance (normally the workload) to enable certain operational features such as sidecar or node affinity rules (and this should be done **before** the resources applied to target cluster).
|
||||
|
||||
This pattern is extremely useful when the component definition is provided by third-party component provider (e.g. software distributor) so app operators do not have privilege to change its template.
|
||||
|
||||
|
|
@ -19,8 +19,7 @@ metadata:
|
|||
name: node-affinity
|
||||
spec:
|
||||
appliesToWorkloads:
|
||||
- webservice
|
||||
- worker
|
||||
- deployments.apps
|
||||
podDisruptive: true
|
||||
schematic:
|
||||
cue:
|
||||
|
|
@ -118,8 +117,7 @@ metadata:
|
|||
name: sidecar
|
||||
spec:
|
||||
appliesToWorkloads:
|
||||
- webservice
|
||||
- worker
|
||||
- deployments.apps
|
||||
podDisruptive: true
|
||||
schematic:
|
||||
cue:
|
||||
|
|
@ -148,8 +146,7 @@ metadata:
|
|||
name: expose
|
||||
spec:
|
||||
appliesToWorkloads:
|
||||
- webservice
|
||||
- worker
|
||||
- deployments.apps
|
||||
podDisruptive: true
|
||||
schematic:
|
||||
cue:
|
||||
|
|
@ -263,8 +260,7 @@ metadata:
|
|||
name: virtualgroup
|
||||
spec:
|
||||
appliesToWorkloads:
|
||||
- webservice
|
||||
- worker
|
||||
- deployments.apps
|
||||
podDisruptive: true
|
||||
schematic:
|
||||
cue:
|
||||
|
|
@ -314,8 +310,7 @@ metadata:
|
|||
name: kautoscale
|
||||
spec:
|
||||
appliesToWorkloads:
|
||||
- webservice
|
||||
- worker
|
||||
- deployments.apps
|
||||
podDisruptive: false
|
||||
schematic:
|
||||
cue:
|
||||
|
|
@ -351,8 +346,7 @@ metadata:
|
|||
name: env
|
||||
spec:
|
||||
appliesToWorkloads:
|
||||
- webservice
|
||||
- worker
|
||||
- deployments.apps
|
||||
podDisruptive: true
|
||||
schematic:
|
||||
cue:
|
||||
|
|
@ -393,8 +387,7 @@ metadata:
|
|||
name: service-account
|
||||
spec:
|
||||
appliesToWorkloads:
|
||||
- webservice
|
||||
- worker
|
||||
- deployments.apps
|
||||
podDisruptive: true
|
||||
schematic:
|
||||
cue:
|
||||
|
|
@ -440,8 +433,7 @@ metadata:
|
|||
name: init-container
|
||||
spec:
|
||||
appliesToWorkloads:
|
||||
- webservice
|
||||
- worker
|
||||
- deployments.apps
|
||||
podDisruptive: true
|
||||
schematic:
|
||||
cue:
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ context:{
|
|||
}
|
||||
```
|
||||
|
||||
Trait will not have the `context.ouput`, other fields are the same.
|
||||
Trait will not have the `context.output`, other fields are the same.
|
||||
|
||||
The example of health check likes below:
|
||||
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
@ -160,7 +162,7 @@ outputs.service.spec.selector.app: reference "context" not found:
|
|||
./def.cue:70:11
|
||||
```
|
||||
|
||||
The `reference "context" not found` is a common error in this step as [`context`](./cue/component#cue-context) is a runtime information that only exist in KubeVela controllers. In order to validate the CUE template end-to-end, we can add a mock `context` in `def.cue`.
|
||||
The `reference "context" not found` is a common error in this step as [`context`](cue/component?id=cue-context) is a runtime information that only exist in KubeVela controllers. In order to validate the CUE template end-to-end, we can add a mock `context` in `def.cue`.
|
||||
|
||||
> Note that you need to remove all mock data when you finished the validation.
|
||||
|
||||
|
|
@ -174,14 +176,18 @@ context: {
|
|||
Then execute the command:
|
||||
|
||||
```shell
|
||||
$ cue vet def.cue
|
||||
cue vet def.cue
|
||||
```
|
||||
```console
|
||||
some instances are incomplete; use the -c flag to show errors or suppress this message
|
||||
```
|
||||
|
||||
The `reference "context" not found` error is gone, but `cue vet` only validates the data type which is not enough to ensure the login in template is correct. Hence we need to use `cue vet -c` for complete validation:
|
||||
|
||||
```shell
|
||||
$ cue vet def.cue -c
|
||||
cue vet def.cue -c
|
||||
```
|
||||
```console
|
||||
context.name: incomplete value string
|
||||
output.metadata.name: incomplete value string
|
||||
output.spec.selector.matchLabels.app: incomplete value string
|
||||
|
|
@ -226,7 +232,9 @@ cue vet def.cue -c
|
|||
The `cue export` can export rendered result in YAMl foramt:
|
||||
|
||||
```shell
|
||||
$ cue export -e output def.cue --out yaml
|
||||
cue export -e output def.cue --out yaml
|
||||
```
|
||||
```console
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
|
|
@ -250,7 +258,9 @@ spec:
|
|||
```
|
||||
|
||||
```shell
|
||||
$ cue export -e outputs.service def.cue --out yaml
|
||||
cue export -e outputs.service def.cue --out yaml
|
||||
```
|
||||
```console
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
|
|
@ -286,7 +296,9 @@ There are two kinds of ways to import internal `kube` packages.
|
|||
2. Import them with third-party packages style. You can run `vela system cue-packages` to list all build-in `kube` packages
|
||||
to know the `third-party packages` supported currently.
|
||||
```shell
|
||||
$ vela system cue-packages
|
||||
vela system cue-packages
|
||||
```
|
||||
```console
|
||||
DEFINITION-NAME IMPORT-PATH USAGE
|
||||
#Deployment k8s.io/apps/v1 Kube Object for apps/v1.Deployment
|
||||
#Service k8s.io/core/v1 Kube Object for v1.Service
|
||||
|
|
@ -318,7 +330,7 @@ touch def.cue
|
|||
In KubeVela, we don't need to download these packages as they're automatically generated from K8s API.
|
||||
But for local test, we need to use `cue get go` to fetch Go packages and convert them to CUE format files.
|
||||
|
||||
So, by using K8s `Deployment` and `Serivice`, we need download and convert to CUE definitions for the `core` and `apps` Kubernetes modules like below:
|
||||
So, by using K8s `Deployment` and `Service`, we need download and convert to CUE definitions for the `core` and `apps` Kubernetes modules like below:
|
||||
|
||||
```shell
|
||||
cue get go k8s.io/api/core/v1
|
||||
|
|
@ -520,7 +532,9 @@ parameter: {
|
|||
Use `cue export` to see the export result.
|
||||
|
||||
```shell
|
||||
$ cue export def.cue --out yaml
|
||||
cue export def.cue --out yaml
|
||||
```
|
||||
```console
|
||||
output:
|
||||
metadata:
|
||||
name: test
|
||||
|
|
@ -576,7 +590,7 @@ When CUE template is good, we can use `vela system dry-run` to dry run and check
|
|||
First, we need use `mergedef.sh` to merge the definition and cue files.
|
||||
|
||||
```shell
|
||||
$ mergedef.sh def.yaml def.cue > componentdef.yaml
|
||||
mergedef.sh def.yaml def.cue > componentdef.yaml
|
||||
```
|
||||
|
||||
Then, let's create an Application named `test-app.yaml`.
|
||||
|
|
@ -604,7 +618,9 @@ spec:
|
|||
Dry run the application by using `vela system dry-run`.
|
||||
|
||||
```shell
|
||||
$ vela system dry-run -f test-app.yaml -d componentdef.yaml
|
||||
vela system dry-run -f test-app.yaml -d componentdef.yaml
|
||||
```
|
||||
```console
|
||||
---
|
||||
# Application(boutique) -- Comopnent(frontend)
|
||||
---
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ spec:
|
|||
```
|
||||
|
||||
In detail:
|
||||
- `.spec.workload` is required to indicate the workload type of this Helm based component. Please also check for [known limitations](./known-issues#workload-type-indicator) if you have multiple workloads packaged in one chart.
|
||||
- `.spec.workload` is required to indicate the workload type of this Helm based component. Please also check for [known limitations](known-issues?id=workload-type-indicator) if you have multiple workloads packaged in one chart.
|
||||
- `.spec.schematic.helm` contains information of Helm `release` and `repository` which leverages `fluxcd/flux2`.
|
||||
- i.e. the spec of `release` aligns with [`HelmReleaseSpec`](https://github.com/fluxcd/helm-controller/blob/main/docs/api/helmrelease.md) and spec of `repository` aligns with [`HelmRepositorySpec`](https://github.com/fluxcd/source-controller/blob/main/docs/api/source.md#source.toolkit.fluxcd.io/v1beta1.HelmRepository).
|
||||
|
||||
|
|
@ -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"
|
||||
```
|
||||
|
|
|
|||
|
|
@ -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
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -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"
|
||||
|
|
|
|||
|
|
@ -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
|
||||
kubectl get configmap -n vela-system -l definition.oam.dev=schema
|
||||
```
|
||||
```console
|
||||
NAME DATA AGE
|
||||
schema-ingress 1 19s
|
||||
schema-scaler 1 19s
|
||||
schema-task 1 19s
|
||||
schema-webservice 1 19s
|
||||
schema-worker 1 20s
|
||||
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:
|
||||
|
|
|
|||
|
|
@ -108,7 +108,7 @@ Hence, the `properties` section of `backend` only exposes two parameters to fill
|
|||
|
||||
Traits (`TraitDefinition` API) are operational features provided by the platform. A trait augments the component instance with operational behaviors such as load balancing policy, network ingress routing, auto-scaling policies, or upgrade strategies, etc.
|
||||
|
||||
To attach a trait to component instance, the user will declare `.type` field to reference the specific `TraitDefinition`, and `.properties` field to set property values of the given trait. Similarly, `TraitDefiniton` also allows you to define *template* for operational features.
|
||||
To attach a trait to component instance, the user will declare `.type` field to reference the specific `TraitDefinition`, and `.properties` field to set property values of the given trait. Similarly, `TraitDefinition` also allows you to define *template* for operational features.
|
||||
|
||||
In the above example, `type: autoscaler` in `frontend` means the specification (i.e. `properties` section) of this trait will be enforced by a `TraitDefinition` object named `autoscaler` as below:
|
||||
|
||||
|
|
@ -121,8 +121,7 @@ metadata:
|
|||
name: hpa
|
||||
spec:
|
||||
appliesToWorkloads:
|
||||
- webservice
|
||||
- worker
|
||||
- deployments.apps
|
||||
schematic:
|
||||
cue:
|
||||
template: |
|
||||
|
|
@ -168,8 +167,7 @@ metadata:
|
|||
name: sidecar
|
||||
spec:
|
||||
appliesToWorkloads:
|
||||
- webservice
|
||||
- worker
|
||||
- deployments.apps
|
||||
schematic:
|
||||
cue:
|
||||
template: |-
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -17,6 +17,8 @@ kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/master/docs/
|
|||
application.core.oam.dev/first-vela-app created
|
||||
```
|
||||
|
||||
Above command will apply an application to KubeVela and let it distribute the application to proper runtime infrastructure.
|
||||
|
||||
Check the status until we see `status` is `running` and services are `healthy`:
|
||||
|
||||
```bash script
|
||||
|
|
@ -38,7 +40,7 @@ status:
|
|||
status: running
|
||||
```
|
||||
|
||||
If your cluster has a working ingress, you can visit the service.
|
||||
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>/
|
||||
|
|
@ -64,9 +66,6 @@ Hello World
|
|||
|
||||
Here are some recommended next steps:
|
||||
|
||||
- Learn KubeVela starting from its [core concepts](./concepts)
|
||||
- Learn KubeVela's [core concepts](./concepts)
|
||||
- Learn more details about [`Application`](end-user/application) and what it can do for you.
|
||||
- Learn how to attach [rollout plan](end-user/scopes/rollout-plan) to this application, or [place it to multiple runtime clusters](end-user/scopes/appdeploy).
|
||||
- Join `#kubevela` channel in CNCF [Slack](https://cloud-native.slack.com) and/or [Gitter](https://gitter.im/oam-dev/community)
|
||||
|
||||
Welcome onboard and sail Vela!
|
||||
|
|
|
|||
Binary file not shown.
|
Before Width: | Height: | Size: 266 KiB After Width: | Height: | Size: 429 KiB |
|
|
@ -1,5 +0,0 @@
|
|||
---
|
||||
title: KubeVela Roadmap
|
||||
---
|
||||
|
||||
Please visit [roadmap docs page](https://github.com/oam-dev/kubevela/tree/master/docs/en/roadmap/).
|
||||
|
|
@ -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.
|
||||
|
|
@ -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
|
||||
|
||||
|
|
@ -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).
|
||||
|
|
@ -91,6 +91,10 @@
|
|||
"type": "doc",
|
||||
"id": "version-v1.1/end-user/traits/volumes"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.1/end-user/traits/service-binding"
|
||||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.1/end-user/traits/more"
|
||||
|
|
@ -396,7 +400,7 @@
|
|||
},
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.1/developers/references/restful-api/rest"
|
||||
"id": "version-v1.1/developers/references/kubectl-plugin"
|
||||
}
|
||||
]
|
||||
},
|
||||
|
|
@ -407,7 +411,7 @@
|
|||
"items": [
|
||||
{
|
||||
"type": "doc",
|
||||
"id": "version-v1.1/roadmap"
|
||||
"id": "version-v1.1/roadmap/README"
|
||||
}
|
||||
]
|
||||
},
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
[
|
||||
"v1.0",
|
||||
"v1.1"
|
||||
"v1.1",
|
||||
"v1.0"
|
||||
]
|
||||
|
|
|
|||
Loading…
Reference in New Issue