refine docs and update the latest vela version
Signed-off-by: Jianbo Sun <jianbo.sjb@alibaba-inc.com>
This commit is contained in:
Jianbo Sun
parent
3b5faf668e
commit
f7f2c341e1
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Initialize/Destroy Infrastructure of Environment
|
||||
title: Initialize Env Infra Resources
|
||||
---
|
||||
|
||||
This section will introduce how to initialize and destroy infrastructure of environment with KubeVela easily.
|
||||
|
|
|
|||
|
|
@ -25,7 +25,8 @@ KubeVela community has maintained a growing [catalog of addons](https://github.c
|
|||
vela addon list
|
||||
```
|
||||
|
||||
The command will show the basic addon info along with all available versions.
|
||||
<details>
|
||||
<summary>The command will show the basic addon info along with all available versions.</summary>
|
||||
|
||||
```console
|
||||
NAME REGISTRY DESCRIPTION AVAILABLE-VERSIONS STATUS
|
||||
|
|
@ -38,6 +39,7 @@ velaux KubeVela KubeVela User Experience (UX). A
|
|||
terraform-alibaba KubeVela Kubernetes Terraform Controller for Alibaba Cloud [1.0.2, 1.0.1] disabled
|
||||
...snip...
|
||||
```
|
||||
</details>
|
||||
|
||||
* You can refer to [addon reference docs](../../reference/addons/overview) for more details of these community certificated addons.
|
||||
|
||||
|
|
@ -49,7 +51,9 @@ The simplest command for installing one addon is:
|
|||
vela addon enable fluxcd
|
||||
```
|
||||
|
||||
The expected output should be:
|
||||
<details>
|
||||
<summary>The expected output.</summary>
|
||||
|
||||
```console
|
||||
I0111 21:45:24.553174 89345 apply.go:106] "creating object" name="addon-fluxcd" resource="core.oam.dev/v1beta1, Kind=Application"
|
||||
I0111 21:45:25.258914 89345 apply.go:106] "creating object" name="helm" resource="core.oam.dev/v1beta1, Kind=ComponentDefinition"
|
||||
|
|
@ -60,6 +64,7 @@ I0111 21:45:25.625815 89345 apply.go:106] "creating object" name="kustomize-st
|
|||
I0111 21:45:25.660129 89345 apply.go:106] "creating object" name="component-uischema-helm" resource="/v1, Kind=ConfigMap"
|
||||
Addon: fluxcd enabled Successfully.
|
||||
```
|
||||
</details>
|
||||
|
||||
You can also install addons with some advanced flags.
|
||||
|
||||
|
|
@ -88,7 +93,14 @@ vela addon enable velaux repo=<your repo address>
|
|||
If you want to check the detail status of an addon, or get more available parameters and other useful info of an addon, you can use command `addon status`. For example:
|
||||
|
||||
```shell
|
||||
$ vela addon enable velaux --verbose
|
||||
vela addon enable velaux --verbose
|
||||
```
|
||||
|
||||
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
```shell
|
||||
velaux: disabled
|
||||
KubeVela User Experience (UX). An extensible, application-oriented delivery and management Dashboard.
|
||||
==> Registry Name
|
||||
|
|
@ -119,12 +131,15 @@ KubeVela
|
|||
default: "kubevela-vela-core"
|
||||
required: ✔
|
||||
```
|
||||
</details>
|
||||
|
||||
As above shows, these infos contain the available parameters, available versions, dependent addons and description of and addon.
|
||||
|
||||
### Discover the capabilities installed
|
||||
|
||||
:::tip
|
||||
Once addon installed, end user can discover and use these capabilities immediately.
|
||||
:::
|
||||
|
||||
* Generally, end user can list the new component or trait types added by `vela component` or `vela trait`. Refer to [Lifecycle of a Definition](../../getting-started/definition#lifecycle-of-a-definition) for more usage details.
|
||||
|
||||
|
|
@ -140,10 +155,13 @@ Please make sure the addon along with its capabilities is no longer used in any
|
|||
vela addon disable fluxcd
|
||||
```
|
||||
|
||||
Expect output:
|
||||
```
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
```shell
|
||||
Successfully disable addon:fluxcd
|
||||
```
|
||||
</details>
|
||||
|
||||
### Manage Addon Registry
|
||||
|
||||
|
|
@ -153,24 +171,45 @@ Let's take the experimental community registry as example.
|
|||
* List your current registries
|
||||
|
||||
```
|
||||
$ vela addon registry list
|
||||
vela addon registry list
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
```shell
|
||||
Name Type URL
|
||||
KubeVela helm https://addons.kubevela.net
|
||||
```
|
||||
</details>
|
||||
|
||||
* Add a new registry
|
||||
|
||||
```
|
||||
$ vela addon registry add experimental --type=helm --endpoint=https://addons.kubevela.net/experimental/
|
||||
vela addon registry add experimental --type=helm --endpoint=https://addons.kubevela.net/experimental/
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
```
|
||||
Successfully add an addon registry experimental
|
||||
```
|
||||
</details>
|
||||
|
||||
* Delete one registry
|
||||
|
||||
```
|
||||
$ vela addon registry delete experimental
|
||||
vela addon registry delete experimental
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
```
|
||||
Successfully delete an addon registry experimental
|
||||
```
|
||||
</details>
|
||||
|
||||
* Build custom registry
|
||||
|
||||
|
|
@ -193,12 +232,25 @@ velaux
|
|||
└── template.yaml
|
||||
|
||||
2 directories, 4 files
|
||||
|
||||
$ vela addon enable ./velaux
|
||||
Addon: velaux enabled successfully
|
||||
```
|
||||
|
||||
* Enable the addon from local directory.
|
||||
|
||||
```
|
||||
vela addon enable ./velaux
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
```
|
||||
Addon: velaux enabled successfully
|
||||
```
|
||||
</details>
|
||||
|
||||
:::caution
|
||||
Please notice that, while an addon is being installed in a cluster, it maybe still need pull some images or Helm Charts. If your cluster cannot reach these resources please refer [docs](../../platform-engineers/system-operation/enable-addon-offline) to complete installation without Internet access.
|
||||
:::
|
||||
|
||||
### Manage the addon with UI Console
|
||||
|
||||
|
|
|
|||
|
|
@ -18,25 +18,27 @@ In VelaUX, you can feel the workflow more intuitively. As shown in the figure: T
|
|||
|
||||
In the workflow, all the steps will be executed sequentially and the next step will be executed after the previous one succeeded. If a step is of type `step-group`, it can contain a series of sub-steps, all of which are executed together when the step group is executed.
|
||||
|
||||
> In future versions of KubeVela (1.5+), you can explicitly specify the execution mode of steps, such as:
|
||||
> ```yaml
|
||||
> workflow:
|
||||
> mode:
|
||||
> steps: StepByStep
|
||||
> subSteps: DAG
|
||||
> ```
|
||||
> There're two modes of execution: StepByStep and DAG.
|
||||
>
|
||||
> If you do not explicitly declare the execution mode, by default steps are executed sequentially in StepByStep and subSteps are executed in parallel in DAG.
|
||||
In KubeVela 1.5.0+, you can explicitly specify the execution mode of steps, such as:
|
||||
|
||||
```yaml
|
||||
workflow:
|
||||
mode:
|
||||
steps: StepByStep
|
||||
subSteps: DAG
|
||||
```
|
||||
|
||||
There're two modes of execution: StepByStep and DAG.
|
||||
|
||||
If you do not explicitly declare the execution mode, by default steps are executed sequentially in StepByStep and subSteps are executed in parallel in DAG.
|
||||
|
||||
## State of Application and Workflow
|
||||
|
||||
| Application | Workflow | Description |
|
||||
| :-------: | :----: | :-----------------------------------: |
|
||||
| runningWorkflow | executing | When the workflow is executing, the status of the application is runningWorkflow |
|
||||
| workflowSuspending | suspending | When the workflow is suspended, the status of the application is workflowSuspending |
|
||||
| workflowTerminated | terminated | When a step in the workflow fails or is terminated, the status of the application is workflowTerminated |
|
||||
| running | succeeded | When all steps in the workflow are executed successfully, the status of the application is running |
|
||||
| Application | Workflow | Description |
|
||||
| :----------------: | :--------: | :-----------------------------------------------------------------------------------------------------: |
|
||||
| runningWorkflow | executing | When the workflow is executing, the status of the application is runningWorkflow |
|
||||
| workflowSuspending | suspending | When the workflow is suspended, the status of the application is workflowSuspending |
|
||||
| workflowTerminated | terminated | When a step in the workflow fails or is terminated, the status of the application is workflowTerminated |
|
||||
| running | succeeded | When all steps in the workflow are executed successfully, the status of the application is running |
|
||||
|
||||
## Core features
|
||||
|
||||
|
|
|
|||
|
|
@ -2,6 +2,10 @@
|
|||
title: Overview
|
||||
---
|
||||
|
||||
:::tip
|
||||
The User Management feature only works when you're using VelaUX UI console.
|
||||
:::
|
||||
|
||||
Once VelaUX is installed, there's a built-in administrator user with full access to the system. It is recommended to use the admin user only for the initial configuration, then switch to another user or configure the SSO integration.
|
||||
|
||||
## Local users/accounts
|
||||
|
|
|
|||
|
|
@ -664,7 +664,6 @@ status:
|
|||
| `context.outputs.<resourceName>` | Structure after instantiation of current component auxiliary resources. | Object Map |
|
||||
| `context.workflowName` | The workflow name specified in annotation. | string |
|
||||
| `context.publishVersion` | The version of application instance specified in annotation. | string |
|
||||
| `context.components` | The object structure of components spec in this application. | Object Map |
|
||||
| `context.appLabels` | The labels of the current application instance. | Object Map |
|
||||
| `context.appAnnotations` | The annotations of the current application instance. | Object Map |
|
||||
| `context.replicaKey` | The key of replication in context. Replication is an internal policy, it will replicate resources with different keys specified. (This feature will be introduced in v1.6+.) | string |
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ KubeVela is fully programmable via [CUE](https://cuelang.org), while it leverage
|
|||
|
||||
You can [manage the definition](../cue/definition-edit) in CUE and the `vela def` command will render it into Kubernetes API with the following protocol.
|
||||
|
||||
## Overview
|
||||
## Definition API
|
||||
|
||||
Essentially, a definition object in KubeVela is a programmable building block. A definition object normally includes several information to model a certain platform capability that would used in further application deployment:
|
||||
- **Capability Indicator**
|
||||
|
|
@ -25,17 +25,44 @@ apiVersion: core.oam.dev/v1beta1
|
|||
kind: XxxDefinition
|
||||
metadata:
|
||||
name: <definition name>
|
||||
annotations:
|
||||
<map of annotations>
|
||||
labels:
|
||||
<map of labels>
|
||||
spec:
|
||||
...
|
||||
schematic:
|
||||
cue:
|
||||
# cue template ...
|
||||
helm:
|
||||
# Helm chart ...
|
||||
# ... interoperability fields
|
||||
```
|
||||
|
||||
Let's explain them one by one.
|
||||
### The convert rule from CUE format to OAM API
|
||||
|
||||
Below is a framework of definition in CUE format:
|
||||
|
||||
```cue
|
||||
<definition name>: {
|
||||
annotations: {}
|
||||
labels: {}
|
||||
attributes: {}
|
||||
description: ""
|
||||
type: "<definition type>"
|
||||
}
|
||||
|
||||
template: {
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
- The `"<definition name>"` aligns with the `.metadata.name` in OAM API.
|
||||
- The `.annotations` aligns with the `.metadata.annotations` in OAM API.
|
||||
- The `.labels` aligns with the `.metadata.labels` in OAM API.
|
||||
- The `.attributes.` aligns with the `.spec.` in OAM API except the `.spec.schematic` field.
|
||||
- The `template` aligns with the `.spec.schematic.cue` field, only CUE schematic supported in this conversion.
|
||||
- The `description` aligns with the `.metadata.annotations["definition.oam.dev/description"]` field.
|
||||
|
||||
Let's check the OAM definition API details one by one.
|
||||
|
||||
## ComponentDefinition
|
||||
|
||||
|
|
@ -478,39 +505,39 @@ spec:
|
|||
|
||||
Once the application is created, KubeVela will tag the created resources with a series of tags, which include the version, name, type, etc. of the application. Through these standard protocols, application components, traits and policies can be coordinated. The specific metadata list is as follows:
|
||||
|
||||
| Label | Description |
|
||||
| :-------------------------------------------------: | :-------------------------------------------: |
|
||||
| `workload.oam.dev/type` | Corresponds to the name of `ComponentDefinition`|
|
||||
| `trait.oam.dev/type` | Corresponds to the name of `TraitDefinition` |
|
||||
| `app.oam.dev/name` | Application name |
|
||||
| `app.oam.dev/component` | Component name |
|
||||
| `trait.oam.dev/resource` | `outputs.\<resource type\>`in Trait |
|
||||
| `app.oam.dev/appRevision` | Application Revision Name |
|
||||
| Label | Description |
|
||||
| :-----------------------: | :----------------------------------------------: |
|
||||
| `workload.oam.dev/type` | Corresponds to the name of `ComponentDefinition` |
|
||||
| `trait.oam.dev/type` | Corresponds to the name of `TraitDefinition` |
|
||||
| `app.oam.dev/name` | Application name |
|
||||
| `app.oam.dev/component` | Component name |
|
||||
| `trait.oam.dev/resource` | `outputs.\<resource type\>`in Trait |
|
||||
| `app.oam.dev/appRevision` | Application Revision Name |
|
||||
|
||||
## Definition Runtime Context
|
||||
|
||||
In the Definition, some runtime context information can be obtained through the `context` variable. The specific list is as follows, where the scope indicates which module definitions the Context variable can be used in:
|
||||
|
||||
| Context Variable | Description | Scope |
|
||||
| :------------------------------: | :------------------------------------------------------------------------------: | :----------------------------------: |
|
||||
| `context.appRevision` | The app version name corresponding to the current instance of the application | ComponentDefinition, TraitDefinition |
|
||||
| `context.appRevisionNum` | The app version number corresponding to the current instance of the application. | ComponentDefinition, TraitDefinition |
|
||||
| `context.appName` | The app name corresponding to the current instance of the application. | ComponentDefinition, TraitDefinition |
|
||||
| Context Variable | Description | Scope |
|
||||
| :------------------------------: | :-----------------------------------------------------------------------------------: | :----------------------------------------------------: |
|
||||
| `context.appRevision` | The app version name corresponding to the current instance of the application | ComponentDefinition, TraitDefinition |
|
||||
| `context.appRevisionNum` | The app version number corresponding to the current instance of the application. | ComponentDefinition, TraitDefinition |
|
||||
| `context.appName` | The app name corresponding to the current instance of the application. | ComponentDefinition, TraitDefinition |
|
||||
| `context.name` | component name in ComponentDefinition and TraitDefinition，policy in PolicyDefinition | ComponentDefinition, TraitDefinition, PolicyDefinition |
|
||||
| `context.namespace` | The namespace of the current instance of the application | ComponentDefinition, TraitDefinition |
|
||||
| `context.revision` | The version name of the current component instance | ComponentDefinition, TraitDefinition |
|
||||
| `context.parameter` | The parameters of the current component instance, it can be obtained in the trait | TraitDefinition |
|
||||
| `context.output` | Object structure after instantiation of current component | ComponentDefinition, TraitDefinition |
|
||||
| `context.outputs.<resourceName>` | Structure after instantiation of current component and trait | ComponentDefinition, TraitDefinition |
|
||||
| `context.namespace` | The namespace of the current instance of the application | ComponentDefinition, TraitDefinition |
|
||||
| `context.revision` | The version name of the current component instance | ComponentDefinition, TraitDefinition |
|
||||
| `context.parameter` | The parameters of the current component instance, it can be obtained in the trait | TraitDefinition |
|
||||
| `context.output` | Object structure after instantiation of current component | ComponentDefinition, TraitDefinition |
|
||||
| `context.outputs.<resourceName>` | Structure after instantiation of current component and trait | ComponentDefinition, TraitDefinition |
|
||||
|
||||
At the same time, in the Workflow system, because the `context` has to act on the application level, it is very different from the above usage. We introduce it separately:
|
||||
|
||||
| Context Variable | Description | Scope |
|
||||
| :------------------------------: | :------------------------------------------------------------------------------: | :----------------------------------: |
|
||||
| `context.name` | The name of the current instance of the application | WorkflowStepDefinition |
|
||||
| `context.namespace` | The namespace of the current instance of the application | WorkflowStepDefinition |
|
||||
| `context.labels` | The labels of the current instance of the application | WorkflowStepDefinition |
|
||||
| `context.annotations` | The annotations of the current instance of the application | WorkflowStepDefinition |
|
||||
| Context Variable | Description | Scope |
|
||||
| :-------------------: | :--------------------------------------------------------: | :--------------------: |
|
||||
| `context.name` | The name of the current instance of the application | WorkflowStepDefinition |
|
||||
| `context.namespace` | The namespace of the current instance of the application | WorkflowStepDefinition |
|
||||
| `context.labels` | The labels of the current instance of the application | WorkflowStepDefinition |
|
||||
| `context.annotations` | The annotations of the current instance of the application | WorkflowStepDefinition |
|
||||
|
||||
|
||||
Please note that all the Definition concepts introduced in this section only need to be understood by the platform administrator when they want to expand the functions of KubeVela. The end users will learn the schema of above definitions with visualized forms (or the JSON schema of parameters if they prefer) and reference them in application deployment plan. Please check the [Generate Forms from Definitions](../openapi-v3-json-schema) section about how this is achieved.
|
||||
|
|
|
|||
|
|
@ -128,9 +128,8 @@ You can define any Kubernetes API objects in policies if you want.
|
|||
|
||||
## Special Policy
|
||||
|
||||
Not all policies generate resources, there're several [built-in policies](../../end-user/policies/references) which are used to control the whole delivery precess and workflows. These special polices are usually coded in the application controller.
|
||||
Not all policies generate resources, there're several [built-in policies](../../end-user/policies/references) which are used to control the whole delivery precess and workflows.
|
||||
|
||||
## What's Next
|
||||
|
||||
* Learn how to [define health check and custom status](../traits/status) of Trait.
|
||||
* Learn how to [define workflow step](../workflow/workflow) in CUE.
|
||||
:::tip
|
||||
These special polices are usually coded in the application controller.
|
||||
:::
|
||||
|
|
@ -9,7 +9,7 @@ KubeVela has [release cadence](../../contributor/release-process) for every 2-3
|
|||
## From v1.4.x to v1.5.x
|
||||
|
||||
:::caution
|
||||
Note: Please upgrade to v1.5.5+ to avoid application workflow rerun when controller upgrade.
|
||||
Note: Please upgrade to v1.5.7+ to avoid application workflow rerun when controller upgrade.
|
||||
:::
|
||||
|
||||
1. Upgrade the CRDs, please make sure you upgrade the CRDs first before upgrade the helm chart.
|
||||
|
|
@ -27,19 +27,19 @@ kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/release-1.5/
|
|||
```
|
||||
helm repo add kubevela https://charts.kubevela.net/core
|
||||
helm repo update
|
||||
helm upgrade -n vela-system --install kubevela kubevela/vela-core --version 1.5.5 --wait
|
||||
helm upgrade -n vela-system --install kubevela kubevela/vela-core --version 1.5.7 --wait
|
||||
```
|
||||
|
||||
3. Download and upgrade to the corresponding CLI
|
||||
|
||||
```
|
||||
curl -fsSl https://kubevela.io/script/install.sh | bash -s 1.5.5
|
||||
curl -fsSl https://kubevela.io/script/install.sh | bash -s 1.5.7
|
||||
```
|
||||
|
||||
4. Upgrade VelaUX or other addon
|
||||
|
||||
```
|
||||
vela addon upgrade velaux --version 1.5.5
|
||||
vela addon upgrade velaux --version 1.5.6
|
||||
```
|
||||
|
||||
## From v1.3.x to v1.4.x
|
||||
|
|
@ -201,9 +201,11 @@ vela addon list
|
|||
vela addon enable <addon name>
|
||||
```
|
||||
|
||||
⚠️Note: This step is not required if the addon is already enabled and used in the pre-upgrade version
|
||||
:::tip
|
||||
This step is not required if the addon is already enabled and used in the pre-upgrade version
|
||||
:::
|
||||
|
||||
5. Update Custom Definition
|
||||
1. Update Custom Definition
|
||||
|
||||
Check if your custom definition works in the new version, try to upgrade them if there're any issues.
|
||||
If you haven't defined any, the normal upgrade process is completed!
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: System Info and Diagnose
|
||||
---
|
||||
|
||||
Vela CLI provide a command to diagnose the system and show the system information.
|
||||
Vela CLI provide a command to diagnose the system and show the system information. It can help check if the system is running in a health state.
|
||||
|
||||
You can:
|
||||
|
||||
|
|
@ -11,19 +11,32 @@ You can:
|
|||
|
||||
### Vela System Info
|
||||
|
||||
1.The system info command displays the cpu and memory metrics, the numbers of ready pods and desired pods.
|
||||
1. The system info command displays the cpu and memory metrics, the numbers of ready pods and desired pods.
|
||||
|
||||
```shell
|
||||
vela system info
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
```
|
||||
NAME NAMESPACE READY PODS IMAGE CPU(cores) MEMORY(bytes) ARGS ENVS
|
||||
kubevela-cluster-gateway vela-system 1/1 oamdev/cluster-gateway:v1.4.0 2m 28Mi apiserver --secure-port=9443 --secret-namespace=ve... -
|
||||
kubevela-vela-core vela-system 1/1 oamdev/vela-core:latest 13m 217Mi --metrics-addr=:8080 --enable-leader-election --op... -
|
||||
```
|
||||
</details>
|
||||
|
||||
2.The system info command displays the deployment spec and status
|
||||
2. The system info command can displays system component details when you specify it by `-s`.
|
||||
|
||||
```shell
|
||||
vela system info -s kubevela-vela-core -n vela-system 1 ↵
|
||||
vela system info -s kubevela-vela-core -n vela-system
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
```
|
||||
metadata:
|
||||
annotations:
|
||||
deployment.kubernetes.io/revision: "2"
|
||||
|
|
@ -64,13 +77,20 @@ status:
|
|||
replicas: 1
|
||||
updatedReplicas: 1
|
||||
```
|
||||
</details>
|
||||
|
||||
### Vela System Diagnose
|
||||
|
||||
`vela system diagnose` will helps you to diagnose the KubeVela's health.
|
||||
|
||||
```shell
|
||||
vela system diagnose
|
||||
vela system diagnose
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
```
|
||||
------------------------------------------------------
|
||||
Diagnosing APIService of cluster-gateway...
|
||||
Result: APIService of cluster-gateway is fine~
|
||||
|
|
@ -79,4 +99,5 @@ Result: APIService of cluster-gateway is fine~
|
|||
Diagnosing health of clusters...
|
||||
Result: Clusters are fine~
|
||||
------------------------------------------------------
|
||||
```
|
||||
```
|
||||
</details>
|
||||
|
|
@ -26,7 +26,7 @@ module.exports = {
|
|||
id: 'start',
|
||||
content:
|
||||
'<div class="header-item">⭐️ If you like KubeVela, give it a star on <a target="_blank" rel="noopener noreferrer" href="https://github.com/kubevela/kubevela">GitHub</a>!⭐️</div>' +
|
||||
'<div class="header-item"><span>KubeVela v1.5.5 is now available.(2022-09-20)</span> <a target="_blank" style="color: var(--ifm-color-primary)" rel="noopener noreferrer" href="https://github.com/kubevela/kubevela/releases/v1.5.5">Read Release Note</a></div>',
|
||||
'<div class="header-item"><span>KubeVela v1.5.7 is now available.(2022-10-17)</span> <a target="_blank" style="color: var(--ifm-color-primary)" rel="noopener noreferrer" href="https://github.com/kubevela/kubevela/releases/v1.5.7">Read Release Note</a></div>',
|
||||
},
|
||||
algolia: {
|
||||
appId: 'PXMFHFWUGZ',
|
||||
|
|
|
|||
|
|
@ -333,5 +333,8 @@
|
|||
},
|
||||
"sidebar.docs.category.Registry Integration": {
|
||||
"message": "注册中心集成"
|
||||
},
|
||||
"sidebar.docs.category.Multi Environment Delivery": {
|
||||
"message": "多环境交付"
|
||||
}
|
||||
}
|
||||
|
|
@ -2,6 +2,10 @@
|
|||
title: 用户管理
|
||||
---
|
||||
|
||||
:::tip
|
||||
该功能仅在使用 VelaUX 以后通过界面使用。
|
||||
:::
|
||||
|
||||
VelaUX 安装后有一个内置的管理员用户，可以完全访问系统。建议仅使用管理员用户进行初始配置，然后切换到本地用户或配置 SSO 集成。
|
||||
|
||||
## 本地用户管理
|
||||
|
|
|
|||
|
|
@ -688,7 +688,6 @@ status:
|
|||
| `context.outputs.<resourceName>` | Structure after instantiation of current component auxiliary resources. | Object Map |
|
||||
| `context.workflowName` | The workflow name specified in annotation. | string |
|
||||
| `context.publishVersion` | The version of application instance specified in annotation. | string |
|
||||
| `context.components` | The object structure of components spec in this application. | Object Map |
|
||||
| `context.appLabels` | The labels of the current application instance. | Object Map |
|
||||
| `context.appAnnotations` | The annotations of the current application instance. | Object Map |
|
||||
| `context.replicaKey` | The key of replication in context. Replication is an internal policy, it will replicate resources with different keys specified. (This feature will be introduced in v1.6+.) | string |
|
||||
|
|
|
|||
|
|
@ -127,9 +127,8 @@ spec:
|
|||
|
||||
## 特殊策略
|
||||
|
||||
并不是所有的策略都可以生成资源, 有几个 [内置策略](../../end-user/policies/references) 用于控制整个交付过程和工作流程。这些特殊策略通常编写在 application controller 中。
|
||||
并不是所有的策略都可以生成资源, 有几个 [内置策略](../../end-user/policies/references) 用于控制整个交付过程和工作流程。
|
||||
|
||||
## 下一步
|
||||
|
||||
* 如何 [自定义 Trait 健康检查和状态](../traits/status) 。
|
||||
* 如何基于 CUE [自定义工作流](../workflow/workflow) 。
|
||||
:::tip
|
||||
这些特殊策略通常编写在 application controller 代码中，无需通过 CUE 自定义。
|
||||
:::
|
||||
|
|
|
|||
|
|
@ -8,7 +8,9 @@ KubeVela 的[发布周期](../../contributor/release-process)定为每隔 2-3
|
|||
|
||||
## 从 v1.4.x 版本 到 v1.5.x 版本
|
||||
|
||||
> ⚠️ 注意: 升级到 v1.5.4 及以前的版本可能会触发应用重启，升级到 v1.5.5 可以保证已经正常运行的应用不受影响。
|
||||
:::caution
|
||||
注意: 升级到 v1.5.6 及以前的版本可能会触发应用重启，升级到 v1.5.7+ 可以保证已经正常运行的应用不受影响。
|
||||
:::
|
||||
|
||||
1. 升级 CRD，请确保在升级 helm chart 之前先升级 CRD。
|
||||
|
||||
|
|
@ -25,24 +27,26 @@ kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/release-1.5/
|
|||
```
|
||||
helm repo add kubevela https://charts.kubevela.net/core
|
||||
helm repo update
|
||||
helm upgrade -n vela-system --install kubevela kubevela/vela-core --version 1.5.5 --wait
|
||||
helm upgrade -n vela-system --install kubevela kubevela/vela-core --version 1.5.7 --wait
|
||||
```
|
||||
|
||||
3. 下载并升级对应的CLI
|
||||
|
||||
```
|
||||
curl -fsSl https://kubevela.io/script/install.sh | bash -s 1.5.5
|
||||
curl -fsSl https://kubevela.io/script/install.sh | bash -s 1.5.7
|
||||
```
|
||||
|
||||
4. 升级 VelaUX 或其他插件
|
||||
|
||||
```
|
||||
vela addon upgrade velaux --version 1.5.5
|
||||
vela addon upgrade velaux --version 1.5.7
|
||||
```
|
||||
|
||||
## 从 v1.3.x 版本 到 v1.4.x 版本
|
||||
|
||||
> ⚠️ 注意: 升级到该版本可能会触发应用重启。
|
||||
:::danger
|
||||
注意: 升级到该版本可能会触发应用重启。
|
||||
:::
|
||||
|
||||
1. 升级 CRD，请确保在升级 helm chart 之前先升级 CRD。
|
||||
|
||||
|
|
@ -83,7 +87,9 @@ vela addon upgrade velaux --version 1.4.7
|
|||
|
||||
## 从 v1.2.x 版本 到 v1.3.x 版本
|
||||
|
||||
> ⚠️ 注意: 升级到该版本可能会触发应用重启。
|
||||
:::danger
|
||||
注意: 升级到该版本可能会触发应用重启。
|
||||
:::
|
||||
|
||||
1. 升级 CRD，请确保在升级 helm chart 之前先升级 CRD。
|
||||
|
||||
|
|
@ -123,7 +129,9 @@ vela addon upgrade velaux --version 1.3.6
|
|||
|
||||
## 从 v1.1.x 版本到 v1.2.x 版本
|
||||
|
||||
> ⚠️ 注意: 升级到该版本会触发应用重启。
|
||||
:::danger
|
||||
注意: 升级到该版本可能会触发应用重启。
|
||||
:::
|
||||
|
||||
1. 检查服务是否正常运行
|
||||
|
||||
|
|
@ -192,9 +200,11 @@ vela addon list
|
|||
vela addon enable <addon name>
|
||||
```
|
||||
|
||||
⚠️注意: 如果插件在升级前的版本中已经启用并且在使用中，则不需要此步骤
|
||||
:::tip
|
||||
如果插件在升级前的版本中已经启用并且在使用中，则不需要此步骤.
|
||||
:::
|
||||
|
||||
5. 更新 Custom Definition
|
||||
1. 更新 Custom Definition
|
||||
|
||||
检查你的 Custom Definition 是否在新版本中正常工作，如果有任何问题，请尝试升级它们。如果你没有定义任何内容，则升级过程已经完成！
|
||||
|
||||
|
|
|
|||
|
|
@ -336,5 +336,8 @@
|
|||
},
|
||||
"sidebar.docs.category.Registry Integration": {
|
||||
"message": "注册中心集成"
|
||||
},
|
||||
"sidebar.docs.category.Multi Environment Delivery": {
|
||||
"message": "多环境交付"
|
||||
}
|
||||
}
|
||||
|
|
@ -2,6 +2,10 @@
|
|||
title: 用户管理
|
||||
---
|
||||
|
||||
:::tip
|
||||
该功能仅在使用 VelaUX 以后通过界面使用。
|
||||
:::
|
||||
|
||||
VelaUX 安装后有一个内置的管理员用户，可以完全访问系统。建议仅使用管理员用户进行初始配置，然后切换到本地用户或配置 SSO 集成。
|
||||
|
||||
## 本地用户管理
|
||||
|
|
|
|||
|
|
@ -688,7 +688,6 @@ status:
|
|||
| `context.outputs.<resourceName>` | Structure after instantiation of current component auxiliary resources. | Object Map |
|
||||
| `context.workflowName` | The workflow name specified in annotation. | string |
|
||||
| `context.publishVersion` | The version of application instance specified in annotation. | string |
|
||||
| `context.components` | The object structure of components spec in this application. | Object Map |
|
||||
| `context.appLabels` | The labels of the current application instance. | Object Map |
|
||||
| `context.appAnnotations` | The annotations of the current application instance. | Object Map |
|
||||
| `context.replicaKey` | The key of replication in context. Replication is an internal policy, it will replicate resources with different keys specified. (This feature will be introduced in v1.6+.) | string |
|
||||
|
|
|
|||
|
|
@ -127,9 +127,8 @@ spec:
|
|||
|
||||
## 特殊策略
|
||||
|
||||
并不是所有的策略都可以生成资源, 有几个 [内置策略](../../end-user/policies/references) 用于控制整个交付过程和工作流程。这些特殊策略通常编写在 application controller 中。
|
||||
并不是所有的策略都可以生成资源, 有几个 [内置策略](../../end-user/policies/references) 用于控制整个交付过程和工作流程。
|
||||
|
||||
## 下一步
|
||||
|
||||
* 如何 [自定义 Trait 健康检查和状态](../traits/status) 。
|
||||
* 如何基于 CUE [自定义工作流](../workflow/workflow) 。
|
||||
:::tip
|
||||
这些特殊策略通常编写在 application controller 代码中，无需通过 CUE 自定义。
|
||||
:::
|
||||
|
|
|
|||
|
|
@ -8,7 +8,9 @@ KubeVela 的[发布周期](../../contributor/release-process)定为每隔 2-3
|
|||
|
||||
## 从 v1.4.x 版本 到 v1.5.x 版本
|
||||
|
||||
> ⚠️ 注意: 升级到 v1.5.4 及以前的版本可能会触发应用重启，升级到 v1.5.5 可以保证已经正常运行的应用不受影响。
|
||||
:::caution
|
||||
注意: 升级到 v1.5.6 及以前的版本可能会触发应用重启，升级到 v1.5.7+ 可以保证已经正常运行的应用不受影响。
|
||||
:::
|
||||
|
||||
1. 升级 CRD，请确保在升级 helm chart 之前先升级 CRD。
|
||||
|
||||
|
|
@ -25,24 +27,26 @@ kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/release-1.5/
|
|||
```
|
||||
helm repo add kubevela https://charts.kubevela.net/core
|
||||
helm repo update
|
||||
helm upgrade -n vela-system --install kubevela kubevela/vela-core --version 1.5.5 --wait
|
||||
helm upgrade -n vela-system --install kubevela kubevela/vela-core --version 1.5.7 --wait
|
||||
```
|
||||
|
||||
3. 下载并升级对应的CLI
|
||||
|
||||
```
|
||||
curl -fsSl https://kubevela.io/script/install.sh | bash -s 1.5.5
|
||||
curl -fsSl https://kubevela.io/script/install.sh | bash -s 1.5.7
|
||||
```
|
||||
|
||||
4. 升级 VelaUX 或其他插件
|
||||
|
||||
```
|
||||
vela addon upgrade velaux --version 1.5.5
|
||||
vela addon upgrade velaux --version 1.5.7
|
||||
```
|
||||
|
||||
## 从 v1.3.x 版本 到 v1.4.x 版本
|
||||
|
||||
> ⚠️ 注意: 升级到该版本可能会触发应用重启。
|
||||
:::danger
|
||||
注意: 升级到该版本可能会触发应用重启。
|
||||
:::
|
||||
|
||||
1. 升级 CRD，请确保在升级 helm chart 之前先升级 CRD。
|
||||
|
||||
|
|
@ -83,7 +87,9 @@ vela addon upgrade velaux --version 1.4.7
|
|||
|
||||
## 从 v1.2.x 版本 到 v1.3.x 版本
|
||||
|
||||
> ⚠️ 注意: 升级到该版本可能会触发应用重启。
|
||||
:::danger
|
||||
注意: 升级到该版本可能会触发应用重启。
|
||||
:::
|
||||
|
||||
1. 升级 CRD，请确保在升级 helm chart 之前先升级 CRD。
|
||||
|
||||
|
|
@ -123,7 +129,9 @@ vela addon upgrade velaux --version 1.3.6
|
|||
|
||||
## 从 v1.1.x 版本到 v1.2.x 版本
|
||||
|
||||
> ⚠️ 注意: 升级到该版本会触发应用重启。
|
||||
:::danger
|
||||
注意: 升级到该版本可能会触发应用重启。
|
||||
:::
|
||||
|
||||
1. 检查服务是否正常运行
|
||||
|
||||
|
|
@ -192,9 +200,11 @@ vela addon list
|
|||
vela addon enable <addon name>
|
||||
```
|
||||
|
||||
⚠️注意: 如果插件在升级前的版本中已经启用并且在使用中，则不需要此步骤
|
||||
:::tip
|
||||
如果插件在升级前的版本中已经启用并且在使用中，则不需要此步骤.
|
||||
:::
|
||||
|
||||
5. 更新 Custom Definition
|
||||
1. 更新 Custom Definition
|
||||
|
||||
检查你的 Custom Definition 是否在新版本中正常工作，如果有任何问题，请尝试升级它们。如果你没有定义任何内容，则升级过程已经完成！
|
||||
|
||||
|
|
|
|||
|
|
@ -1,21 +1,20 @@
|
|||
---
|
||||
title: Custom Container Delivery
|
||||
title: 自定义容器交付
|
||||
---
|
||||
|
||||
If the default `webservice` component type is not suitable for your team, and you want to get a more simple way to deploy your business application. This guide will help you. Before, you must have the platform manager's permission.
|
||||
如果默认的 `webservice` 组件类型不能满足你的团队，并且你希望获得一种更简单的方式来部署业务应用。 本指南将为你提供帮助。 在此之前，你必须获得平台管理员的权限。
|
||||
|
||||
### Simplify the `webservice` type
|
||||
### 简化 `webservice` 类型
|
||||
|
||||
The default [webservice](../end-user/components/references#webservice) component type has more than 10 properties. Maybe your developer only needs to configure the image path and resource limits. For the other properties, the team could set the default values.
|
||||
If so, you could change the `webservice` definition.
|
||||
默认的 [webservice](../end-user/components/references#webservice) 组件类型有超过 10 个属性。 也许你的开发者只需要配置镜像路径和资源限制。 对于其他属性，团队可以设置默认值。如果是这样，你可以更改 `webservice` 定义。
|
||||
|
||||
1. Change the UI schema to hide some fields
|
||||
1. 更改 UI schema 以隐藏某些字段
|
||||
|
||||
> This way is only suitable the UI users.
|
||||
> 这种方式只适合 UI 用户。
|
||||
|
||||
|
||||
|
||||
On the definition detail page, users could customize the UI schema to setting the UI forms. For example, if you want to hide the ExposeType field, only need to set the disable is `true`.
|
||||
在定义详情页面，用户可以自定义 UI schema 来设置 UI 表单。 例如，如果要隐藏 ExposeType 字段，只需要设置 disable 为 `true`。
|
||||
|
||||
```yaml
|
||||
...
|
||||
|
|
@ -26,29 +25,29 @@ On the definition detail page, users could customize the UI schema to setting th
|
|||
...
|
||||
```
|
||||
|
||||
More references: [UI Schema](../reference/ui-schema)
|
||||
更多参考: [UI Schema](../reference/ui-schema)
|
||||
|
||||
2. Change the definition and remove or add some fields
|
||||
2. 更改定义并增删字段
|
||||
|
||||
If you want to completely remove or add some fields, you should edit the component definition.
|
||||
如果要完全删除或添加某些字段，则应编辑组件定义。
|
||||
|
||||
> This guide should learn the CUE language.
|
||||
> 本指南需要先学习 CUE 语言。
|
||||
|
||||
```bash
|
||||
vela def get webservice > custom-webservice.cue
|
||||
```
|
||||
|
||||
Refer to the [CUE Basic](../platform-engineers/cue/basic) and [Component Definition](../platform-engineers/components/custom-component) documents to learn how to custom the `custom-webservice.cue`.
|
||||
参考[CUE基础](../platform-engineers/cue/basic)和[组件定义](../platform-engineers/components/custom-component)文档，了解如何自定义 `custom-webservice.cue`。
|
||||
|
||||
After edit:
|
||||
编辑完成之后:
|
||||
|
||||
```bash
|
||||
vela def apply custom-webservice.cue
|
||||
```
|
||||
|
||||
### Create a new component type to deploy the war package
|
||||
### 创建一个新的组件类型来部署 war 包
|
||||
|
||||
If your team uses the war package to deploy the Java application. In KubeVela you could create a new component type to deploy the War package.
|
||||
如果你的团队使用 war 包来部署 Java 应用。 在 KubeVela 中，你可以创建一个新的组件类型来部署 War 包。
|
||||
|
||||
```cue
|
||||
"java-war": {
|
||||
|
|
@ -228,13 +227,13 @@ template: {
|
|||
}
|
||||
```
|
||||
|
||||
Copy the definition and create a file `java-war.cue`, then:
|
||||
复制上面的定义来创建一个文件 `java-war.cue`，然后：
|
||||
|
||||
```bash
|
||||
vela def apply java-war.cue
|
||||
```
|
||||
|
||||
Now, other developers could create the application with a war URL, for example:
|
||||
现在，其他开发人员可以使用 war URL 创建应用，例如：
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
|
|
@ -299,6 +298,6 @@ spec:
|
|||
|
||||
|
||||
|
||||
This example includes three components, and the order service depends on the catalog and the customer services. The developer only needs to care about the war package URL and the tomcat/JRE version, they are familiar to the Java developer. The developer should upload the war package to a repository, such as Jfrog. Get a download URL to assign to the `warURL` field.
|
||||
这个例子包括三个组件，order 服务依赖 catalog 和 customer 服务。 开发者只需要关心 war 包 URL 和 tomcat/JRE 版本，Java开发者对此都很熟悉。 开发人员应将 war 包上传到仓库，例如 Jfrog。 获取下载 URL 以分配给 `warURL` 字段。
|
||||
|
||||
In the same way, you could create a component type to deploy the Jar package and other's binary packages.
|
||||
同样，你可以创建一个组件类型来部署 Jar 包和其他二进制包。
|
||||
|
|
|
|||
15
sidebars.js
15
sidebars.js
|
|
@ -192,8 +192,14 @@ module.exports = {
|
|||
],
|
||||
},
|
||||
{
|
||||
'User Management': [
|
||||
'how-to/dashboard/user/user',
|
||||
type: 'category',
|
||||
label: 'User Management',
|
||||
collapsed: true,
|
||||
link: {
|
||||
type: "doc",
|
||||
id: 'how-to/dashboard/user/user',
|
||||
},
|
||||
items: [
|
||||
'tutorials/sso',
|
||||
'how-to/dashboard/config/dex-connectors',
|
||||
],
|
||||
|
|
@ -234,8 +240,11 @@ module.exports = {
|
|||
type: 'category',
|
||||
label: 'Developer Guide',
|
||||
collapsed: true,
|
||||
link: {
|
||||
type: "doc",
|
||||
id: 'contributor/overview',
|
||||
},
|
||||
items: [
|
||||
'contributor/overview',
|
||||
{
|
||||
Addons: [
|
||||
'platform-engineers/addon/intro',
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Initialize/Destroy Infrastructure of Environment
|
||||
title: Initialize Env Infra Resources
|
||||
---
|
||||
|
||||
This section will introduce how to initialize and destroy infrastructure of environment with KubeVela easily.
|
||||
|
|
|
|||
|
|
@ -25,7 +25,8 @@ KubeVela community has maintained a growing [catalog of addons](https://github.c
|
|||
vela addon list
|
||||
```
|
||||
|
||||
The command will show the basic addon info along with all available versions.
|
||||
<details>
|
||||
<summary>The command will show the basic addon info along with all available versions.</summary>
|
||||
|
||||
```console
|
||||
NAME REGISTRY DESCRIPTION AVAILABLE-VERSIONS STATUS
|
||||
|
|
@ -38,6 +39,7 @@ velaux KubeVela KubeVela User Experience (UX). A
|
|||
terraform-alibaba KubeVela Kubernetes Terraform Controller for Alibaba Cloud [1.0.2, 1.0.1] disabled
|
||||
...snip...
|
||||
```
|
||||
</details>
|
||||
|
||||
* You can refer to [addon reference docs](../../reference/addons/overview) for more details of these community certificated addons.
|
||||
|
||||
|
|
@ -49,7 +51,9 @@ The simplest command for installing one addon is:
|
|||
vela addon enable fluxcd
|
||||
```
|
||||
|
||||
The expected output should be:
|
||||
<details>
|
||||
<summary>The expected output.</summary>
|
||||
|
||||
```console
|
||||
I0111 21:45:24.553174 89345 apply.go:106] "creating object" name="addon-fluxcd" resource="core.oam.dev/v1beta1, Kind=Application"
|
||||
I0111 21:45:25.258914 89345 apply.go:106] "creating object" name="helm" resource="core.oam.dev/v1beta1, Kind=ComponentDefinition"
|
||||
|
|
@ -60,6 +64,7 @@ I0111 21:45:25.625815 89345 apply.go:106] "creating object" name="kustomize-st
|
|||
I0111 21:45:25.660129 89345 apply.go:106] "creating object" name="component-uischema-helm" resource="/v1, Kind=ConfigMap"
|
||||
Addon: fluxcd enabled Successfully.
|
||||
```
|
||||
</details>
|
||||
|
||||
You can also install addons with some advanced flags.
|
||||
|
||||
|
|
@ -88,7 +93,14 @@ vela addon enable velaux repo=<your repo address>
|
|||
If you want to check the detail status of an addon, or get more available parameters and other useful info of an addon, you can use command `addon status`. For example:
|
||||
|
||||
```shell
|
||||
$ vela addon enable velaux --verbose
|
||||
vela addon enable velaux --verbose
|
||||
```
|
||||
|
||||
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
```shell
|
||||
velaux: disabled
|
||||
KubeVela User Experience (UX). An extensible, application-oriented delivery and management Dashboard.
|
||||
==> Registry Name
|
||||
|
|
@ -119,12 +131,15 @@ KubeVela
|
|||
default: "kubevela-vela-core"
|
||||
required: ✔
|
||||
```
|
||||
</details>
|
||||
|
||||
As above shows, these infos contain the available parameters, available versions, dependent addons and description of and addon.
|
||||
|
||||
### Discover the capabilities installed
|
||||
|
||||
:::tip
|
||||
Once addon installed, end user can discover and use these capabilities immediately.
|
||||
:::
|
||||
|
||||
* Generally, end user can list the new component or trait types added by `vela component` or `vela trait`. Refer to [Lifecycle of a Definition](../../getting-started/definition#lifecycle-of-a-definition) for more usage details.
|
||||
|
||||
|
|
@ -140,10 +155,13 @@ Please make sure the addon along with its capabilities is no longer used in any
|
|||
vela addon disable fluxcd
|
||||
```
|
||||
|
||||
Expect output:
|
||||
```
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
```shell
|
||||
Successfully disable addon:fluxcd
|
||||
```
|
||||
</details>
|
||||
|
||||
### Manage Addon Registry
|
||||
|
||||
|
|
@ -153,24 +171,45 @@ Let's take the experimental community registry as example.
|
|||
* List your current registries
|
||||
|
||||
```
|
||||
$ vela addon registry list
|
||||
vela addon registry list
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
```shell
|
||||
Name Type URL
|
||||
KubeVela helm https://addons.kubevela.net
|
||||
```
|
||||
</details>
|
||||
|
||||
* Add a new registry
|
||||
|
||||
```
|
||||
$ vela addon registry add experimental --type=helm --endpoint=https://addons.kubevela.net/experimental/
|
||||
vela addon registry add experimental --type=helm --endpoint=https://addons.kubevela.net/experimental/
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
```
|
||||
Successfully add an addon registry experimental
|
||||
```
|
||||
</details>
|
||||
|
||||
* Delete one registry
|
||||
|
||||
```
|
||||
$ vela addon registry delete experimental
|
||||
vela addon registry delete experimental
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
```
|
||||
Successfully delete an addon registry experimental
|
||||
```
|
||||
</details>
|
||||
|
||||
* Build custom registry
|
||||
|
||||
|
|
@ -193,12 +232,25 @@ velaux
|
|||
└── template.yaml
|
||||
|
||||
2 directories, 4 files
|
||||
|
||||
$ vela addon enable ./velaux
|
||||
Addon: velaux enabled successfully
|
||||
```
|
||||
|
||||
* Enable the addon from local directory.
|
||||
|
||||
```
|
||||
vela addon enable ./velaux
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
```
|
||||
Addon: velaux enabled successfully
|
||||
```
|
||||
</details>
|
||||
|
||||
:::caution
|
||||
Please notice that, while an addon is being installed in a cluster, it maybe still need pull some images or Helm Charts. If your cluster cannot reach these resources please refer [docs](../../platform-engineers/system-operation/enable-addon-offline) to complete installation without Internet access.
|
||||
:::
|
||||
|
||||
### Manage the addon with UI Console
|
||||
|
||||
|
|
|
|||
|
|
@ -18,25 +18,27 @@ In VelaUX, you can feel the workflow more intuitively. As shown in the figure: T
|
|||
|
||||
In the workflow, all the steps will be executed sequentially and the next step will be executed after the previous one succeeded. If a step is of type `step-group`, it can contain a series of sub-steps, all of which are executed together when the step group is executed.
|
||||
|
||||
> In future versions of KubeVela (1.5+), you can explicitly specify the execution mode of steps, such as:
|
||||
> ```yaml
|
||||
> workflow:
|
||||
> mode:
|
||||
> steps: StepByStep
|
||||
> subSteps: DAG
|
||||
> ```
|
||||
> There're two modes of execution: StepByStep and DAG.
|
||||
>
|
||||
> If you do not explicitly declare the execution mode, by default steps are executed sequentially in StepByStep and subSteps are executed in parallel in DAG.
|
||||
In KubeVela 1.5.0+, you can explicitly specify the execution mode of steps, such as:
|
||||
|
||||
```yaml
|
||||
workflow:
|
||||
mode:
|
||||
steps: StepByStep
|
||||
subSteps: DAG
|
||||
```
|
||||
|
||||
There're two modes of execution: StepByStep and DAG.
|
||||
|
||||
If you do not explicitly declare the execution mode, by default steps are executed sequentially in StepByStep and subSteps are executed in parallel in DAG.
|
||||
|
||||
## State of Application and Workflow
|
||||
|
||||
| Application | Workflow | Description |
|
||||
| :-------: | :----: | :-----------------------------------: |
|
||||
| runningWorkflow | executing | When the workflow is executing, the status of the application is runningWorkflow |
|
||||
| workflowSuspending | suspending | When the workflow is suspended, the status of the application is workflowSuspending |
|
||||
| workflowTerminated | terminated | When a step in the workflow fails or is terminated, the status of the application is workflowTerminated |
|
||||
| running | succeeded | When all steps in the workflow are executed successfully, the status of the application is running |
|
||||
| Application | Workflow | Description |
|
||||
| :----------------: | :--------: | :-----------------------------------------------------------------------------------------------------: |
|
||||
| runningWorkflow | executing | When the workflow is executing, the status of the application is runningWorkflow |
|
||||
| workflowSuspending | suspending | When the workflow is suspended, the status of the application is workflowSuspending |
|
||||
| workflowTerminated | terminated | When a step in the workflow fails or is terminated, the status of the application is workflowTerminated |
|
||||
| running | succeeded | When all steps in the workflow are executed successfully, the status of the application is running |
|
||||
|
||||
## Core features
|
||||
|
||||
|
|
|
|||
|
|
@ -2,6 +2,10 @@
|
|||
title: Overview
|
||||
---
|
||||
|
||||
:::tip
|
||||
The User Management feature only works when you're using VelaUX UI console.
|
||||
:::
|
||||
|
||||
Once VelaUX is installed, there's a built-in administrator user with full access to the system. It is recommended to use the admin user only for the initial configuration, then switch to another user or configure the SSO integration.
|
||||
|
||||
## Local users/accounts
|
||||
|
|
|
|||
|
|
@ -664,7 +664,6 @@ status:
|
|||
| `context.outputs.<resourceName>` | Structure after instantiation of current component auxiliary resources. | Object Map |
|
||||
| `context.workflowName` | The workflow name specified in annotation. | string |
|
||||
| `context.publishVersion` | The version of application instance specified in annotation. | string |
|
||||
| `context.components` | The object structure of components spec in this application. | Object Map |
|
||||
| `context.appLabels` | The labels of the current application instance. | Object Map |
|
||||
| `context.appAnnotations` | The annotations of the current application instance. | Object Map |
|
||||
| `context.replicaKey` | The key of replication in context. Replication is an internal policy, it will replicate resources with different keys specified. (This feature will be introduced in v1.6+.) | string |
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ KubeVela is fully programmable via [CUE](https://cuelang.org), while it leverage
|
|||
|
||||
You can [manage the definition](../cue/definition-edit) in CUE and the `vela def` command will render it into Kubernetes API with the following protocol.
|
||||
|
||||
## Overview
|
||||
## Definition API
|
||||
|
||||
Essentially, a definition object in KubeVela is a programmable building block. A definition object normally includes several information to model a certain platform capability that would used in further application deployment:
|
||||
- **Capability Indicator**
|
||||
|
|
@ -25,17 +25,44 @@ apiVersion: core.oam.dev/v1beta1
|
|||
kind: XxxDefinition
|
||||
metadata:
|
||||
name: <definition name>
|
||||
annotations:
|
||||
<map of annotations>
|
||||
labels:
|
||||
<map of labels>
|
||||
spec:
|
||||
...
|
||||
schematic:
|
||||
cue:
|
||||
# cue template ...
|
||||
helm:
|
||||
# Helm chart ...
|
||||
# ... interoperability fields
|
||||
```
|
||||
|
||||
Let's explain them one by one.
|
||||
### The convert rule from CUE format to OAM API
|
||||
|
||||
Below is a framework of definition in CUE format:
|
||||
|
||||
```cue
|
||||
<definition name>: {
|
||||
annotations: {}
|
||||
labels: {}
|
||||
attributes: {}
|
||||
description: ""
|
||||
type: "<definition type>"
|
||||
}
|
||||
|
||||
template: {
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
- The `"<definition name>"` aligns with the `.metadata.name` in OAM API.
|
||||
- The `.annotations` aligns with the `.metadata.annotations` in OAM API.
|
||||
- The `.labels` aligns with the `.metadata.labels` in OAM API.
|
||||
- The `.attributes.` aligns with the `.spec.` in OAM API except the `.spec.schematic` field.
|
||||
- The `template` aligns with the `.spec.schematic.cue` field, only CUE schematic supported in this conversion.
|
||||
- The `description` aligns with the `.metadata.annotations["definition.oam.dev/description"]` field.
|
||||
|
||||
Let's check the OAM definition API details one by one.
|
||||
|
||||
## ComponentDefinition
|
||||
|
||||
|
|
@ -478,39 +505,39 @@ spec:
|
|||
|
||||
Once the application is created, KubeVela will tag the created resources with a series of tags, which include the version, name, type, etc. of the application. Through these standard protocols, application components, traits and policies can be coordinated. The specific metadata list is as follows:
|
||||
|
||||
| Label | Description |
|
||||
| :-------------------------------------------------: | :-------------------------------------------: |
|
||||
| `workload.oam.dev/type` | Corresponds to the name of `ComponentDefinition`|
|
||||
| `trait.oam.dev/type` | Corresponds to the name of `TraitDefinition` |
|
||||
| `app.oam.dev/name` | Application name |
|
||||
| `app.oam.dev/component` | Component name |
|
||||
| `trait.oam.dev/resource` | `outputs.\<resource type\>`in Trait |
|
||||
| `app.oam.dev/appRevision` | Application Revision Name |
|
||||
| Label | Description |
|
||||
| :-----------------------: | :----------------------------------------------: |
|
||||
| `workload.oam.dev/type` | Corresponds to the name of `ComponentDefinition` |
|
||||
| `trait.oam.dev/type` | Corresponds to the name of `TraitDefinition` |
|
||||
| `app.oam.dev/name` | Application name |
|
||||
| `app.oam.dev/component` | Component name |
|
||||
| `trait.oam.dev/resource` | `outputs.\<resource type\>`in Trait |
|
||||
| `app.oam.dev/appRevision` | Application Revision Name |
|
||||
|
||||
## Definition Runtime Context
|
||||
|
||||
In the Definition, some runtime context information can be obtained through the `context` variable. The specific list is as follows, where the scope indicates which module definitions the Context variable can be used in:
|
||||
|
||||
| Context Variable | Description | Scope |
|
||||
| :------------------------------: | :------------------------------------------------------------------------------: | :----------------------------------: |
|
||||
| `context.appRevision` | The app version name corresponding to the current instance of the application | ComponentDefinition, TraitDefinition |
|
||||
| `context.appRevisionNum` | The app version number corresponding to the current instance of the application. | ComponentDefinition, TraitDefinition |
|
||||
| `context.appName` | The app name corresponding to the current instance of the application. | ComponentDefinition, TraitDefinition |
|
||||
| Context Variable | Description | Scope |
|
||||
| :------------------------------: | :-----------------------------------------------------------------------------------: | :----------------------------------------------------: |
|
||||
| `context.appRevision` | The app version name corresponding to the current instance of the application | ComponentDefinition, TraitDefinition |
|
||||
| `context.appRevisionNum` | The app version number corresponding to the current instance of the application. | ComponentDefinition, TraitDefinition |
|
||||
| `context.appName` | The app name corresponding to the current instance of the application. | ComponentDefinition, TraitDefinition |
|
||||
| `context.name` | component name in ComponentDefinition and TraitDefinition，policy in PolicyDefinition | ComponentDefinition, TraitDefinition, PolicyDefinition |
|
||||
| `context.namespace` | The namespace of the current instance of the application | ComponentDefinition, TraitDefinition |
|
||||
| `context.revision` | The version name of the current component instance | ComponentDefinition, TraitDefinition |
|
||||
| `context.parameter` | The parameters of the current component instance, it can be obtained in the trait | TraitDefinition |
|
||||
| `context.output` | Object structure after instantiation of current component | ComponentDefinition, TraitDefinition |
|
||||
| `context.outputs.<resourceName>` | Structure after instantiation of current component and trait | ComponentDefinition, TraitDefinition |
|
||||
| `context.namespace` | The namespace of the current instance of the application | ComponentDefinition, TraitDefinition |
|
||||
| `context.revision` | The version name of the current component instance | ComponentDefinition, TraitDefinition |
|
||||
| `context.parameter` | The parameters of the current component instance, it can be obtained in the trait | TraitDefinition |
|
||||
| `context.output` | Object structure after instantiation of current component | ComponentDefinition, TraitDefinition |
|
||||
| `context.outputs.<resourceName>` | Structure after instantiation of current component and trait | ComponentDefinition, TraitDefinition |
|
||||
|
||||
At the same time, in the Workflow system, because the `context` has to act on the application level, it is very different from the above usage. We introduce it separately:
|
||||
|
||||
| Context Variable | Description | Scope |
|
||||
| :------------------------------: | :------------------------------------------------------------------------------: | :----------------------------------: |
|
||||
| `context.name` | The name of the current instance of the application | WorkflowStepDefinition |
|
||||
| `context.namespace` | The namespace of the current instance of the application | WorkflowStepDefinition |
|
||||
| `context.labels` | The labels of the current instance of the application | WorkflowStepDefinition |
|
||||
| `context.annotations` | The annotations of the current instance of the application | WorkflowStepDefinition |
|
||||
| Context Variable | Description | Scope |
|
||||
| :-------------------: | :--------------------------------------------------------: | :--------------------: |
|
||||
| `context.name` | The name of the current instance of the application | WorkflowStepDefinition |
|
||||
| `context.namespace` | The namespace of the current instance of the application | WorkflowStepDefinition |
|
||||
| `context.labels` | The labels of the current instance of the application | WorkflowStepDefinition |
|
||||
| `context.annotations` | The annotations of the current instance of the application | WorkflowStepDefinition |
|
||||
|
||||
|
||||
Please note that all the Definition concepts introduced in this section only need to be understood by the platform administrator when they want to expand the functions of KubeVela. The end users will learn the schema of above definitions with visualized forms (or the JSON schema of parameters if they prefer) and reference them in application deployment plan. Please check the [Generate Forms from Definitions](../openapi-v3-json-schema) section about how this is achieved.
|
||||
|
|
|
|||
|
|
@ -128,9 +128,8 @@ You can define any Kubernetes API objects in policies if you want.
|
|||
|
||||
## Special Policy
|
||||
|
||||
Not all policies generate resources, there're several [built-in policies](../../end-user/policies/references) which are used to control the whole delivery precess and workflows. These special polices are usually coded in the application controller.
|
||||
Not all policies generate resources, there're several [built-in policies](../../end-user/policies/references) which are used to control the whole delivery precess and workflows.
|
||||
|
||||
## What's Next
|
||||
|
||||
* Learn how to [define health check and custom status](../traits/status) of Trait.
|
||||
* Learn how to [define workflow step](../workflow/workflow) in CUE.
|
||||
:::tip
|
||||
These special polices are usually coded in the application controller.
|
||||
:::
|
||||
|
|
@ -9,7 +9,7 @@ KubeVela has [release cadence](../../contributor/release-process) for every 2-3
|
|||
## From v1.4.x to v1.5.x
|
||||
|
||||
:::caution
|
||||
Note: Please upgrade to v1.5.5+ to avoid application workflow rerun when controller upgrade.
|
||||
Note: Please upgrade to v1.5.7+ to avoid application workflow rerun when controller upgrade.
|
||||
:::
|
||||
|
||||
1. Upgrade the CRDs, please make sure you upgrade the CRDs first before upgrade the helm chart.
|
||||
|
|
@ -27,19 +27,19 @@ kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/release-1.5/
|
|||
```
|
||||
helm repo add kubevela https://charts.kubevela.net/core
|
||||
helm repo update
|
||||
helm upgrade -n vela-system --install kubevela kubevela/vela-core --version 1.5.5 --wait
|
||||
helm upgrade -n vela-system --install kubevela kubevela/vela-core --version 1.5.7 --wait
|
||||
```
|
||||
|
||||
3. Download and upgrade to the corresponding CLI
|
||||
|
||||
```
|
||||
curl -fsSl https://kubevela.io/script/install.sh | bash -s 1.5.5
|
||||
curl -fsSl https://kubevela.io/script/install.sh | bash -s 1.5.7
|
||||
```
|
||||
|
||||
4. Upgrade VelaUX or other addon
|
||||
|
||||
```
|
||||
vela addon upgrade velaux --version 1.5.5
|
||||
vela addon upgrade velaux --version 1.5.6
|
||||
```
|
||||
|
||||
## From v1.3.x to v1.4.x
|
||||
|
|
@ -201,9 +201,11 @@ vela addon list
|
|||
vela addon enable <addon name>
|
||||
```
|
||||
|
||||
⚠️Note: This step is not required if the addon is already enabled and used in the pre-upgrade version
|
||||
:::tip
|
||||
This step is not required if the addon is already enabled and used in the pre-upgrade version
|
||||
:::
|
||||
|
||||
5. Update Custom Definition
|
||||
1. Update Custom Definition
|
||||
|
||||
Check if your custom definition works in the new version, try to upgrade them if there're any issues.
|
||||
If you haven't defined any, the normal upgrade process is completed!
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: System Info and Diagnose
|
||||
---
|
||||
|
||||
Vela CLI provide a command to diagnose the system and show the system information.
|
||||
Vela CLI provide a command to diagnose the system and show the system information. It can help check if the system is running in a health state.
|
||||
|
||||
You can:
|
||||
|
||||
|
|
@ -11,19 +11,32 @@ You can:
|
|||
|
||||
### Vela System Info
|
||||
|
||||
1.The system info command displays the cpu and memory metrics, the numbers of ready pods and desired pods.
|
||||
1. The system info command displays the cpu and memory metrics, the numbers of ready pods and desired pods.
|
||||
|
||||
```shell
|
||||
vela system info
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
```
|
||||
NAME NAMESPACE READY PODS IMAGE CPU(cores) MEMORY(bytes) ARGS ENVS
|
||||
kubevela-cluster-gateway vela-system 1/1 oamdev/cluster-gateway:v1.4.0 2m 28Mi apiserver --secure-port=9443 --secret-namespace=ve... -
|
||||
kubevela-vela-core vela-system 1/1 oamdev/vela-core:latest 13m 217Mi --metrics-addr=:8080 --enable-leader-election --op... -
|
||||
```
|
||||
</details>
|
||||
|
||||
2.The system info command displays the deployment spec and status
|
||||
2. The system info command can displays system component details when you specify it by `-s`.
|
||||
|
||||
```shell
|
||||
vela system info -s kubevela-vela-core -n vela-system 1 ↵
|
||||
vela system info -s kubevela-vela-core -n vela-system
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
```
|
||||
metadata:
|
||||
annotations:
|
||||
deployment.kubernetes.io/revision: "2"
|
||||
|
|
@ -64,13 +77,20 @@ status:
|
|||
replicas: 1
|
||||
updatedReplicas: 1
|
||||
```
|
||||
</details>
|
||||
|
||||
### Vela System Diagnose
|
||||
|
||||
`vela system diagnose` will helps you to diagnose the KubeVela's health.
|
||||
|
||||
```shell
|
||||
vela system diagnose
|
||||
vela system diagnose
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>expected output</summary>
|
||||
|
||||
```
|
||||
------------------------------------------------------
|
||||
Diagnosing APIService of cluster-gateway...
|
||||
Result: APIService of cluster-gateway is fine~
|
||||
|
|
@ -79,4 +99,5 @@ Result: APIService of cluster-gateway is fine~
|
|||
Diagnosing health of clusters...
|
||||
Result: Clusters are fine~
|
||||
------------------------------------------------------
|
||||
```
|
||||
```
|
||||
</details>
|
||||
|
|
@ -201,8 +201,14 @@
|
|||
]
|
||||
},
|
||||
{
|
||||
"User Management": [
|
||||
"how-to/dashboard/user/user",
|
||||
"type": "category",
|
||||
"label": "User Management",
|
||||
"collapsed": true,
|
||||
"link": {
|
||||
"type": "doc",
|
||||
"id": "how-to/dashboard/user/user"
|
||||
},
|
||||
"items": [
|
||||
"tutorials/sso",
|
||||
"how-to/dashboard/config/dex-connectors"
|
||||
]
|
||||
|
|
@ -243,8 +249,11 @@
|
|||
"type": "category",
|
||||
"label": "Developer Guide",
|
||||
"collapsed": true,
|
||||
"link": {
|
||||
"type": "doc",
|
||||
"id": "contributor/overview"
|
||||
},
|
||||
"items": [
|
||||
"contributor/overview",
|
||||
{
|
||||
"Addons": [
|
||||
"platform-engineers/addon/intro",
|
||||
|
|
|
|||
Loading…
Reference in New Issue