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

release v1.4 docs (#693) 

* release v1.4 docs

Signed-off-by: Jianbo Sun <jianbo.sjb@alibaba-inc.com>

* update cli for v1.4 docs

Signed-off-by: Jianbo Sun <jianbo.sjb@alibaba-inc.com>
This commit is contained in:
Jianbo Sun 2022-05-31 20:24:55 +08:00 committed by GitHub
parent 42c7cf07fe
commit 7d3dc118f5
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1307 changed files with 65302 additions and 45 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
README.md
View File

@ -110,13 +110,13 @@ All docs of new features should be updated in the latest docs, we will create a
### Build New Version
```
yarn docusaurus docs:version v1.3
yarn docusaurus docs:version v1.x
```
### Update Docs for version
```
make update-version version=v1.3
make update-version version=v1.x
```
## Send your pull request

3
docs/cli/vela.md
View File

@ -25,12 +25,15 @@ title: CLI Commands
* [vela port-forward](vela_port-forward) - Forward local ports to container/service port of vela application.
* [vela logs](vela_logs) - Tail logs for vela application.
* [vela live-diff](vela_live-diff) - Compare application and revisions
* [vela ql](vela_ql) - Show result of executing velaQL.
* [vela dry-run](vela_dry-run) - Dry-run application locally, render the Kubernetes resources as result to stdout.
* [vela revision](vela_revision) - Manage KubeVela Application Revisions
## Continuous Delivery
* [vela auth](vela_auth) -
* [vela cluster](vela_cluster) - Manage Kubernetes Clusters for Continuous Delivery.
* [vela kube](vela_kube) -
* [vela workflow](vela_workflow) - Operate the Workflow during Application Delivery.
## Managing Extension

1
docs/cli/vela_addon.md
View File

@ -26,6 +26,7 @@ Manage addons for extension.
* [vela addon disable](vela_addon_disable) - disable an addon
* [vela addon enable](vela_addon_enable) - enable an addon
* [vela addon list](vela_addon_list) - List addons
* [vela addon package](vela_addon_package) - package an addon directory
* [vela addon registry](vela_addon_registry) - Manage addon registry.
* [vela addon status](vela_addon_status) - get an addon's status.
* [vela addon upgrade](vela_addon_upgrade) - upgrade an addon

2
docs/cli/vela_addon_enable.md
View File

@ -19,7 +19,7 @@ vela addon enable [flags]
Enable addon by:
vela addon enable <addon-name>
Enable addon with specify version:
vela addon enable <addon-name> --version <addon-version>
vela addon enable <addon-name> --version <addon-version>
Enable addon for specific clusters, (local means control plane):
vela addon enable <addon-name> --clusters={local,cluster1,cluster2}

40
docs/cli/vela_addon_package.md Normal file
View File

@ -0,0 +1,40 @@
---
title: vela addon package
---
package an addon directory
### Synopsis
package an addon directory into a helm chart archive.
```
vela addon package [flags]
```
### Examples
```
vela addon package <addon directory>
```
### Options
```
-h, --help help for package
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela addon](vela_addon) - Manage addons for extension.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

2
docs/cli/vela_addon_registry_add.md
View File

@ -25,8 +25,10 @@ vela addon registry add [flags]
--endpoint string specify the addon registry endpoint
--gitToken string specify the github repo token
-h, --help help for add
--password string specify the Helm addon registry password
--path string specify the addon registry OSS path
--type string specify the addon registry type
--username string specify the Helm addon registry username
```
### Options inherited from parent commands

2
docs/cli/vela_addon_registry_update.md
View File

@ -25,8 +25,10 @@ vela addon registry update <registry-name> --type OSS --endpoint=<URL> --bucket=
--endpoint string specify the addon registry endpoint
--gitToken string specify the github repo token
-h, --help help for update
--password string specify the Helm addon registry password
--path string specify the addon registry OSS path
--type string specify the addon registry type
--username string specify the Helm addon registry username
```
### Options inherited from parent commands

3
docs/cli/vela_addon_status.md
View File

@ -21,7 +21,8 @@ vela addon status <addon-name>
### Options
```
-h, --help help for status
-h, --help help for status
-v, --verbose show addon descriptions and parameters in addition to status
```
### Options inherited from parent commands

2
docs/cli/vela_addon_upgrade.md
View File

@ -19,7 +19,7 @@ vela addon upgrade [flags]
Upgrade addon by:
vela addon upgrade <addon-name>
Upgrade addon with specify version:
vela addon upgrade <addon-name> --version <addon-version>
vela addon upgrade <addon-name> --version <addon-version>
Upgrade addon for specific clusters, (local means control plane):
vela addon upgrade <addon-name> --clusters={local,cluster1,cluster2}

29
docs/cli/vela_auth.md Normal file
View File

@ -0,0 +1,29 @@
---
title: vela auth
---
Manage identity and authorizations.
### Options
```
-h, --help help for auth
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela auth gen-kubeconfig](vela_auth_gen-kubeconfig) - Generate kubeconfig for user
* [vela auth grant-privileges](vela_auth_grant-privileges) - Grant privileges for user/group/serviceaccount
* [vela auth list-privileges](vela_auth_list-privileges) - List privileges for user/group/serviceaccount
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

61
docs/cli/vela_auth_gen-kubeconfig.md Normal file
View File

@ -0,0 +1,61 @@
---
title: vela auth gen-kubeconfig
---
Generate kubeconfig for user
### Synopsis
Generate kubeconfig for user
Generate a new kubeconfig with specified identity. By default, the generated kubeconfig will reuse the certificate-authority-data in the cluster config from the current used kubeconfig. All contexts, clusters and users that are not in use will not be included in the generated kubeconfig.
To generate a new kubeconfig for given user and groups, use the --user and --group flag. Multiple --group flags is allowed. The group kubevela:client is added to the groups by default. The identity in the current kubeconfig should be able to approve CertificateSigningRequest in the kubernetes cluster. See https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/ for details.
To generate a kubeconfig based on existing ServiceAccount in your cluster, use the --serviceaccount flag. The corresponding secret token and ca data will be embedded in the generated kubeconfig, which allows you to act as the serviceaccount.
```
vela auth gen-kubeconfig
```
### Examples
```
# Generate a kubeconfig with provided user
vela auth gen-kubeconfig --user new-user
# Generate a kubeconfig with provided user and group
vela auth gen-kubeconfig --user new-user --group kubevela:developer
# Generate a kubeconfig with provided user and groups
vela auth gen-kubeconfig --user new-user --group kubevela:developer --group my-org:my-team
# Generate a kubeconfig with provided serviceaccount
vela auth gen-kubeconfig --serviceaccount default -n demo
```
### Options
```
-e, --env string The environment name for the CLI request
-g, --group --user The groups of the generated kubeconfig. This flag only works when --user is set. It will be embedded as the Organization in the X509 certificate.
-h, --help help for gen-kubeconfig
-n, --namespace --serviceaccount The namespace of the serviceaccount. This flag only works when --serviceaccount is set.
--serviceaccount --user The serviceaccount of the generated kubeconfig. If set, a kubeconfig will be generated based on the secret token of the serviceaccount. Cannot be set when --user presents.
-u, --user string The user of the generated kubeconfig. If set, an X509-based kubeconfig will be intended to create. It will be embedded as the Subject in the X509 certificate.
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela auth](vela_auth) - Manage identity and authorizations.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

76
docs/cli/vela_auth_grant-privileges.md Normal file
View File

@ -0,0 +1,76 @@
---
title: vela auth grant-privileges
---
Grant privileges for user/group/serviceaccount
### Synopsis
Grant privileges for user
Grant privileges to user/group/serviceaccount. By using --for-namespace and --for-cluster, you can grant all read/write privileges for all resources in the specified namespace and cluster. If --for-namespace is not set, the privileges will be granted cluster-wide.
Setting --create-namespace will automatically create namespace if the namespace of the granted privilege does not exists. By default, this flag is not enabled and errors will be returned if the namespace is not found in the corresponding cluster.
Setting --readonly will only grant read privileges for all resources in the destination. This can be useful if you want to give somebody the privileges to view resources but do not want to allow them to edit any resource.
If multiple identity information are set, all the identity information will be bond to the intended privileges respectively.
If --kubeconfig is set, the user/serviceaccount information in the kubeconfig will be used as the identity to grant privileges. Groups will be ignored.
```
vela auth grant-privileges
```
### Examples
```
# Grant privileges for User alice in the namespace demo of the control plane
vela auth grant-privileges --user alice --for-namespace demo
# Grant privileges for User alice in the namespace demo in cluster-1, create demo namespace if not exist
vela auth grant-privileges --user alice --for-namespace demo --for-cluster cluster-1 --create-namespace
# Grant cluster-scoped privileges for Group org:dev-team in the control plane
vela auth grant-privileges --group org:dev-team
# Grant privileges for Group org:dev-team and org:test-team in the namespace test on the control plane and managed cluster example-cluster
vela auth grant-privileges --group org:dev-team --group org:test-team --for-namespace test --for-cluster local --for-cluster example-cluster
# Grant read privileges for ServiceAccount observer in test namespace on the control plane
vela auth grant-privileges --serviceaccount observer -n test --for-namespace test --readonly
# Grant privileges for identity in kubeconfig in cluster-1
vela auth grant-privileges --kubeconfig ./example.kubeconfig --for-cluster cluster-1
```
### Options
```
--create-namespace If set, non-exist namespace will be created automatically.
-e, --env string The environment name for the CLI request
--for-cluster strings The clusters privileges to grant. If empty, the control plane will be used.
--for-namespace strings The namespaces privileges to grant. If empty, cluster-scoped privileges will be granted.
-g, --group strings The group to grant privileges.
-h, --help help for grant-privileges
--kubeconfig string The kubeconfig to grant privileges. If set, it will override all the other identity flags.
-n, --namespace --serviceaccount The namespace of the serviceaccount. This flag only works when --serviceaccount is set.
--readonly If set, only read privileges of resources will be granted. Otherwise, read/write privileges will be granted.
--serviceaccount string The serviceaccount to grant privileges.
-u, --user string The user to grant privileges.
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela auth](vela_auth) - Manage identity and authorizations.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

68
docs/cli/vela_auth_list-privileges.md Normal file
View File

@ -0,0 +1,68 @@
---
title: vela auth list-privileges
---
List privileges for user/group/serviceaccount
### Synopsis
List privileges for user
List privileges that user has in clusters. Use --user/--group to check the privileges for specified user and group. They can be jointly configured to see the union of privileges. Use --serviceaccount and -n/--namespace to see the privileges for ServiceAccount. You can also use --kubeconfig to use the identity inside implicitly. The privileges will be shown in tree format.
This command supports listing privileges across multiple clusters, by using --cluster. If not set, the control plane will be used. This feature requires cluster-gateway to be properly setup to use.
The privileges are collected through listing all ClusterRoleBinding and RoleBinding, following the Kubernetes RBAC Authorization. Other authorization mechanism is not supported now. See https://kubernetes.io/docs/reference/access-authn-authz/rbac/ for details.
The ClusterRoleBinding and RoleBinding that matches the specified identity will be tracked. Related ClusterRoles and Roles are retrieved and the contained PolicyRules are demonstrated.
```
vela auth list-privileges
```
### Examples
```
# List privileges for User alice in the control plane
vela auth list-privileges --user alice
# List privileges for Group org:dev-team in the control plane
vela auth list-privileges --group org:dev-team
# List privileges for User bob with Groups org:dev-team and org:test-team in the control plane and managed cluster example-cluster
vela auth list-privileges --user bob --group org:dev-team --group org:test-team --cluster local --cluster example-cluster
# List privileges for ServiceAccount example-sa in demo namespace in multiple managed clusters
vela auth list-privileges --serviceaccount example-sa -n demo --cluster cluster-1 --cluster cluster-2
# List privileges for identity in kubeconfig
vela auth list-privileges --kubeconfig ./example.kubeconfig --cluster local --cluster cluster-1
```
### Options
```
-c, --cluster strings The cluster to list privileges. If not set, the command will list privileges in the control plane. (default [local])
-e, --env string The environment name for the CLI request
-g, --group strings The group to list privileges. Can be set together with --user.
-h, --help help for list-privileges
--kubeconfig string The kubeconfig to list privileges. If set, it will override all the other identity flags.
-n, --namespace --serviceaccount The namespace of the serviceaccount. This flag only works when --serviceaccount is set.
--serviceaccount string The serviceaccount to list privileges. Cannot be set with --user and --group.
-u, --user string The user to list privileges.
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela auth](vela_auth) - Manage identity and authorizations.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

4
docs/cli/vela_debug.md
View File

@ -22,10 +22,10 @@ vela debug <application-name>
```
-e, --env string specify environment name for application
-f, --focus string specify the focus value to debug
-f, --focus string specify the focus value to debug, only valid for application with workflow
-h, --help help for debug
-n, --namespace string specify the Kubernetes namespace to use
-s, --step string specify the step to debug
-s, --step string specify the step or component to debug
```
### Options inherited from parent commands

2
docs/cli/vela_def_del.md
View File

@ -24,7 +24,7 @@ vela def del DEFINITION_NAME [flags]
```
-h, --help help for del
-n, --namespace string Specify which namespace the definition locates.
-t, --type string Specify the definition type of target. Valid types: workload, scope, workflow-step, component, trait, policy
-t, --type string Specify the definition type of target. Valid types: component, trait, policy, workload, scope, workflow-step
```
### Options inherited from parent commands

2
docs/cli/vela_def_init.md
View File

@ -42,7 +42,7 @@ vela def init DEF_NAME [flags]
--path string Specify which path the configuration(HCL) is stored in the Git repository. Valid when --git is set.
-p, --provider alibaba Specify which provider the cloud resource definition belongs to. Only alibaba, `aws`, `azure` are supported.
-f, --template-yaml string Specify the template yaml file that definition will use to build the schema. If empty, a default template for the given definition type will be used.
-t, --type string Specify the type of the new definition. Valid types: workflow-step, component, trait, policy, workload, scope
-t, --type string Specify the type of the new definition. Valid types: component, trait, policy, workload, scope, workflow-step
```
### Options inherited from parent commands

2
docs/cli/vela_def_list.md
View File

@ -26,7 +26,7 @@ vela def list [flags]
```
-h, --help help for list
-n, --namespace string Specify which namespace to list. If empty, all namespaces will be searched.
-t, --type string Specify which definition type to list. If empty, all types will be searched. Valid types: component, trait, policy, workload, scope, workflow-step
-t, --type string Specify which definition type to list. If empty, all types will be searched. Valid types: workflow-step, component, trait, policy, workload, scope
```
### Options inherited from parent commands

1
docs/cli/vela_dry-run.md
View File

@ -26,6 +26,7 @@ vela dry-run
-f, --file string application file name (default "./app.yaml")
-h, --help help for dry-run
-n, --namespace string specify the Kubernetes namespace to use
--offline dry-run Run dry-run in offline / local mode, all validation steps will be skipped
```
### Options inherited from parent commands

32
docs/cli/vela_kube.md Normal file
View File

@ -0,0 +1,32 @@
---
title: vela kube
---
Managing native Kubernetes resources across clusters.
```
vela kube [flags]
```
### Options
```
-h, --help help for kube
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela kube apply](vela_kube_apply) - Apply resources in Kubernetes YAML file to clusters.
* [vela kube delete](vela_kube_delete) - Delete resources in clusters.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

58
docs/cli/vela_kube_apply.md Normal file
View File

@ -0,0 +1,58 @@
---
title: vela kube apply
---
Apply resources in Kubernetes YAML file to clusters.
### Synopsis
Apply Kubernetes objects in clusters
Apply Kubernetes objects in multiple clusters. Use --clusters to specify which clusters to apply. If -n/--namespace is used, the original object namespace will be overrode.
You can use -f/--file to specify the object file to apply. Multiple file inputs are allowed. Directory input and web url input is supported as well.
```
vela kube apply [flags]
```
### Examples
```
# Apply single object file in managed cluster
vela kube apply -f my.yaml --cluster cluster-1
# Apply multiple object files in multiple managed clusters
vela kube apply -f my-1.yaml -f my-2.yaml --cluster cluster-1 --cluster cluster-2
# Apply object file with web url in control plane
vela kube apply -f https://raw.githubusercontent.com/kubevela/kubevela/master/docs/examples/app-with-probe/app-with-probe.yaml
# Apply object files in directory to specified namespace in managed clusters
vela kube apply -f ./resources -n demo --cluster cluster-1 --cluster cluster-2
```
### Options
```
-c, --cluster strings The cluster to apply objects. Setting multiple clusters will apply objects in order. (default [local])
--dryrun Setting this flag will not apply resources in clusters. It will print out the resource to be applied.
-f, --file strings Files that include native Kubernetes objects to apply.
-h, --help help for apply
-n, --namespace string The namespace to apply objects. If empty, the namespace declared in the YAML will be used.
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela kube](vela_kube) - Managing native Kubernetes resources across clusters.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

54
docs/cli/vela_kube_delete.md Normal file
View File

@ -0,0 +1,54 @@
---
title: vela kube delete
---
Delete resources in clusters.
### Synopsis
Delete Kubernetes objects in clusters
Delete Kubernetes objects in multiple clusters. Use --clusters to specify which clusters to delete. Use -n/--namespace flags to specify which cluster the target resource locates.
Use --all flag to delete all this kind of objects in the target namespace and clusters.
```
vela kube delete [flags]
```
### Examples
```
# Delete the deployment nginx in default namespace in cluster-1
vela kube delete deployment nginx --cluster cluster-1
# Delete the deployment nginx in demo namespace in cluster-1 and cluster-2
vela kube delete deployment nginx -n demo --cluster cluster-1 --cluster cluster-2
# Delete all deployments in demo namespace in cluster-1
vela kube delete deployment --all -n demo --cluster cluster-1
```
### Options
```
--all Setting this flag will delete all this kind of resources.
-c, --cluster strings The cluster to delete objects. Setting multiple clusters will delete objects in order. (default [local])
-h, --help help for delete
-n, --namespace string The namespace to delete objects. If empty, the default namespace will be used.
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela kube](vela_kube) - Managing native Kubernetes resources across clusters.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

2
docs/cli/vela_provider.md
View File

@ -23,6 +23,8 @@ Authenticate Terraform Cloud Providers by managing Terraform Controller Provider
### SEE ALSO
* [vela provider add](vela_provider_add) - Authenticate Terraform Cloud Provider
* [vela provider delete](vela_provider_delete) - Delete Terraform Cloud Provider
* [vela provider list](vela_provider_list) - List Terraform Cloud Providers
#### Go Back to [CLI Commands](vela) Homepage.

9
docs/cli/vela_provider_add.md
View File

@ -33,15 +33,8 @@ vela provider add <provider-type>
### SEE ALSO
* [vela provider](vela_provider) - Authenticate Terraform Cloud Providers
* [vela provider add terraform-alibaba](vela_provider_add_terraform-alibaba) - Authenticate Terraform Cloud Provider terraform-alibaba
* [vela provider add terraform-aws](vela_provider_add_terraform-aws) - Authenticate Terraform Cloud Provider terraform-aws
* [vela provider add terraform-azure](vela_provider_add_terraform-azure) - Authenticate Terraform Cloud Provider terraform-azure
* [vela provider add terraform-baidu](vela_provider_add_terraform-baidu) - Authenticate Terraform Cloud Provider terraform-baidu
* [vela provider add terraform-gcp](vela_provider_add_terraform-gcp) - Authenticate Terraform Cloud Provider terraform-gcp
* [vela provider add terraform-tencent](vela_provider_add_terraform-tencent) - Authenticate Terraform Cloud Provider terraform-tencent
* [vela provider add terraform-ucloud](vela_provider_add_terraform-ucloud) - Authenticate Terraform Cloud Provider terraform-ucloud
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 19-Apr-2022, refer to [script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

9
docs/cli/vela_provider_delete.md
View File

@ -33,15 +33,8 @@ vela provider delete <provider-type> -name <provider-name>
### SEE ALSO
* [vela provider](vela_provider) - Authenticate Terraform Cloud Providers
* [vela provider delete terraform-alibaba](vela_provider_delete_terraform-alibaba) - Delete Terraform Cloud Provider terraform-alibaba
* [vela provider delete terraform-aws](vela_provider_delete_terraform-aws) - Delete Terraform Cloud Provider terraform-aws
* [vela provider delete terraform-azure](vela_provider_delete_terraform-azure) - Delete Terraform Cloud Provider terraform-azure
* [vela provider delete terraform-baidu](vela_provider_delete_terraform-baidu) - Delete Terraform Cloud Provider terraform-baidu
* [vela provider delete terraform-gcp](vela_provider_delete_terraform-gcp) - Delete Terraform Cloud Provider terraform-gcp
* [vela provider delete terraform-tencent](vela_provider_delete_terraform-tencent) - Delete Terraform Cloud Provider terraform-tencent
* [vela provider delete terraform-ucloud](vela_provider_delete_terraform-ucloud) - Delete Terraform Cloud Provider terraform-ucloud
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by spf13/cobra on 19-Apr-2022, refer to [script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

40
docs/cli/vela_ql.md Normal file
View File

@ -0,0 +1,40 @@
---
title: vela ql
---
Show result of executing velaQL.
### Synopsis
Show result of executing velaQL.
```
vela ql [flags]
```
### Examples
```
vela ql "view{parameter=value1,parameter=value2}"
```
### Options
```
-h, --help help for ql
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

2
docs/install.mdx
View File

@ -28,7 +28,7 @@ If you don't need the automation with root access, you can download from the [re
* ** MacOS/Linux **
```shell
curl -fsSl https://static.kubevela.net/script/install-velad.sh | bash -s 1.3.5
curl -fsSl https://static.kubevela.net/script/install-velad.sh | bash -s 1.4.0
```
* **Windows**

8
docs/platform-engineers/advanced-install.mdx
View File

@ -39,7 +39,7 @@ KubeVela CLI provides an easy to engage and manage your application delivery in
** MacOS/Linux **
```shell script
curl -fsSl https://kubevela.io/script/install.sh | bash -s 1.3.5
curl -fsSl https://kubevela.io/script/install.sh | bash -s 1.4.0
```
**Windows**
@ -157,7 +157,7 @@ If you are helm user, you can also use helm to install kubevela core:
```
helm repo add kubevela https://charts.kubevela.net/core
helm repo update
helm install --create-namespace -n vela-system kubevela kubevela/vela-core --version 1.3.5 --wait
helm install --create-namespace -n vela-system kubevela kubevela/vela-core --version 1.4.0 --wait
```
</TabItem>
@ -181,7 +181,7 @@ helm install --create-namespace -n vela-system kubevela kubevela/vela-core --ver
** MacOS/Linux **
```shell script
curl -fsSl https://kubevela.io/script/install.sh | bash -s 1.3.5
curl -fsSl https://kubevela.io/script/install.sh | bash -s 1.4.0
```
**Windows**
@ -240,7 +240,7 @@ docker pull oamdev/vela-cli:latest
### 2. Upgrade Vela Core
```shell
vela install --version v1.3.5
vela install --version v1.4.0
```
### 3. Upgrade VelaUX

2
docusaurus.config.js
View File

@ -7,7 +7,7 @@ module.exports = {
onBrokenLinks: 'throw',
onBrokenMarkdownLinks: 'throw',
favicon: 'img/favicons/favicon.ico',
organizationName: 'oam-dev', // Usually your GitHub org/user name.
organizationName: 'kubevela', // Usually your GitHub org/user name.
projectName: 'kubevela.io', // Usually your repo name.
i18n: {
defaultLocale: 'en',

3
i18n/zh/docusaurus-plugin-content-docs/current/cli/vela.md
View File

@ -25,12 +25,15 @@ title: CLI Commands
* [vela port-forward](vela_port-forward) - Forward local ports to container/service port of vela application.
* [vela logs](vela_logs) - Tail logs for vela application.
* [vela live-diff](vela_live-diff) - Compare application and revisions
* [vela ql](vela_ql) - Show result of executing velaQL.
* [vela dry-run](vela_dry-run) - Dry-run application locally, render the Kubernetes resources as result to stdout.
* [vela revision](vela_revision) - Manage KubeVela Application Revisions
## Continuous Delivery
* [vela auth](vela_auth) -
* [vela cluster](vela_cluster) - Manage Kubernetes Clusters for Continuous Delivery.
* [vela kube](vela_kube) -
* [vela workflow](vela_workflow) - Operate the Workflow during Application Delivery.
## Managing Extension

1
i18n/zh/docusaurus-plugin-content-docs/current/cli/vela_addon.md
View File

@ -26,6 +26,7 @@ Manage addons for extension.
* [vela addon disable](vela_addon_disable) - disable an addon
* [vela addon enable](vela_addon_enable) - enable an addon
* [vela addon list](vela_addon_list) - List addons
* [vela addon package](vela_addon_package) - package an addon directory
* [vela addon registry](vela_addon_registry) - Manage addon registry.
* [vela addon status](vela_addon_status) - get an addon's status.
* [vela addon upgrade](vela_addon_upgrade) - upgrade an addon

2
i18n/zh/docusaurus-plugin-content-docs/current/cli/vela_addon_enable.md
View File

@ -19,7 +19,7 @@ vela addon enable [flags]
Enable addon by:
vela addon enable <addon-name>
Enable addon with specify version:
vela addon enable <addon-name> --version <addon-version>
vela addon enable <addon-name> --version <addon-version>
Enable addon for specific clusters, (local means control plane):
vela addon enable <addon-name> --clusters={local,cluster1,cluster2}

40
i18n/zh/docusaurus-plugin-content-docs/current/cli/vela_addon_package.md Normal file
View File

@ -0,0 +1,40 @@
---
title: vela addon package
---
package an addon directory
### Synopsis
package an addon directory into a helm chart archive.
```
vela addon package [flags]
```
### Examples
```
vela addon package <addon directory>
```
### Options
```
-h, --help help for package
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela addon](vela_addon) - Manage addons for extension.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

2
i18n/zh/docusaurus-plugin-content-docs/current/cli/vela_addon_registry_add.md
View File

@ -25,8 +25,10 @@ vela addon registry add [flags]
--endpoint string specify the addon registry endpoint
--gitToken string specify the github repo token
-h, --help help for add
--password string specify the Helm addon registry password
--path string specify the addon registry OSS path
--type string specify the addon registry type
--username string specify the Helm addon registry username
```
### Options inherited from parent commands

2
i18n/zh/docusaurus-plugin-content-docs/current/cli/vela_addon_registry_update.md
View File

@ -25,8 +25,10 @@ vela addon registry update <registry-name> --type OSS --endpoint=<URL> --bucket=
--endpoint string specify the addon registry endpoint
--gitToken string specify the github repo token
-h, --help help for update
--password string specify the Helm addon registry password
--path string specify the addon registry OSS path
--type string specify the addon registry type
--username string specify the Helm addon registry username
```
### Options inherited from parent commands

3
i18n/zh/docusaurus-plugin-content-docs/current/cli/vela_addon_status.md
View File

@ -21,7 +21,8 @@ vela addon status <addon-name>
### Options
```
-h, --help help for status
-h, --help help for status
-v, --verbose show addon descriptions and parameters in addition to status
```
### Options inherited from parent commands

2
i18n/zh/docusaurus-plugin-content-docs/current/cli/vela_addon_upgrade.md
View File

@ -19,7 +19,7 @@ vela addon upgrade [flags]
Upgrade addon by:
vela addon upgrade <addon-name>
Upgrade addon with specify version:
vela addon upgrade <addon-name> --version <addon-version>
vela addon upgrade <addon-name> --version <addon-version>
Upgrade addon for specific clusters, (local means control plane):
vela addon upgrade <addon-name> --clusters={local,cluster1,cluster2}

29
i18n/zh/docusaurus-plugin-content-docs/current/cli/vela_auth.md Normal file
View File

@ -0,0 +1,29 @@
---
title: vela auth
---
Manage identity and authorizations.
### Options
```
-h, --help help for auth
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela auth gen-kubeconfig](vela_auth_gen-kubeconfig) - Generate kubeconfig for user
* [vela auth grant-privileges](vela_auth_grant-privileges) - Grant privileges for user/group/serviceaccount
* [vela auth list-privileges](vela_auth_list-privileges) - List privileges for user/group/serviceaccount
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

61
i18n/zh/docusaurus-plugin-content-docs/current/cli/vela_auth_gen-kubeconfig.md Normal file
View File

@ -0,0 +1,61 @@
---
title: vela auth gen-kubeconfig
---
Generate kubeconfig for user
### Synopsis
Generate kubeconfig for user
Generate a new kubeconfig with specified identity. By default, the generated kubeconfig will reuse the certificate-authority-data in the cluster config from the current used kubeconfig. All contexts, clusters and users that are not in use will not be included in the generated kubeconfig.
To generate a new kubeconfig for given user and groups, use the --user and --group flag. Multiple --group flags is allowed. The group kubevela:client is added to the groups by default. The identity in the current kubeconfig should be able to approve CertificateSigningRequest in the kubernetes cluster. See https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/ for details.
To generate a kubeconfig based on existing ServiceAccount in your cluster, use the --serviceaccount flag. The corresponding secret token and ca data will be embedded in the generated kubeconfig, which allows you to act as the serviceaccount.
```
vela auth gen-kubeconfig
```
### Examples
```
# Generate a kubeconfig with provided user
vela auth gen-kubeconfig --user new-user
# Generate a kubeconfig with provided user and group
vela auth gen-kubeconfig --user new-user --group kubevela:developer
# Generate a kubeconfig with provided user and groups
vela auth gen-kubeconfig --user new-user --group kubevela:developer --group my-org:my-team
# Generate a kubeconfig with provided serviceaccount
vela auth gen-kubeconfig --serviceaccount default -n demo
```
### Options
```
-e, --env string The environment name for the CLI request
-g, --group --user The groups of the generated kubeconfig. This flag only works when --user is set. It will be embedded as the Organization in the X509 certificate.
-h, --help help for gen-kubeconfig
-n, --namespace --serviceaccount The namespace of the serviceaccount. This flag only works when --serviceaccount is set.
--serviceaccount --user The serviceaccount of the generated kubeconfig. If set, a kubeconfig will be generated based on the secret token of the serviceaccount. Cannot be set when --user presents.
-u, --user string The user of the generated kubeconfig. If set, an X509-based kubeconfig will be intended to create. It will be embedded as the Subject in the X509 certificate.
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela auth](vela_auth) - Manage identity and authorizations.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

76
i18n/zh/docusaurus-plugin-content-docs/current/cli/vela_auth_grant-privileges.md Normal file
View File

@ -0,0 +1,76 @@
---
title: vela auth grant-privileges
---
Grant privileges for user/group/serviceaccount
### Synopsis
Grant privileges for user
Grant privileges to user/group/serviceaccount. By using --for-namespace and --for-cluster, you can grant all read/write privileges for all resources in the specified namespace and cluster. If --for-namespace is not set, the privileges will be granted cluster-wide.
Setting --create-namespace will automatically create namespace if the namespace of the granted privilege does not exists. By default, this flag is not enabled and errors will be returned if the namespace is not found in the corresponding cluster.
Setting --readonly will only grant read privileges for all resources in the destination. This can be useful if you want to give somebody the privileges to view resources but do not want to allow them to edit any resource.
If multiple identity information are set, all the identity information will be bond to the intended privileges respectively.
If --kubeconfig is set, the user/serviceaccount information in the kubeconfig will be used as the identity to grant privileges. Groups will be ignored.
```
vela auth grant-privileges
```
### Examples
```
# Grant privileges for User alice in the namespace demo of the control plane
vela auth grant-privileges --user alice --for-namespace demo
# Grant privileges for User alice in the namespace demo in cluster-1, create demo namespace if not exist
vela auth grant-privileges --user alice --for-namespace demo --for-cluster cluster-1 --create-namespace
# Grant cluster-scoped privileges for Group org:dev-team in the control plane
vela auth grant-privileges --group org:dev-team
# Grant privileges for Group org:dev-team and org:test-team in the namespace test on the control plane and managed cluster example-cluster
vela auth grant-privileges --group org:dev-team --group org:test-team --for-namespace test --for-cluster local --for-cluster example-cluster
# Grant read privileges for ServiceAccount observer in test namespace on the control plane
vela auth grant-privileges --serviceaccount observer -n test --for-namespace test --readonly
# Grant privileges for identity in kubeconfig in cluster-1
vela auth grant-privileges --kubeconfig ./example.kubeconfig --for-cluster cluster-1
```
### Options
```
--create-namespace If set, non-exist namespace will be created automatically.
-e, --env string The environment name for the CLI request
--for-cluster strings The clusters privileges to grant. If empty, the control plane will be used.
--for-namespace strings The namespaces privileges to grant. If empty, cluster-scoped privileges will be granted.
-g, --group strings The group to grant privileges.
-h, --help help for grant-privileges
--kubeconfig string The kubeconfig to grant privileges. If set, it will override all the other identity flags.
-n, --namespace --serviceaccount The namespace of the serviceaccount. This flag only works when --serviceaccount is set.
--readonly If set, only read privileges of resources will be granted. Otherwise, read/write privileges will be granted.
--serviceaccount string The serviceaccount to grant privileges.
-u, --user string The user to grant privileges.
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela auth](vela_auth) - Manage identity and authorizations.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

68
i18n/zh/docusaurus-plugin-content-docs/current/cli/vela_auth_list-privileges.md Normal file
View File

@ -0,0 +1,68 @@
---
title: vela auth list-privileges
---
List privileges for user/group/serviceaccount
### Synopsis
List privileges for user
List privileges that user has in clusters. Use --user/--group to check the privileges for specified user and group. They can be jointly configured to see the union of privileges. Use --serviceaccount and -n/--namespace to see the privileges for ServiceAccount. You can also use --kubeconfig to use the identity inside implicitly. The privileges will be shown in tree format.
This command supports listing privileges across multiple clusters, by using --cluster. If not set, the control plane will be used. This feature requires cluster-gateway to be properly setup to use.
The privileges are collected through listing all ClusterRoleBinding and RoleBinding, following the Kubernetes RBAC Authorization. Other authorization mechanism is not supported now. See https://kubernetes.io/docs/reference/access-authn-authz/rbac/ for details.
The ClusterRoleBinding and RoleBinding that matches the specified identity will be tracked. Related ClusterRoles and Roles are retrieved and the contained PolicyRules are demonstrated.
```
vela auth list-privileges
```
### Examples
```
# List privileges for User alice in the control plane
vela auth list-privileges --user alice
# List privileges for Group org:dev-team in the control plane
vela auth list-privileges --group org:dev-team
# List privileges for User bob with Groups org:dev-team and org:test-team in the control plane and managed cluster example-cluster
vela auth list-privileges --user bob --group org:dev-team --group org:test-team --cluster local --cluster example-cluster
# List privileges for ServiceAccount example-sa in demo namespace in multiple managed clusters
vela auth list-privileges --serviceaccount example-sa -n demo --cluster cluster-1 --cluster cluster-2
# List privileges for identity in kubeconfig
vela auth list-privileges --kubeconfig ./example.kubeconfig --cluster local --cluster cluster-1
```
### Options
```
-c, --cluster strings The cluster to list privileges. If not set, the command will list privileges in the control plane. (default [local])
-e, --env string The environment name for the CLI request
-g, --group strings The group to list privileges. Can be set together with --user.
-h, --help help for list-privileges
--kubeconfig string The kubeconfig to list privileges. If set, it will override all the other identity flags.
-n, --namespace --serviceaccount The namespace of the serviceaccount. This flag only works when --serviceaccount is set.
--serviceaccount string The serviceaccount to list privileges. Cannot be set with --user and --group.
-u, --user string The user to list privileges.
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela auth](vela_auth) - Manage identity and authorizations.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

4
i18n/zh/docusaurus-plugin-content-docs/current/cli/vela_debug.md
View File

@ -22,10 +22,10 @@ vela debug <application-name>
```
-e, --env string specify environment name for application
-f, --focus string specify the focus value to debug
-f, --focus string specify the focus value to debug, only valid for application with workflow
-h, --help help for debug
-n, --namespace string specify the Kubernetes namespace to use
-s, --step string specify the step to debug
-s, --step string specify the step or component to debug
```
### Options inherited from parent commands

2
i18n/zh/docusaurus-plugin-content-docs/current/cli/vela_def_edit.md
View File

@ -27,7 +27,7 @@ vela def edit NAME [flags]
```
-h, --help help for edit
-n, --namespace string Specify which namespace to get. If empty, all namespaces will be searched.
-t, --type string Specify which definition type to get. If empty, all types will be searched. Valid types: component, trait, policy, workload, scope, workflow-step
-t, --type string Specify which definition type to get. If empty, all types will be searched. Valid types: workload, scope, workflow-step, component, trait, policy
```
### Options inherited from parent commands

2
i18n/zh/docusaurus-plugin-content-docs/current/cli/vela_def_get.md
View File

@ -26,7 +26,7 @@ vela def get NAME [flags]
```
-h, --help help for get
-n, --namespace string Specify which namespace to get. If empty, all namespaces will be searched.
-t, --type string Specify which definition type to get. If empty, all types will be searched. Valid types: policy, workload, scope, workflow-step, component, trait
-t, --type string Specify which definition type to get. If empty, all types will be searched. Valid types: workflow-step, component, trait, policy, workload, scope
```
### Options inherited from parent commands

1
i18n/zh/docusaurus-plugin-content-docs/current/cli/vela_dry-run.md
View File

@ -26,6 +26,7 @@ vela dry-run
-f, --file string application file name (default "./app.yaml")
-h, --help help for dry-run
-n, --namespace string specify the Kubernetes namespace to use
--offline dry-run Run dry-run in offline / local mode, all validation steps will be skipped
```
### Options inherited from parent commands

32
i18n/zh/docusaurus-plugin-content-docs/current/cli/vela_kube.md Normal file
View File

@ -0,0 +1,32 @@
---
title: vela kube
---
Managing native Kubernetes resources across clusters.
```
vela kube [flags]
```
### Options
```
-h, --help help for kube
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela kube apply](vela_kube_apply) - Apply resources in Kubernetes YAML file to clusters.
* [vela kube delete](vela_kube_delete) - Delete resources in clusters.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

58
i18n/zh/docusaurus-plugin-content-docs/current/cli/vela_kube_apply.md Normal file
View File

@ -0,0 +1,58 @@
---
title: vela kube apply
---
Apply resources in Kubernetes YAML file to clusters.
### Synopsis
Apply Kubernetes objects in clusters
Apply Kubernetes objects in multiple clusters. Use --clusters to specify which clusters to apply. If -n/--namespace is used, the original object namespace will be overrode.
You can use -f/--file to specify the object file to apply. Multiple file inputs are allowed. Directory input and web url input is supported as well.
```
vela kube apply [flags]
```
### Examples
```
# Apply single object file in managed cluster
vela kube apply -f my.yaml --cluster cluster-1
# Apply multiple object files in multiple managed clusters
vela kube apply -f my-1.yaml -f my-2.yaml --cluster cluster-1 --cluster cluster-2
# Apply object file with web url in control plane
vela kube apply -f https://raw.githubusercontent.com/kubevela/kubevela/master/docs/examples/app-with-probe/app-with-probe.yaml
# Apply object files in directory to specified namespace in managed clusters
vela kube apply -f ./resources -n demo --cluster cluster-1 --cluster cluster-2
```
### Options
```
-c, --cluster strings The cluster to apply objects. Setting multiple clusters will apply objects in order. (default [local])
--dryrun Setting this flag will not apply resources in clusters. It will print out the resource to be applied.
-f, --file strings Files that include native Kubernetes objects to apply.
-h, --help help for apply
-n, --namespace string The namespace to apply objects. If empty, the namespace declared in the YAML will be used.
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela kube](vela_kube) - Managing native Kubernetes resources across clusters.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

54
i18n/zh/docusaurus-plugin-content-docs/current/cli/vela_kube_delete.md Normal file
View File

@ -0,0 +1,54 @@
---
title: vela kube delete
---
Delete resources in clusters.
### Synopsis
Delete Kubernetes objects in clusters
Delete Kubernetes objects in multiple clusters. Use --clusters to specify which clusters to delete. Use -n/--namespace flags to specify which cluster the target resource locates.
Use --all flag to delete all this kind of objects in the target namespace and clusters.
```
vela kube delete [flags]
```
### Examples
```
# Delete the deployment nginx in default namespace in cluster-1
vela kube delete deployment nginx --cluster cluster-1
# Delete the deployment nginx in demo namespace in cluster-1 and cluster-2
vela kube delete deployment nginx -n demo --cluster cluster-1 --cluster cluster-2
# Delete all deployments in demo namespace in cluster-1
vela kube delete deployment --all -n demo --cluster cluster-1
```
### Options
```
--all Setting this flag will delete all this kind of resources.
-c, --cluster strings The cluster to delete objects. Setting multiple clusters will delete objects in order. (default [local])
-h, --help help for delete
-n, --namespace string The namespace to delete objects. If empty, the default namespace will be used.
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela kube](vela_kube) - Managing native Kubernetes resources across clusters.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

2
i18n/zh/docusaurus-plugin-content-docs/current/cli/vela_provider.md
View File

@ -23,6 +23,8 @@ Authenticate Terraform Cloud Providers by managing Terraform Controller Provider
### SEE ALSO
* [vela provider add](vela_provider_add) - Authenticate Terraform Cloud Provider
* [vela provider delete](vela_provider_delete) - Delete Terraform Cloud Provider
* [vela provider list](vela_provider_list) - List Terraform Cloud Providers
#### Go Back to [CLI Commands](vela) Homepage.

40
i18n/zh/docusaurus-plugin-content-docs/current/cli/vela_provider_add.md Normal file
View File

@ -0,0 +1,40 @@
---
title: vela provider add
---
Authenticate Terraform Cloud Provider
### Synopsis
Authenticate Terraform Cloud Provider by creating a credential secret and a Terraform Controller Provider
```
vela provider add [flags]
```
### Examples
```
vela provider add <provider-type>
```
### Options
```
-h, --help help for add
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela provider](vela_provider) - Authenticate Terraform Cloud Providers
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

40
i18n/zh/docusaurus-plugin-content-docs/current/cli/vela_provider_delete.md Normal file
View File

@ -0,0 +1,40 @@
---
title: vela provider delete
---
Delete Terraform Cloud Provider
### Synopsis
Delete Terraform Cloud Provider
```
vela provider delete [flags]
```
### Examples
```
vela provider delete <provider-type> -name <provider-name>
```
### Options
```
-h, --help help for delete
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela provider](vela_provider) - Authenticate Terraform Cloud Providers
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

40
i18n/zh/docusaurus-plugin-content-docs/current/cli/vela_ql.md Normal file
View File

@ -0,0 +1,40 @@
---
title: vela ql
---
Show result of executing velaQL.
### Synopsis
Show result of executing velaQL.
```
vela ql [flags]
```
### Examples
```
vela ql "view{parameter=value1,parameter=value2}"
```
### Options
```
-h, --help help for ql
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

6
i18n/zh/docusaurus-plugin-content-docs/current/install.mdx
View File

@ -178,7 +178,7 @@ KubeVela CLI 提供了命令行工具来便捷的应用终端管理能力。
** MacOS/Linux **
```shell script
curl -fsSl https://kubevela.io/script/install.sh | bash -s 1.3.4
curl -fsSl https://kubevela.io/script/install.sh | bash -s 1.4.0
```
**Windows**
@ -280,7 +280,7 @@ If you want to enable dashboard, please run "vela addon enable velaux"
```
helm repo add kubevela https://charts.kubevela.net/core
helm repo update
helm install --create-namespace -n vela-system kubevela kubevela/vela-core --version 1.3.4 --wait
helm install --create-namespace -n vela-system kubevela kubevela/vela-core --version 1.4.0 --wait
```
</TabItem>
@ -292,7 +292,7 @@ helm install --create-namespace -n vela-system kubevela kubevela/vela-core --ver
VelaUX 是一个可视化操作界面，包括 UI+API 服务，它适用于大多数厂商开箱即用的获取应用交付和管理能力。
```shell script
vela addon enable velaux serviceType=NodePort --version v1.3.4
vela addon enable velaux serviceType=NodePort --version v1.4.0
# 获取映射的端口，通过该端口访问 VelaUX
kubectl get service velaux -n vela-system -o jsonpath="{.spec.ports[0].nodePort}"

6
i18n/zh/docusaurus-plugin-content-docs/current/platform-engineers/advanced-install.mdx
View File

@ -51,7 +51,7 @@ vela install --version 1.3.0-beta.2
** MacOS/Linux **
```shell script
curl -fsSl https://kubevela.io/script/install.sh | bash -s 1.3.4
curl -fsSl https://kubevela.io/script/install.sh | bash -s 1.4.0
```
**Windows**
@ -100,13 +100,13 @@ sudo mv ./vela /usr/local/bin/vela
### 2. 升级核心控制器
```
vela install --version v1.3.4
vela install --version v1.4.0
```
### 3. 升级 VelaUX
```
vela addon enable velaux version=v1.3.4
vela addon enable velaux version=v1.4.0
```
> 请注意，如果安装时指定了自定义参数，比如数据库地址。请在升级时同时指定该参数。

27
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/README.md Normal file
View File

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

235
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/application-crd.md Normal file
View File

@ -0,0 +1,235 @@
---
title: Application CRD
---
本部分将逐步介绍如何使用 `Application` 对象来定义你的应用，并以声明式的方式进行相应的操作。
## 示例
下面的示例应用声明了一个具有 *Worker* 工作负载类型的 `backend` 组件和具有 *Web Service* 工作负载类型的 `frontend` 组件。
此外，`frontend`组件声明了具有 `sidecar` 和 `autoscaler` 的 `trait` 运维能力，这意味着工作负载将自动注入 `fluentd` 的sidecar，并可以根据CPU使用情况触发1-10个副本进行扩展。
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: website
spec:
components:
- name: backend
type: worker
properties:
image: busybox
cmd:
- sleep
- '1000'
- name: frontend
type: webservice
properties:
image: nginx
traits:
- type: autoscaler
properties:
min: 1
max: 10
cpuPercent: 60
- type: sidecar
properties:
name: "sidecar-test"
image: "fluentd"
```
### 部署应用
部署上述的 application yaml文件, 然后应用启动
```shell
$ kubectl get application -o yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: website
....
status:
components:
- apiVersion: core.oam.dev/v1alpha2
kind: Component
name: backend
- apiVersion: core.oam.dev/v1alpha2
kind: Component
name: frontend
....
status: running
```
你可以看到一个命名为 `frontend` 并带有被注入的容器 `fluentd` 的 Deployment 正在运行。
```shell
$ kubectl get deploy frontend
NAME READY UP-TO-DATE AVAILABLE AGE
frontend 1/1 1 1 100m
```
另一个命名为 `backend` 的 Deployment 也在运行。
```shell
$ kubectl get deploy backend
NAME READY UP-TO-DATE AVAILABLE AGE
backend 1/1 1 1 100m
```
同样被 `autoscaler` trait 创建出来的还有一个 HPA 。
```shell
$ kubectl get HorizontalPodAutoscaler frontend
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
frontend Deployment/frontend <unknown>/50% 1 10 1 101m
```
## 背后的原理
在上面的示例中, `type: worker` 指的是该组件的字段内容（即下面的 `properties` 字段中的内容）将遵从名为 `worker` 的 `ComponentDefinition` 对象中的规范定义，如下所示：
```yaml
apiVersion: core.oam.dev/v1beta1
kind: ComponentDefinition
metadata:
name: worker
annotations:
definition.oam.dev/description: "Describes long-running, scalable, containerized services that running at backend. They do NOT have network endpoint to receive external network traffic."
spec:
workload:
definition:
apiVersion: apps/v1
kind: Deployment
schematic:
cue:
template: |
output: {
apiVersion: "apps/v1"
kind: "Deployment"
spec: {
selector: matchLabels: {
"app.oam.dev/component": context.name
}
template: {
metadata: labels: {
"app.oam.dev/component": context.name
}
spec: {
containers: [{
name: context.name
image: parameter.image
if parameter["cmd"] != _|_ {
command: parameter.cmd
}
}]
}
}
}
}
parameter: {
image: string
cmd?: [...string]
}
```
因此，`backend` 的 `properties` 部分仅支持两个参数：`image` 和 `cmd`。这是由定义的 `.spec.template` 字段中的 `parameter` 列表执行的。
类似的可扩展抽象机制也同样适用于 traits(运维能力)。
例如，`frontend` 中的 `type：autoscaler` 指的是组件对应的 trait 的字段规范（即 trait 的 `properties` 部分）
将由名为 `autoscaler` 的 `TraitDefinition` 对象执行，如下所示：
```yaml
apiVersion: core.oam.dev/v1beta1
kind: TraitDefinition
metadata:
annotations:
definition.oam.dev/description: "configure k8s HPA for Deployment"
name: hpa
spec:
appliesToWorkloads:
- webservice
- worker
schematic:
cue:
template: |
outputs: hpa: {
apiVersion: "autoscaling/v2beta2"
kind: "HorizontalPodAutoscaler"
metadata: name: context.name
spec: {
scaleTargetRef: {
apiVersion: "apps/v1"
kind: "Deployment"
name: context.name
}
minReplicas: parameter.min
maxReplicas: parameter.max
metrics: [{
type: "Resource"
resource: {
name: "cpu"
target: {
type: "Utilization"
averageUtilization: parameter.cpuUtil
}
}
}]
}
}
parameter: {
min: *1 | int
max: *10 | int
cpuUtil: *50 | int
}
```
应用同样有一个`sidecar`的运维能力
```yaml
apiVersion: core.oam.dev/v1beta1
kind: TraitDefinition
metadata:
annotations:
definition.oam.dev/description: "add sidecar to the app"
name: sidecar
spec:
appliesToWorkloads:
- webservice
- worker
schematic:
cue:
template: |-
patch: {
// +patchKey=name
spec: template: spec: containers: [parameter]
}
parameter: {
name: string
image: string
command?: [...string]
}
```
在业务用户使用之前，我们认为所有用于定义的对象（Definition Object）都已经由平台团队声明并安装完毕了。所以，业务用户将需要专注于应用（`Application`）本身。
请注意，KubeVela 的终端用户（业务研发）不需要了解定义对象，他们只需要学习如何使用平台已经安装的能力，这些能力通常还可以被可视化的表单展示出来（或者通过 JSON schema 对接其他方式）。请从[由定义生成前端表单](/docs/platform-engineers/openapi-v3-json-schema)部分的文档了解如何实现。
### 惯例和"标准协议"
在应用（`Application` 资源）部署到 Kubernetes 集群后，KubeVela 运行时将遵循以下 “标准协议”和惯例来生成和管理底层资源实例。
| Label | 描述 |
| :--: | :---------: |
|`workload.oam.dev/type=<component definition name>` | 其对应 `ComponentDefinition` 的名称 |
|`trait.oam.dev/type=<trait definition name>` | 其对应 `TraitDefinition` 的名称 |
|`app.oam.dev/name=<app name>` | 它所属的应用的名称 |
|`app.oam.dev/component=<component name>` | 它所属的组件的名称 |
|`trait.oam.dev/resource=<name of trait resource instance>` | 运维能力资源实例的名称 |
|`app.oam.dev/appRevision=<name of app revision>` | 它所属的应用revision的名称 |

407
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/case-studies/gitops.md Normal file
View File

@ -0,0 +1,407 @@
---
title: GitOps 交付
---
本案例将介绍如何在 GitOps 场景下使用 KubeVela，并介绍这样做的好处是什么。
> 该教程仅适用于 CLI 用户。
## 简介
GitOps 是一种现代化的持续交付手段，它允许开发人员通过直接更改 Git 仓库中的代码和配置来自动部署应用，在提高部署生产力的同时也通过分支回滚等能力提高了可靠性。其具体的好处可以查看[这篇文章](https://www.weave.works/blog/what-is-gitops-really)，本文将不再赘述。
KubeVela 作为一个声明式的应用交付控制平面，天然就可以以 GitOps 的方式进行使用，并且这样做会在 GitOps 的基础上为用户提供更多的益处和端到端的体验，包括：
- 应用交付工作流（CD 流水线）
- 即：KubeVela 支持在 GitOps 模式中描述过程式的应用交付，而不只是简单的声明终态；
- 处理部署过程中的各种依赖关系和拓扑结构；
- 在现有各种 GitOps 工具的语义之上提供统一的上层抽象，简化应用交付与管理过程；
- 统一进行云服务的声明、部署和服务绑定；
- 提供开箱即用的交付策略（金丝雀、蓝绿发布等）；
- 提供开箱即用的混合云/多云部署策略（放置规则、集群过滤规则等）；
- 在多环境交付中提供 Kustomize 风格的 Patch 来描述部署差异，而无需学习任何 Kustomize 本身的细节；
- …… 以及更多。
在本文中，我们主要讲解直接使用 KubeVela 在 GitOps 模式下进行交付的步骤。
交付的面向人员有以下两种，我们将分别介绍：
1. 面向平台管理员/运维人员的基础设施交付，用户可以通过直接更新仓库中的配置文件，从而更新集群中的基础设施配置，如系统的依赖软件、安全策略、存储、网络等基础设施配置。
2. 面向终端开发者的交付，用户的代码一旦合并到应用代码仓库，就自动化触发集群中应用的更新，可以更高效的完成应用的迭代，与 KubeVela 的灰度发布、流量调拨、多集群部署等功能结合可以形成更为强大的自动化发布能力。
> 提示：你也可以通过类似的步骤使用 ArgoCD 等 GitOps 工具来间接使用 KubeVela，细节的操作文档我们会在后续发布中提供。
## 面向平台管理员/运维人员的交付
如图所示，对于平台管理员/运维人员而言，他们并不需要关心应用的代码，所以只需要准备一个 Git 配置仓库并部署 KubeVela 配置文件，后续对于应用及基础设施的配置变动，便可通过直接更新 Git 配置仓库来完成，使得每一次配置变更可追踪。
![alt](../resources/ops-flow.jpg)
### 准备配置仓库
> 具体的配置可参考 [示例仓库](https://github.com/kubevela/samples/tree/master/09.GitOps_Demo/for-SREs)。
在本例中，我们将部署一个 MySQL 数据库软件作为项目的基础设施，同时部署一个业务应用，使用这个数据库。配置仓库的目录结构如下:
* `clusters/` 中包含集群中的 KubeVela GitOps 配置，用户需要将 `clusters/` 中的文件手动部署到集群中。这个是一次性的管控操作，执行完成后，KubeVela 便能自动监听配置仓库中的文件变动且自动更新集群中的配置。其中，`clusters/apps.yaml` 将监听 `apps/` 下所有应用的变化，`clusters/infra.yaml` 将监听 `infrastructure/` 下所有基础设施的变化。
* `apps/` 目录中包含业务应用的所有配置，在本例中为一个使用数据库的业务应用。
* `infrastructure/` 中包含一些基础设施相关的配置和策略，在本例中为 MySQL 数据库。
```shell
├── apps
│   └── my-app.yaml
├── clusters
│   ├── apps.yaml
│   └── infra.yaml
└── infrastructure
└── mysql.yaml
```
> KubeVela 建议使用如上的目录结构管理你的 GitOps 仓库。`clusters/` 中存放相关的 KubeVela GitOps 配置并需要被手动部署到集群中，`apps/` 和 `infrastructure/` 中分别存放你的应用和基础设施配置。通过把应用和基础配置分开，能够更为合理的管理你的部署环境，隔离应用的变动影响。
#### `clusters/` 目录
首先，我们来看下 clusters 目录，这也是 KubeVela 对接 GitOps 的初始化操作配置目录
以 `clusters/infra.yaml` 为例：
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: infra
spec:
components:
- name: database-config
type: kustomize
properties:
repoType: git
# 将此处替换成你需要监听的 git 配置仓库地址
url: https://github.com/FogDong/KubeVela-GitOps-Infra-Demo
# 如果是私有仓库，还需要关联 git secret
# secretRef: git-secret
# 自动拉取配置的时间间隔，由于基础设施的变动性较小，此处设置为十分钟
pullInterval: 10m
git:
# 监听变动的分支
branch: main
# 监听变动的路径，指向仓库中 infrastructure 目录下的文件
path: ./infrastructure
```
`apps.yaml` 与 `infra.yaml` 几乎保持一致，只不过监听的文件目录有所区别。
在 `apps.yaml` 中，`properties.path` 的值将改为 `./apps`，表明监听 `apps/` 目录下的文件变动。
cluster 文件夹中的 GitOps 管控配置文件需要在初始化的时候一次性手动部署到集群中，在此之后 KubeVela 将自动监听 `apps/` 以及 `infrastructure/` 目录下的配置文件并定期更新同步。
#### `apps/` 目录
`apps/` 目录中存放着应用配置文件，这是一个配置了数据库信息以及 Ingress 的简单应用。该应用将连接到一个 MySQL 数据库，并简单地启动服务。在默认的服务路径下，会显示当前版本号。在 `/db` 路径下，会列出当前数据库中的信息。
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: my-app
namespace: default
spec:
components:
- name: my-server
type: webservice
properties:
image: ghcr.io/fogdong/test-fog:master-cba5605f-1632714412
port: 8088
env:
- name: DB_HOST
value: mysql-cluster-mysql.default.svc.cluster.local:3306
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
name: mysql-secret
key: ROOT_PASSWORD
traits:
- type: ingress
properties:
domain: testsvc.example.com
http:
/: 8088
```
#### `infrastructure/` 目录
`infrastructure/` 目录下存放一些基础设施的配置。此处我们使用 [mysql controller](https://github.com/bitpoke/mysql-operator) 来部署了一个 MySQL 集群。
> 注意，请确保你的集群中有一个 secret，并通过 `ROOT_PASSWORD` 声明了 MySQL 密码。
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: mysql
namespace: default
spec:
components:
- name: mysql-controller
type: helm
properties:
repoType: helm
url: https://presslabs.github.io/charts
chart: mysql-operator
version: "0.4.0"
- name: mysql-cluster
type: raw
dependsOn:
- mysql-controller
properties:
apiVersion: mysql.presslabs.org/v1alpha1
kind: MysqlCluster
metadata:
name: mysql-cluster
spec:
replicas: 1
# 关联 secret 名称
secretName: mysql-secret
```
#### 部署 `clusters/` 目录下的文件
配置完以上文件并存放到 Git 配置仓库后，我们需要在集群中手动部署 `clusters/` 目录下的 KubeVela GitOps 配置文件。
首先，在集群中部署 `clusters/infra.yaml`。可以看到它自动在集群中拉起了 `infrastructure/` 目录下的 MySQL 部署文件：
```shell
vela up -f clusters/infra.yaml
```
```shell
$ vela ls
APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
infra database-config kustomize running healthy 2021-09-26 20:48:09 +0800 CST
mysql mysql-controller helm running healthy 2021-09-26 20:48:11 +0800 CST
└─ mysql-cluster raw running healthy 2021-09-26 20:48:11 +0800 CST
```
接着，在集群中部署 `clusters/apps.yaml`，可以看到它自动拉起了 `apps/` 目录下的应用部署文件：
```shell
vela up -f clusters/apps.yaml
```
```shell
APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
apps apps kustomize running healthy 2021-09-27 16:55:53 +0800 CST
infra database-config kustomize running healthy 2021-09-26 20:48:09 +0800 CST
my-app my-server webservice ingress running healthy 2021-09-27 16:55:55 +0800 CST
mysql mysql-controller helm running healthy 2021-09-26 20:48:11 +0800 CST
└─ mysql-cluster raw running healthy 2021-09-26 20:48:11 +0800 CST
```
至此，我们通过部署 KubeVela GitOps 配置文件，自动在集群中拉起了应用及数据库。
通过 curl 应用的 Ingress，可以看到目前的版本是 0.1.5，并且成功地连接到了数据库：
```shell
$ kubectl get ingress
NAME CLASS HOSTS ADDRESS PORTS AGE
my-server <none> testsvc.example.com <ingress-ip> 80 162m
$ curl -H "Host:testsvc.example.com" http://<ingress-ip>
Version: 0.1.5
$ curl -H "Host:testsvc.example.com" http://<ingress-ip>/db
User: KubeVela
Description: It's a test user
```
### 修改配置
完成了首次部署后，我们可以通过修改配置仓库中的配置，来完成集群中应用的配置更新。
修改应用 Ingress 的 Domain：
```yaml
...
traits:
- type: ingress
properties:
domain: kubevela.example.com
http:
/: 8089
```
经过一段时间后，重新查看集群中的 Ingress：
```shell
NAME CLASS HOSTS ADDRESS PORTS AGE
my-server <none> kubevela.example.com <ingress-ip> 80 162m
```
可以看到，Ingress 的 Host 地址已被成功更新。
通过这种方式，我们可以方便地通过更新 Git 配置仓库中的文件，从而自动化更新集群中的配置。
## 面向终端开发者的交付
如图所示，对于终端开发者而言，在 KubeVela Git 配置仓库以外，还需要准备一个应用代码仓库。在用户更新了应用代码仓库中的代码后，需要配置一个 CI 来自动构建镜像并推送至镜像仓库中。KubeVela 会监听镜像仓库中的最新镜像，并自动更新配置仓库中的镜像配置，最后再更新集群中的应用配置。使用户可以达成在更新代码后，集群中的配置也自动更新的效果。
![alt](../resources/dev-flow.jpg)
### 准备代码仓库
准备一个代码仓库，里面包含一些源代码以及对应的 Dockerfile。
这些代码将连接到一个 MySQL 数据库，并简单地启动服务。在默认的服务路径下，会显示当前版本号。在 `/db` 路径下，会列出当前数据库中的信息。
```go
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
_, _ = fmt.Fprintf(w, "Version: %s\n", VERSION)
})
http.HandleFunc("/db", func(w http.ResponseWriter, r *http.Request) {
rows, err := db.Query("select * from userinfo;")
if err != nil {
_, _ = fmt.Fprintf(w, "Error: %v\n", err)
}
for rows.Next() {
var username string
var desc string
err = rows.Scan(&username, &desc)
if err != nil {
_, _ = fmt.Fprintf(w, "Scan Error: %v\n", err)
}
_, _ = fmt.Fprintf(w, "User: %s \nDescription: %s\n\n", username, desc)
}
})
if err := http.ListenAndServe(":8088", nil); err != nil {
panic(err.Error())
}
```
我们希望用户改动代码进行提交后，自动构建出最新的镜像并推送到镜像仓库。这一步 CI 可以通过集成 GitHub Actions、Jenkins 或者其他 CI 工具来实现。在本例中，我们通过借助 GitHub Actions 来完成持续集成。具体的代码文件及配置可参考 [示例仓库](https://github.com/kubevela/samples/tree/master/09.GitOps_Demo/for-developers/app-code)。
### 配置秘钥信息
在新的镜像推送到镜像仓库后，KubeVela 会识别到新的镜像，并更新仓库及集群中的 `Application` 配置文件。因此，我们需要一个含有 Git 信息的 Secret，使 KubeVela 向 Git 仓库进行提交。部署如下文件，将其中的用户名和密码替换成你的 Git 用户名及密码（或 Token）：
```yaml
apiVersion: v1
kind: Secret
metadata:
name: git-secret
type: kubernetes.io/basic-auth
stringData:
username: <your username>
password: <your password>
```
### 准备配置仓库
配置仓库与之前面向运维人员的配置大同小异，只需要加上与镜像仓库相关的配置即可。具体配置请参考 [示例仓库](https://github.com/kubevela/samples/tree/master/09.GitOps_Demo/for-developers/kubevela-config)。
修改 `clusters/` 中的 `apps.yaml`，该 GitOps 配置会监听仓库中 `apps/` 下的应用文件变动以及镜像仓库中的镜像更新：
```yaml
...
imageRepository:
# 镜像地址
image: <your image>
# 如果这是一个私有的镜像仓库，可以通过 `kubectl create secret docker-registry` 创建对应的镜像秘钥并相关联
# secretRef: imagesecret
filterTags:
# 可对镜像 tag 进行过滤
pattern: '^master-[a-f0-9]+-(?P<ts>[0-9]+)'
extract: '$ts'
# 通过 policy 筛选出最新的镜像 Tag 并用于更新
policy:
numerical:
order: asc
# 追加提交信息
commitMessage: "Image: {{range .Updated.Images}}{{println .}}{{end}}"
```
修改 `apps/my-app.yaml` 中的 image 字段，在后面加上 `# {"$imagepolicy": "default:apps"}` 的注释。KubeVela 会通过该注释去更新对应的镜像字段。`default:apps` 是上面 GitOps 配置对应的命名空间和名称。
```yaml
spec:
components:
- name: my-server
type: webservice
properties:
image: ghcr.io/fogdong/test-fog:master-cba5605f-1632714412 # {"$imagepolicy": "default:apps"}
```
将 `clusters/` 中包含镜像仓库配置的文件更新到集群中后，我们便可以通过修改代码来完成应用的更新。
### 修改代码
将代码文件中的 `Version` 改为 `0.1.6`，并修改数据库中的数据:
```go
const VERSION = "0.1.6"
...
func InsertInitData(db *sql.DB) {
stmt, err := db.Prepare(insertInitData)
if err != nil {
panic(err)
}
defer stmt.Close()
_, err = stmt.Exec("KubeVela2", "It's another test user")
if err != nil {
panic(err)
}
}
```
提交该改动至代码仓库，可以看到，我们配置的 CI 流水线开始构建镜像并推送至镜像仓库。
而 KubeVela 会通过监听镜像仓库，根据最新的镜像 Tag 来更新配置仓库中 `apps/` 下的应用 `my-app`。
此时，可以看到配置仓库中有一条来自 `kubevelabot` 的提交，提交信息均带有 `Update image automatically.` 前缀。你也可以通过 `{{range .Updated.Images}}{{println .}}{{end}}` 在 `commitMessage` 字段中追加你所需要的信息。
![alt](../resources/gitops-commit.png)
> 值得注意的是，如果你希望将代码和配置放在同一个仓库，需要过滤掉来自 `kubevelabot` 的提交来防止流水线的重复构建。可以在 CI 中通过如下配置过滤：
>
> ```shell
> jobs:
> publish:
> if: "!contains(github.event.head_commit.message, 'Update image automatically')"
> ```
重新查看集群中的应用，可以看到经过一段时间后，应用 `my-app` 的镜像已经被更新。
> KubeVela 会通过你配置的 `interval` 时间间隔，来每隔一段时间分别从配置仓库及镜像仓库中获取最新信息：
> * 当 Git 仓库中的配置文件被更新时，KubeVela 将根据最新的配置更新集群中的应用。
> * 当镜像仓库中多了新的 Tag 时，KubeVela 将根据你配置的 policy 规则，筛选出最新的镜像 Tag，并更新到 Git 仓库中。而当代码仓库中的文件被更新后，KubeVela 将重复第一步，更新集群中的文件，从而达到了自动部署的效果。
通过 `curl` 对应的 `Ingress` 查看当前版本和数据库信息：
```shell
$ kubectl get ingress
NAME CLASS HOSTS ADDRESS PORTS AGE
my-server <none> kubevela.example.com <ingress-ip> 80 162m
$ curl -H "Host:kubevela.example.com" http://<ingress-ip>
Version: 0.1.6
$ curl -H "Host:kubevela.example.com" http://<ingress-ip>/db
User: KubeVela
Description: It's a test user
User: KubeVela2
Description: It's another test user
```
版本已被成功更新！至此，我们完成了从变更代码，到自动部署至集群的全部操作。
## 总结
在运维侧，如若需要更新基础设施（如数据库）的配置，或是应用的配置项，只需要修改配置仓库中的文件，KubeVela 将自动把配置同步到集群中，简化了部署流程。
在研发侧，用户修改代码仓库中的代码后，KubeVela 将自动更新配置仓库中的镜像。从而进行应用的版本更新。
通过与 GitOps 的结合，KubeVela 加速了应用从开发到部署的整个流程。

233
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/case-studies/initialize-env.md Normal file
View File

@ -0,0 +1,233 @@
---
title: 一键创建/销毁环境
---
本章将介绍如何使用 KubeVela 在交付应用时对环境进行快速初始化和销毁。
## 环境指什么？
一个应用开发团队通常需要做一些初始化工作来满足应用部署时方方面面的需要，即“初始化环境”。
这里的环境是一个逻辑概念，既可以表示应用部署时依赖的公共资源，也可以表示应用运行必要的准备工作。
KubeVela 同样是 Application 对象做环境的初始化，可以初始化的资源类型包括但不限于下列类型：
1. 一个或多个 Kubernetes 集群，不同的环境可能需要不同规模和不同版本的 Kubernetes 集群。同时环境初始化还可以将多个 Kubernetes 集群注册到一个中央集群进行统一的多集群管控。
2. 任意类型的 Kubernetes 自定义资源（CRD）和系统插件，一个环境会拥有很多种不同的自定义资源来提供系统能力，比如不同的工作负载、不同的运维管理功能等等。初始化环境可以包含环境所依赖的一系列功能的初始化安装，比如各类中间件工作负载、流量管理、日志监控等各类运维系统。
3. 各类共享资源和服务，一个微服务在不同环境中测试验证时，除了自身所开发的组件以外，往往还会包含一系列其他团队维护的组件和一些公共资源。环境初始化功能可以将其他组件和公共资源统一部署，在无需使用时销毁。这些共享资源可以是一个微服务组件、云数据库、缓存、负载均衡、API网关等等。
4. 各类管理策略和流程，一个环境可能会配备不同的全局策略和流程，举例来说，环境策略可能会包括混沌测试、安全扫描、错误配置检测、SLO指标等等；而流程则可以是初始化一个数据库表、注册一个自动发现配置等。
不仅如此，KubeVela 的环境初始化能力还可以跟工作流、策略、依赖等功能相结合，做不同环境的差异化部署，依赖管理等。
若不同环境初始化存在依赖关系，可以初始化的公共资源分离出一个单独的 Application 作为依赖，这样可以形成可以被复用的初始化模块。
例如，测试环境和开发环境都依赖了一些相同的控制器，可以将这些控制器提取出来作为单独的环境初始化，在开发环境和测试环境中都指定依赖该环境初始化。
## 如何使用
### 直接使用应用部署计划完成环境初始化
> 请确保你的 KubeVela 版本在 v1.1.6 及以上。
如果我们希望在环境中使用一个自定义 CRD 控制器(如 [OpenKruise](https://github.com/openkruise/kruise))，那么，我们可以使用 Helm 组件初始化 kruise。
我们可以直接使用 KubeVela 的应用部署计划来初始化 kruise 的环境，该应用会帮你在集群中部署一个 OpenKruise 的控制器，给集群提供 kruise 的各种能力。
由于我们使用 Helm 组件完成 kruise 的部署，我们首先要在集群中使用 `fluxcd` 开启 helm 功能。
当环境初始化具备多个模块时，可以对初始化的内容进行拆分，同时使用工作流的 `depends-on-app` 步骤，描述不同初始化模块的依赖关系。
比如我们可以在这个例子里，使用 `depends-on-app` 表示环境初始化 kruise 依赖环境初始化 fluxcd 提供的能力。
> `depends-on-app` 会根据 `properties` 中的 `name` 及 `namespace`，去查询集群中是否存在对应的应用。
如果应用存在，则当该应用的状态可用时，才会进行下一个步骤；
若该应用不存在，则会去查询同名的 configMap，从中读取出应用的配置并部署到集群中。
> 更详细的说明，请查看 [depends-on-app](../end-user/workflow/built-in-workflow-defs#depends-on-app)。
部署如下文件：
```shell
cat <<EOF | vela up -f -
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: kruise
namespace: vela-system
spec:
components:
- name: kruise
type: helm
properties:
branch: master
chart: ./charts/kruise/v0.9.0
version: "*"
repoType: git
url: https://github.com/openkruise/kruise
workflow:
steps:
- name: check-flux
type: depends-on-app
properties:
name: fluxcd
namespace: vela-system
- name: apply-kruise
type: apply-component
properties:
component: kruise
EOF
```
查看集群中应用的状态：
```shell
$ vela ls -n vela-system
APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
kruise ... raw running healthy 2021-09-24 20:59:06 +0800 CST
fluxcd ... raw running healthy 2021-09-24 20:59:06 +0800 CST
```
kruise 已经成功运行！之后，你可以在环境中使用 kruise 的能力。如果需要配置新的环境初始化，也只需要类似的定义一个部署计划。
### 在应用部署中加入初始化的工作流
在环境中，一些通用的 ConfigMap / PVC 等资源是十分常用的。
如果你希望在部署应用前内置一些通用资源，可以在应用部署中加入初始化的工作流来完成。
KubeVela 提供了一个内置的工作流步骤 `apply-object`，可以直接在组件的 `properties` 字段中填写创建到环境中的原生 Kubernetes 资源。
这种在 Application 中直接填写 Kubernetes 原生资源的方式，可以避免编写多余的组件定义（ComponentDefinition）。
部署如下应用，初始化一个带有 ConfigMap / PVC 的环境。同时，部署两个组件，第一个组件会不断向 PVC 中写入数据，第二个组件会读取 PVC 中的数据：
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: server-with-pvc-and-cm
namespace: default
spec:
components:
- name: log-gen-worker
type: worker
properties:
image: busybox
cmd:
- /bin/sh
- -c
- >
i=0;
while true;
do
echo "$i: $(date)" >> /test-pvc/date.log;
i=$((i+1));
sleep 1;
done
volumes:
- name: "my-pvc"
type: "pvc"
mountPath: "/test-pvc"
claimName: "my-claim"
- name: "my-configmap"
type: "configMap"
mountPath: "/test-cm"
cmName: "my-cm"
items:
- key: test-key
path: test-key
- name: log-read-worker
type: worker
properties:
name: count-log
image: busybox
cmd:
- /bin/sh
- -c
- 'tail -n+1 -f /test-pvc/date.log'
volumes:
- name: "my-pvc"
type: "pvc"
mountPath: "/test-pvc"
claimName: "my-claim"
- name: "my-configmap"
type: "configMap"
mountPath: "/test-cm"
cmName: "my-cm"
items:
- key: test-key
path: test-key
workflow:
steps:
- name: apply-pvc
type: apply-object
properties:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-claim
namespace: default
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 8Gi
storageClassName: standard
- name: apply-cm
type: apply-object
properties:
apiVersion: v1
kind: ConfigMap
metadata:
name: my-cm
namespace: default
data:
test-key: test-value
- name: apply-remaining
type: apply-remaining
```
查看集群中的 PVC 以及 ConfigMap：
```shell
$ kubectl get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
my-claim Bound pvc-2621d7d7-453c-41df-87fb-58e6b3a8e136 8Gi RWO standard 2m53s
$ kubectl get cm
NAME DATA AGE
my-cm 1 3m8s
```
查看集群中应用的状态：
```shell
$ vela ls
APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
server-with-pvc-and-cm log-gen-worker worker running healthy 2021-10-11 20:42:38 +0800 CST
└─ log-read-worker worker running 2021-10-11 20:42:38 +0800 CST
```
检查第二个组件的日志输出：
```shell
$ kubectl logs -f log-read-worker-774b58f565-ch8ch
0: Mon Oct 11 12:43:01 UTC 2021
1: Mon Oct 11 12:43:02 UTC 2021
2: Mon Oct 11 12:43:03 UTC 2021
3: Mon Oct 11 12:43:04 UTC 2021
4: Mon Oct 11 12:43:05 UTC 2021
5: Mon Oct 11 12:43:06 UTC 2021
6: Mon Oct 11 12:43:07 UTC 2021
7: Mon Oct 11 12:43:08 UTC 2021
```
可以看到，应用中的两个组件均已正常运行。同时，这两个组件共享同一个 PVC，并使用相同的 ConfigMap 进行配置。
## 如何销毁环境
因为我们已经通过应用（Application）这个统一的模型做了环境初始化，所以销毁环境变得非常简单，只需要删除这个应用即可。
```
vela delete server-with-pvc-and-cm
```
KubeVela 控制器会自动将资源删除。

154
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/case-studies/jenkins-cicd.md Normal file
View File

@ -0,0 +1,154 @@
---
title: Jenkins CI 集成
draft: true
---
本文将介绍如何使用 KubeVela 同已有的 CI 工具（比如 Jenkins）共同协作来进行应用的持续交付，并解释这样集成的好处是什么。
## 简介
KubeVela 作为一个普适的应用交付控制平面，只需要一点点集成工作就可以同任何现有的 CI/CD 系统对接起来，并且为它们带来一系列现代云原生应用交付的能力，比如：
- 混合云/多云应用交付；
- 跨环境发布（Promotion）；
- 基于 Service Mesh 的发布与回滚；
- 处理部署过程中的各种依赖关系和拓扑结构；
- 统一进行云服务的声明、部署和服务绑定；
- 无需强迫你的团队采纳完整的 GitOps 协作方式即可享受 GitOps 技术本身的[一系列好处](https://www.weave.works/blog/what-is-gitops-really)；
- …… 以及更多。
接下来，本文将会以一个 HTTP 服务的开发部署为例，介绍 KubeVela + Jenkins 方式下应用的持续集成与持续交付步骤。这个应用的具体代码在[这个 GitHub 库中](https://github.com/Somefive/KubeVela-demo-CICD-app)。
## 准备工作
在对接之前，用户首先需要确保以下环境。
1. 已部署好 Jenkins 服务并配置了 Docker 在 Jenkins 中的环境，包括相关插件及镜像仓库的访问权限。
2. 已配置好的 Git 仓库并开启 Webhook。确保 Git 仓库对应分支的变化能够通过 Webhook 触发 Jenkins 流水线的运行。
3. 准备好需要部署的 Kubernetes 集群环境，并在环境中安装 KubeVela 基础组件及 apiserver，确保 KubeVela apiserver 能够从公网访问到。
## 对接 Jenkins 与 KubeVela apiserver
在 Jenkins 中以下面的 Groovy 脚本为例设置部署流水线。可以将流水线中的 Git 地址、镜像地址、apiserver 的地址、应用命名空间及应用替换成自己的配置，同时在自己的代码仓库中存放 Dockerfile 及 app.yaml，用来构建及部署 KubeVela 应用。
```groovy
pipeline {
agent any
environment {
GIT_BRANCH = 'prod'
GIT_URL = 'https://github.com/Somefive/KubeVela-demo-CICD-app.git'
DOCKER_REGISTRY = 'https://registry.hub.docker.com'
DOCKER_CREDENTIAL = 'DockerHubCredential'
DOCKER_IMAGE = 'somefive/kubevela-demo-cicd-app'
APISERVER_URL = 'http://47.88.24.19'
APPLICATION_YAML = 'app.yaml'
APPLICATION_NAMESPACE = 'kubevela-demo-namespace'
APPLICATION_NAME = 'cicd-demo-app'
}
stages {
stage('Prepare') {
steps {
script {
def checkout = git branch: env.GIT_BRANCH, url: env.GIT_URL
env.GIT_COMMIT = checkout.GIT_COMMIT
env.GIT_BRANCH = checkout.GIT_BRANCH
echo "env.GIT_BRANCH=${env.GIT_BRANCH},env.GIT_COMMIT=${env.GIT_COMMIT}"
}
}
}
stage('Build') {
steps {
script {
docker.withRegistry(env.DOCKER_REGISTRY, env.DOCKER_CREDENTIAL) {
def customImage = docker.build(env.DOCKER_IMAGE)
customImage.push()
}
}
}
}
stage('Deploy') {
steps {
sh 'wget -q "https://github.com/mikefarah/yq/releases/download/v4.12.1/yq_linux_amd64"'
sh 'chmod +x yq_linux_amd64'
script {
def app = sh (
script: "./yq_linux_amd64 eval -o=json '.spec' ${env.APPLICATION_YAML} | sed -e 's/GIT_COMMIT/$GIT_COMMIT/g'",
returnStdout: true
)
echo "app: ${app}"
def response = httpRequest acceptType: 'APPLICATION_JSON', contentType: 'APPLICATION_JSON', httpMode: 'POST', requestBody: app, url: "${env.APISERVER_URL}/v1/namespaces/${env.APPLICATION_NAMESPACE}/applications/${env.APPLICATION_NAME}"
println('Status: '+response.status)
println('Response: '+response.content)
}
}
}
}
}
```
之后向流水线中使用的 Git 仓库的分支推送代码变更，Git 仓库的 Webhook 会触发 Jenkins 中新创建的流水线。该流水线会自动构建代码镜像并推送至镜像仓库，然后对 KubeVela apiserver 发送 POST 请求，将仓库中的应用配置文件部署到 Kubernetes 集群中。其中 app.yaml 可以参照以下样例。
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: kubevela-demo-app
spec:
components:
- name: kubevela-demo-app-web
type: webservice
properties:
image: somefive/kubevela-demo-cicd-app
imagePullPolicy: Always
port: 8080
traits:
- type: rollout
properties:
rolloutBatches:
- replicas: 2
- replicas: 3
batchPartition: 0
targetSize: 5
- type: labels
properties:
jenkins-build-commit: GIT_COMMIT
- type: ingress
properties:
domain: <your domain>
http:
"/": 8088
```
其中 GIT_COMMIT 会在 Jenkins 流水线中被替换为当前的 git commit id。这时可以通过 kubectl 命令查看 Kubernetes 集群中应用的部署情况。
```bash
$ kubectl get app -n kubevela-demo-namespace
NAME COMPONENT TYPE PHASE HEALTHY STATUS AGE
cicd-demo-app kubevela-demo-app-web webservice running true 102s
$ kubectl get deployment -n kubevela-demo-namespace
NAME READY UP-TO-DATE AVAILABLE AGE
kubevela-demo-app-web-v1 2/2 2 2 111s
$ kubectl get ingress -n kubevela-demo-namespace
NAME CLASS HOSTS ADDRESS PORTS AGE
kubevela-demo-app-web <none> <your domain> 198.11.175.125 80 117s
```
在部署的应用文件中，我们使用了灰度发布(Rollout)的特性，应用初始发布先创建 2 个 Pod，以便进行金丝雀验证。待验证完毕，你可以将应用配置中 Rollout 特性的 `batchPatition: 0` 删去，以便完成剩余实例的更新发布。这个机制大大提高发布的安全性和稳定性，同时你也可以根据实际需要，调整 Rollout 发布策略。
```bash
$ kubectl edit app -n kubevela-demo-namespace
application.core.oam.dev/cicd-demo-app edited
$ kubectl get deployment -n kubevela-demo-namespace
NAME READY UP-TO-DATE AVAILABLE AGE
kubevela-demo-app-web-v1 5/5 5 5 4m16s
$ curl http://<your domain>/
Version: 0.1.2
```
## 更多
详细的环境部署流程以及更加完整的应用滚动更新可以参考[博客](/blog/2021/09/02/kubevela-jenkins-cicd)。
## 下一步
- 学习 KubeVela 在 [GitOps](./gitops) 场景下的对接和使用方式。

527
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/case-studies/multi-cluster.md Normal file
View File

@ -0,0 +1,527 @@
---
title: 多集群应用交付
---
本章节将会介绍如何使用 KubeVela 分发多集群应用。
## 简介
如今，在越来越多的场景下，开发者和系统运维人员开始将应用部署在多个集群中：
* 由于 Kubernetes 集群存在着部署规模的局限性（单一集群最多容纳 5k 节点），需要应用多集群技术来部署、管理海量的应用。
* 考虑到稳定性及高可用性，同一个应用可以部署在多个集群中，以实现容灾、异地多活等需求。
* 应用可能需要部署在不同的区域来满足不同政府对于数据安全性的政策需求。
下文将会介绍如何在 KubeVela 中进行使用管理多集群应用。
## 准备工作
在使用多集群应用部署之前，你需要将子集群通过 KubeConfig 加入到 KubeVela 的管控中来。Vela CLI 可以帮你实现这一点。
```shell script
vela cluster join <your kubeconfig path>
```
该命令会自动使用 KubeConfig 中的 `context.cluster` 字段作为集群名称，你也可以使用 `--name` 参数来指定，如
```shell
$ vela cluster join beijing.kubeconfig --name beijing
$ vela cluster join hangzhou-1.kubeconfig --name hangzhou-1
$ vela cluster join hangzhou-2.kubeconfig --name hangzhou-2
```
在子集群加入 KubeVela 中后，你同样可以使用 CLI 命令来查看当前正在被 KubeVela 管控的所有集群。
```bash
$ vela cluster list
CLUSTER TYPE ENDPOINT ACCEPTED LABELS
local Internal - true
cluster-beijing X509Certificate <ENDPOINT_BEIJING> true
cluster-hangzhou-1 X509Certificate <ENDPOINT_HANGZHOU_1> true
cluster-hangzhou-2 X509Certificate <ENDPOINT_HANGZHOU_2> true
```
> 默认情况下，KubeVela 控制面所在的管控集群会被作为 `local` 集群进行注册。你可以通过它将应用资源部署在管控集群中。该 `local` 集群不能被修改或者删除。
如果你不需要某个子集群了，还可以将子集群从 KubeVela 管控中移除。
```shell script
$ vela cluster detach beijing
```
> 移除一个正在使用的集群是危险行为。不过如果你想要对集群的认证信息做修改，比如轮转证书，你可以强行删除它。
你也可以给你的集群打标签，帮助你选择要部署的集群。
```bash
$ vela cluster labels add cluster-hangzhou-1 region=hangzhou
$ vela cluster labels add cluster-hangzhou-2 region=hangzhou
$ vela cluster list
CLUSTER TYPE ENDPOINT ACCEPTED LABELS
local Internal - true
cluster-beijing X509Certificate <ENDPOINT_BEIJING> true
cluster-hangzhou-1 X509Certificate <ENDPOINT_HANGZHOU_1> true region=hangzhou
cluster-hangzhou-2 X509Certificate <ENDPOINT_HANGZHOU_2> true region=hangzhou
```
## 部署多集群应用
你只需要使用 `topology` 策略来声明要部署的集群，就可以部署多集群应用了。例如，你可以使用下面这个样例将 nginx webservice 部署在两个杭州集群中，
```bash
$ cat <<EOF | vela up -f -
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: basic-topology
namespace: examples
spec:
components:
- name: nginx-basic
type: webservice
properties:
image: nginx
traits:
- type: expose
properties:
port: [80]
policies:
- name: topology-hangzhou-clusters
type: topology
properties:
clusters: ["cluster-hangzhou-1", "cluster-hangzhou-2"]
EOF
```
你可以通过运行 `vela status` 来查看部署状态。
```bash
$ vela status basic-topology -n examples
About:
Name: basic-topology
Namespace: examples
Created at: 2022-04-08 14:37:54 +0800 CST
Status: workflowFinished
Workflow:
mode: DAG
finished: true
Suspend: false
Terminated: false
Steps
- id:3mvz5i8elj
name:deploy-topology-hangzhou-clusters
type:deploy
phase:succeeded
message:
Services:
- Name: nginx-basic
Cluster: cluster-hangzhou-1 Namespace: examples
Type: webservice
Healthy Ready:1/1
Traits:
✅ expose
- Name: nginx-basic
Cluster: cluster-hangzhou-2 Namespace: examples
Type: webservice
Healthy Ready:1/1
Traits:
✅ expose
```
### 调试多集群应用
你可以运行以下 CLI 命令调试上述的多集群应用。通过这些 CLI 命令，你可以在管控集群上直接操纵子集群中的资源，而不需要切换 KubeConfig 等集群配置。如果你的应用使用了多个集群，CLI 向你询问你希望操纵的集群。
- `vela status` 如上文所示，为你展示多集群应用的整体部署情况。
- `vela logs` 查询子集群中的 Pod 日志。
```bash
$ vela logs basic-topology -n examples
? You have 2 deployed resources in your app. Please choose one: Cluster: cluster-hangzhou-1 | Namespace: examples | Kind: Deployment | Name: nginx-basic
+ nginx-basic-dfb6dcf8d-km5vk › nginx-basic
nginx-basic-dfb6dcf8d-km5vk nginx-basic 2022-04-08T06:38:10.540430392Z /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
nginx-basic-dfb6dcf8d-km5vk nginx-basic 2022-04-08T06:38:10.540742240Z /docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
```
- `vela port-forward` 将子集群中的 Pod 或者 Service 通过端口映射到本地使其可以在本地被访问。
```bash
$ vela exec basic-topology -n examples -it -- ls
? You have 2 deployed resources in your app. Please choose one: Cluster: cluster-hangzhou-1 | Namespace: examples | Kind: Deployment | Name: nginx-basic
bin docker-entrypoint.d home media proc sbin tmp
boot docker-entrypoint.sh lib mnt root srv usr
dev etc lib64 opt run sys var
```
- `vela exec` 帮助你在子集群的 Pod 里执行命令。
```bash
$ vela port-forward basic-topology -n examples 8080:80
? You have 4 deployed resources in your app. Please choose one: Cluster: cluster-hangzhou-1 | Namespace: examples | Kind: Deployment | Name: nginx-basic
Forwarding from 127.0.0.1:8080 -> 80
Forwarding from [::1]:8080 -> 80
Forward successfully! Opening browser ...
Handling connection for 8080
```
## 进阶使用
### 理解多集群应用
下图为多集群应用的整体结构图。如图所示，所有的配置信息（包括应用、策略和工作流）都处于管控集群中。只有资源（如 deployment 或者 service）会被下发到子集群之中。
策略主要负责描述资源的位置以及它们应该如何被差异化配置。资源下发真正的执行者是工作流。在工作流中，`deploy` 步骤会根据引用的策略对资源进行差异化配置，然后再将它们分发到对应的集群中。
![multi-cluster-arch](../../../../../docs/resources/multi-cluster-arch.jpg)
### 配置部署目标
选择部署目标的最直接的方法就是在 `topology` 策略中声明你想要部署的集群名称。有的时候，使用标签来筛选要部署的集群会更方便，比如下面这个例子通过标签筛选出所有的杭州集群：
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: label-selector-topology
namespace: examples
spec:
components:
- name: nginx-label-selector
type: webservice
properties:
image: nginx
policies:
- name: topology-hangzhou-clusters
type: topology
properties:
clusterLabelSelector:
region: hangzhou
```
如果你想要在管控集群中部署应用，你也可以使用 `local` 集群。除此之外，你还可以选择希望部署的命名空间，取代应用原有的命名空间。
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: local-ns-topology
namespace: examples
spec:
components:
- name: nginx-local-ns
type: webservice
properties:
image: nginx
policies:
- name: topology-local
type: topology
properties:
clusters: ["local"]
namespace: examples-alternative
```
> 有时，出于安全考虑，你可能希望限制应用使其只能在自己的命名空间中部署资源。你可以通过在 KubeVela 控制器的启动参数中配置 `--allow-cross-namespace-resource=false` 来禁用跨集群部署。
### 控制部署工作流
默认情况下，如果你在应用中声明了多个 `topology` 策略，应用组件将会依次分发到这些目标位置上。
如果你想要控制整个部署流程，比如更改默认的部署顺序，或者是添加人工审核步骤，你可以显式使用 `deploy` 工作流步骤来实现。
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: deploy-workflowstep
namespace: examples
spec:
components:
- name: nginx-deploy-workflowstep
type: webservice
properties:
image: nginx
policies:
- name: topology-hangzhou-clusters
type: topology
properties:
clusterLabelSelector:
region: hangzhou
- name: topology-local
type: topology
properties:
clusters: ["local"]
namespace: examples-alternative
workflow:
steps:
- type: deploy
name: deploy-local
properties:
policies: ["topology-local"]
- type: deploy
name: deploy-hangzhou
properties:
# require manual approval before running this step
auto: false
policies: ["topology-hangzhou-clusters"]
```
如果你希望并行地部署所有集群，你可以在一个 `deploy` 工作流步骤中使用所有的 `topology` 策略。
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: deploy-concurrently
namespace: examples
spec:
components:
- name: nginx-deploy-concurrently
type: webservice
properties:
image: nginx
policies:
- name: topology-hangzhou-clusters
type: topology
properties:
clusterLabelSelector:
region: hangzhou
- name: topology-local
type: topology
properties:
clusters: ["local"]
namespace: examples-alternative
workflow:
steps:
- type: deploy
name: deploy-all
properties:
policies: ["topology-local", "topology-hangzhou-clusters"]
```
### 使用差异化配置
在一些情况下，你可能希望应用在不同的集群中有不一样的配置，而不是全都使用完全相同的默认配置。比如使用不同的镜像或者配置不同的副本数量。
`override` 策略可以帮助你实现差异化配置。你可以在 `deploy` 工作流步骤中，配合 `topology` 策略来使用它。
在下面的样例中，应用会在 `local` 集群中部署一个默认的 nginx webservcie，然后在杭州集群中部署含有 3 副本的高可用 nginx webservice，并且使用 `nginx:1.20` 镜像。
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: deploy-with-override
namespace: examples
spec:
components:
- name: nginx-with-override
type: webservice
properties:
image: nginx
policies:
- name: topology-hangzhou-clusters
type: topology
properties:
clusterLabelSelector:
region: hangzhou
- name: topology-local
type: topology
properties:
clusters: ["local"]
namespace: examples-alternative
- name: override-nginx-legacy-image
type: override
properties:
components:
- name: nginx-with-override
properties:
image: nginx:1.20
- name: override-high-availability
type: override
properties:
components:
- type: webservice
traits:
- type: scaler
properties:
replicas: 3
workflow:
steps:
- type: deploy
name: deploy-local
properties:
policies: ["topology-local"]
- type: deploy
name: deploy-hangzhou
properties:
policies: ["topology-hangzhou-clusters", "override-nginx-legacy-image", "override-high-availability"]
```
> 注意：override 策略是用来修改基础配置的策略，因此**它被设计成必须需要和 topology 策略一同使用**。如果你不想要使用 topology 策略，你可以直接将配置写在组件声明中，而不是使用 override 策略。*如果你错误的在 deploy 工作流步骤中使用了 override 策略，而没有使用 topology 策略，应用不会发生错误，但是也不会下发任何资源。*
差异化配置有一些高级配置能力，比如添加额外的组件，或者选择部分组件。下面的样例中，应用会首先在 `local` 集群中部署一个镜像为 `nginx:1.20` 的 webservice，然后再将 `nginx` 和 `nginx:stable` 两个 webservice 部署到杭州集群中
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: advance-override
namespace: examples
spec:
components:
- name: nginx-advance-override-legacy
type: webservice
properties:
image: nginx:1.20
- name: nginx-advance-override-latest
type: webservice
properties:
image: nginx
policies:
- name: topology-hangzhou-clusters
type: topology
properties:
clusterLabelSelector:
region: hangzhou
- name: topology-local
type: topology
properties:
clusters: ["local"]
namespace: examples-alternative
- name: override-nginx-legacy
type: override
properties:
selector: ["nginx-advance-override-legacy"]
- name: override-nginx-latest
type: override
properties:
selector: ["nginx-advance-override-latest", "nginx-advance-override-stable"]
components:
- name: nginx-advance-override-stable
type: webservice
properties:
image: nginx:stable
workflow:
steps:
- type: deploy
name: deploy-local
properties:
policies: ["topology-local", "override-nginx-legacy"]
- type: deploy
name: deploy-hangzhou
properties:
policies: ["topology-hangzhou-clusters", "override-nginx-latest"]
```
### 使用外置策略和工作流
有时，你可能希望在不同的应用之间使用相同的策略，或者在部署资源的时候复用之前的工作流配置。
为了减少重复的配置，你可以使用外置的策略和工作流，并在应用中引用它们。
> 注意：你只能在应用中引用相同命名空间下的策略和工作流。
```yaml
apiVersion: core.oam.dev/v1alpha1
kind: Policy
metadata:
name: topology-hangzhou-clusters
namespace: examples
type: topology
properties:
clusterLabelSelector:
region: hangzhou
---
apiVersion: core.oam.dev/v1alpha1
kind: Policy
metadata:
name: override-high-availability-webservice
namespace: examples
type: override
properties:
components:
- type: webservice
traits:
- type: scaler
properties:
replicas: 3
---
apiVersion: core.oam.dev/v1alpha1
kind: Workflow
metadata:
name: make-release-in-hangzhou
namespace: examples
steps:
- type: deploy
name: deploy-hangzhou
properties:
auto: false
policies: ["override-high-availability-webservice", "topology-hangzhou-clusters"]
```
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: external-policies-and-workflow
namespace: examples
spec:
components:
- name: nginx-external-policies-and-workflow
type: webservice
properties:
image: nginx
workflow:
ref: make-release-in-hangzhou
```
> 注意：内置的策略会被优先使用。只有当工作流使用的策略不存在于内置策略中时才会使用外置策略。在下面的样例中，你可以复用 `topology-hangzhou-clusters` 策略以及 `make-release-in-hangzhou` 工作流，但是通过在应用中声明 `override-high-availability-webservice` 策略来覆盖同名的外置策略。
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: nginx-stable-ultra
namespace: examples
spec:
components:
- name: nginx-stable-ultra
type: webservice
properties:
image: nginx:stable
policies:
- name: override-high-availability-webservice
type: override
properties:
components:
- type: webservice
traits:
- type: scaler
properties:
replicas: 5
workflow:
ref: make-release-in-hangzhou
```
## 兼容性
KubeVela 的 v1.3 应用相较于之前的版本使用了不同的策略和工作流步骤来分发、管理多集群应用。
旧版本中的 `env-binding` 策略以及 `deploy2env` 工作流步骤在目前版本中仍保留并兼容，但可能会在未来的版本中逐步废弃。
新的策略和工作流步骤可以完全覆盖旧版本中多集群应用的所有使用场景，而且提供了更强的能力。自动化升级工具将会在废弃旧版本之前提供给用户。
如果你已经在生产环境中使用了旧版本的多集群应用，并且不希望改变他们，KubeVela v1.3 可以完全兼容它们，而不需要对应用进行升级。

58
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/cli/vela.md Normal file
View File

@ -0,0 +1,58 @@
---
title: CLI Commands
---
## Getting Started
* [vela env](vela_env) - Manage environments for vela applications to run.
* [vela init](vela_init) - Create scaffold for vela application.
* [vela up](vela_up) - Deploy one application
Deploy one application based on local files or re-deploy an existing application. With the -n/--namespace flag, you can choose the location of the target application.
To apply application from file, use the -f/--file flag to specify the application file location.
To give a particular version to this deploy, use the -v/--publish-version flag. When you are deploying an existing application, the version name must be different from the current name. You can also use a history revision for the deploy and override the current application by using the -r/--revision flag.
* [vela show](vela_show) - Show the reference doc for component, trait or workflow types.
## Managing Applications
* [vela ls](vela_ls) - List all vela applications.
* [vela status](vela_status) - Show status of vela application.
* [vela delete](vela_delete) - Delete an application.
* [vela exec](vela_exec) - Execute command inside container based vela application.
* [vela port-forward](vela_port-forward) - Forward local ports to container/service port of vela application.
* [vela logs](vela_logs) - Tail logs for vela application.
* [vela live-diff](vela_live-diff) - Compare application and revisions
* [vela ql](vela_ql) - Show result of executing velaQL.
* [vela dry-run](vela_dry-run) - Dry-run application locally, render the Kubernetes resources as result to stdout.
* [vela revision](vela_revision) - Manage KubeVela Application Revisions
## Continuous Delivery
* [vela auth](vela_auth) -
* [vela cluster](vela_cluster) - Manage Kubernetes Clusters for Continuous Delivery.
* [vela kube](vela_kube) -
* [vela workflow](vela_workflow) - Operate the Workflow during Application Delivery.
## Managing Extension
* [vela addon](vela_addon) - Manage addons for extension.
* [vela uischema](vela_uischema) - Manage UI schema for addons.
* [vela def](vela_def) - Manage X-Definitions for extension.
* [vela registry](vela_registry) - Manage Registry of X-Definitions for extension.
* [vela provider](vela_provider) - Authenticate Terraform Cloud Providers by managing Terraform Controller Providers with its credential secret
* [vela component](vela_component) - List component types installed and discover more in registry.
* [vela trait](vela_trait) - List trait types installed and discover more in registry.
## Others
* [vela uninstall](vela_uninstall) - Uninstalls KubeVela from a Kubernetes cluster.
* [vela install](vela_install) - The Kubevela CLI allows installing Kubevela on any Kubernetes derivative to which your kube config is pointing to.
* [vela completion](vela_completion) - Output shell completion code for the specified shell (bash or zsh).
The shell code must be evaluated to provide interactive completion of vela commands.
* [vela export](vela_export) - Export deploy manifests from appfile or application.
* [vela version](vela_version) - Prints vela build version information.
###### Auto generated by [script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

37
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/cli/vela_addon.md Normal file
View File

@ -0,0 +1,37 @@
---
title: vela addon
---
Manage addons for extension.
### Synopsis
Manage addons for extension.
### Options
```
-h, --help help for addon
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela addon disable](vela_addon_disable) - disable an addon
* [vela addon enable](vela_addon_enable) - enable an addon
* [vela addon list](vela_addon_list) - List addons
* [vela addon package](vela_addon_package) - package an addon directory
* [vela addon registry](vela_addon_registry) - Manage addon registry.
* [vela addon status](vela_addon_status) - get an addon's status.
* [vela addon upgrade](vela_addon_upgrade) - upgrade an addon
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

41
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/cli/vela_addon_disable.md Normal file
View File

@ -0,0 +1,41 @@
---
title: vela addon disable
---
disable an addon
### Synopsis
disable an addon in cluster.
```
vela addon disable [flags]
```
### Examples
```
vela addon disable <addon-name>
```
### Options
```
-f, --force skip checking if applications are still using this addon
-h, --help help for disable
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela addon](vela_addon) - Manage addons for extension.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

49
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/cli/vela_addon_enable.md Normal file
View File

@ -0,0 +1,49 @@
---
title: vela addon enable
---
enable an addon
### Synopsis
enable an addon in cluster.
```
vela addon enable [flags]
```
### Examples
```
\
Enable addon by:
vela addon enable <addon-name>
Enable addon with specify version:
vela addon enable <addon-name> --version <addon-version>
Enable addon for specific clusters, (local means control plane):
vela addon enable <addon-name> --clusters={local,cluster1,cluster2}
```
### Options
```
-c, --clusters string specify the runtime-clusters to enable
-h, --help help for enable
-v, --version string specify the addon version to enable
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela addon](vela_addon) - Manage addons for extension.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

34
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/cli/vela_addon_list.md Normal file
View File

@ -0,0 +1,34 @@
---
title: vela addon list
---
List addons
### Synopsis
List addons in KubeVela
```
vela addon list [flags]
```
### Options
```
-h, --help help for list
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela addon](vela_addon) - Manage addons for extension.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

40
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/cli/vela_addon_package.md Normal file
View File

@ -0,0 +1,40 @@
---
title: vela addon package
---
package an addon directory
### Synopsis
package an addon directory into a helm chart archive.
```
vela addon package [flags]
```
### Examples
```
vela addon package <addon directory>
```
### Options
```
-h, --help help for package
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela addon](vela_addon) - Manage addons for extension.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

35
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/cli/vela_addon_registry.md Normal file
View File

@ -0,0 +1,35 @@
---
title: vela addon registry
---
Manage addon registry.
### Synopsis
Manage addon registry.
### Options
```
-h, --help help for registry
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela addon](vela_addon) - Manage addons for extension.
* [vela addon registry add](vela_addon_registry_add) - Add an addon registry.
* [vela addon registry delete](vela_addon_registry_delete) - Delete an addon registry
* [vela addon registry get](vela_addon_registry_get) - Get an addon registry.
* [vela addon registry list](vela_addon_registry_list) - List addon registries.
* [vela addon registry update](vela_addon_registry_update) - Update an addon registry.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

47
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/cli/vela_addon_registry_add.md Normal file
View File

@ -0,0 +1,47 @@
---
title: vela addon registry add
---
Add an addon registry.
### Synopsis
Add an addon registry.
```
vela addon registry add [flags]
```
### Examples
```
"vela addon registry add <my-registry-name> --type OSS --endpoint=<URL> --bucket=<bukect-name> or vela addon registry add my-repo --type git --endpoint=<URL> --path=<OSS-ptah> --gitToken=<git token>"
```
### Options
```
--bucket string specify the OSS bucket name
--endpoint string specify the addon registry endpoint
--gitToken string specify the github repo token
-h, --help help for add
--password string specify the Helm addon registry password
--path string specify the addon registry OSS path
--type string specify the addon registry type
--username string specify the Helm addon registry username
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela addon registry](vela_addon_registry) - Manage addon registry.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

40
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/cli/vela_addon_registry_delete.md Normal file
View File

@ -0,0 +1,40 @@
---
title: vela addon registry delete
---
Delete an addon registry
### Synopsis
Delete an addon registry
```
vela addon registry delete [flags]
```
### Examples
```
vela addon registry delete <registry-name>
```
### Options
```
-h, --help help for delete
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela addon registry](vela_addon_registry) - Manage addon registry.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

40
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/cli/vela_addon_registry_get.md Normal file
View File

@ -0,0 +1,40 @@
---
title: vela addon registry get
---
Get an addon registry.
### Synopsis
Get an addon registry.
```
vela addon registry get [flags]
```
### Examples
```
vela addon registry get <registry name>
```
### Options
```
-h, --help help for get
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela addon registry](vela_addon_registry) - Manage addon registry.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

40
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/cli/vela_addon_registry_list.md Normal file
View File

@ -0,0 +1,40 @@
---
title: vela addon registry list
---
List addon registries.
### Synopsis
List addon registries.
```
vela addon registry list [flags]
```
### Examples
```
vela addon registry list
```
### Options
```
-h, --help help for list
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela addon registry](vela_addon_registry) - Manage addon registry.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

47
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/cli/vela_addon_registry_update.md Normal file
View File

@ -0,0 +1,47 @@
---
title: vela addon registry update
---
Update an addon registry.
### Synopsis
Update an addon registry.
```
vela addon registry update [flags]
```
### Examples
```
vela addon registry update <registry-name> --type OSS --endpoint=<URL> --bucket=<bucket name>
```
### Options
```
--bucket string specify the OSS bucket name
--endpoint string specify the addon registry endpoint
--gitToken string specify the github repo token
-h, --help help for update
--password string specify the Helm addon registry password
--path string specify the addon registry OSS path
--type string specify the addon registry type
--username string specify the Helm addon registry username
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela addon registry](vela_addon_registry) - Manage addon registry.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

41
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/cli/vela_addon_status.md Normal file
View File

@ -0,0 +1,41 @@
---
title: vela addon status
---
get an addon's status.
### Synopsis
get an addon's status from cluster.
```
vela addon status [flags]
```
### Examples
```
vela addon status <addon-name>
```
### Options
```
-h, --help help for status
-v, --verbose show addon descriptions and parameters in addition to status
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela addon](vela_addon) - Manage addons for extension.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

48
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/cli/vela_addon_upgrade.md Normal file
View File

@ -0,0 +1,48 @@
---
title: vela addon upgrade
---
upgrade an addon
### Synopsis
upgrade an addon in cluster.
```
vela addon upgrade [flags]
```
### Examples
```
\
Upgrade addon by:
vela addon upgrade <addon-name>
Upgrade addon with specify version:
vela addon upgrade <addon-name> --version <addon-version>
Upgrade addon for specific clusters, (local means control plane):
vela addon upgrade <addon-name> --clusters={local,cluster1,cluster2}
```
### Options
```
-h, --help help for upgrade
-v, --version string specify the addon version to upgrade
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela addon](vela_addon) - Manage addons for extension.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

29
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/cli/vela_auth.md Normal file
View File

@ -0,0 +1,29 @@
---
title: vela auth
---
Manage identity and authorizations.
### Options
```
-h, --help help for auth
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela auth gen-kubeconfig](vela_auth_gen-kubeconfig) - Generate kubeconfig for user
* [vela auth grant-privileges](vela_auth_grant-privileges) - Grant privileges for user/group/serviceaccount
* [vela auth list-privileges](vela_auth_list-privileges) - List privileges for user/group/serviceaccount
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

61
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/cli/vela_auth_gen-kubeconfig.md Normal file
View File

@ -0,0 +1,61 @@
---
title: vela auth gen-kubeconfig
---
Generate kubeconfig for user
### Synopsis
Generate kubeconfig for user
Generate a new kubeconfig with specified identity. By default, the generated kubeconfig will reuse the certificate-authority-data in the cluster config from the current used kubeconfig. All contexts, clusters and users that are not in use will not be included in the generated kubeconfig.
To generate a new kubeconfig for given user and groups, use the --user and --group flag. Multiple --group flags is allowed. The group kubevela:client is added to the groups by default. The identity in the current kubeconfig should be able to approve CertificateSigningRequest in the kubernetes cluster. See https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/ for details.
To generate a kubeconfig based on existing ServiceAccount in your cluster, use the --serviceaccount flag. The corresponding secret token and ca data will be embedded in the generated kubeconfig, which allows you to act as the serviceaccount.
```
vela auth gen-kubeconfig
```
### Examples
```
# Generate a kubeconfig with provided user
vela auth gen-kubeconfig --user new-user
# Generate a kubeconfig with provided user and group
vela auth gen-kubeconfig --user new-user --group kubevela:developer
# Generate a kubeconfig with provided user and groups
vela auth gen-kubeconfig --user new-user --group kubevela:developer --group my-org:my-team
# Generate a kubeconfig with provided serviceaccount
vela auth gen-kubeconfig --serviceaccount default -n demo
```
### Options
```
-e, --env string The environment name for the CLI request
-g, --group --user The groups of the generated kubeconfig. This flag only works when --user is set. It will be embedded as the Organization in the X509 certificate.
-h, --help help for gen-kubeconfig
-n, --namespace --serviceaccount The namespace of the serviceaccount. This flag only works when --serviceaccount is set.
--serviceaccount --user The serviceaccount of the generated kubeconfig. If set, a kubeconfig will be generated based on the secret token of the serviceaccount. Cannot be set when --user presents.
-u, --user string The user of the generated kubeconfig. If set, an X509-based kubeconfig will be intended to create. It will be embedded as the Subject in the X509 certificate.
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela auth](vela_auth) - Manage identity and authorizations.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

76
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/cli/vela_auth_grant-privileges.md Normal file
View File

@ -0,0 +1,76 @@
---
title: vela auth grant-privileges
---
Grant privileges for user/group/serviceaccount
### Synopsis
Grant privileges for user
Grant privileges to user/group/serviceaccount. By using --for-namespace and --for-cluster, you can grant all read/write privileges for all resources in the specified namespace and cluster. If --for-namespace is not set, the privileges will be granted cluster-wide.
Setting --create-namespace will automatically create namespace if the namespace of the granted privilege does not exists. By default, this flag is not enabled and errors will be returned if the namespace is not found in the corresponding cluster.
Setting --readonly will only grant read privileges for all resources in the destination. This can be useful if you want to give somebody the privileges to view resources but do not want to allow them to edit any resource.
If multiple identity information are set, all the identity information will be bond to the intended privileges respectively.
If --kubeconfig is set, the user/serviceaccount information in the kubeconfig will be used as the identity to grant privileges. Groups will be ignored.
```
vela auth grant-privileges
```
### Examples
```
# Grant privileges for User alice in the namespace demo of the control plane
vela auth grant-privileges --user alice --for-namespace demo
# Grant privileges for User alice in the namespace demo in cluster-1, create demo namespace if not exist
vela auth grant-privileges --user alice --for-namespace demo --for-cluster cluster-1 --create-namespace
# Grant cluster-scoped privileges for Group org:dev-team in the control plane
vela auth grant-privileges --group org:dev-team
# Grant privileges for Group org:dev-team and org:test-team in the namespace test on the control plane and managed cluster example-cluster
vela auth grant-privileges --group org:dev-team --group org:test-team --for-namespace test --for-cluster local --for-cluster example-cluster
# Grant read privileges for ServiceAccount observer in test namespace on the control plane
vela auth grant-privileges --serviceaccount observer -n test --for-namespace test --readonly
# Grant privileges for identity in kubeconfig in cluster-1
vela auth grant-privileges --kubeconfig ./example.kubeconfig --for-cluster cluster-1
```
### Options
```
--create-namespace If set, non-exist namespace will be created automatically.
-e, --env string The environment name for the CLI request
--for-cluster strings The clusters privileges to grant. If empty, the control plane will be used.
--for-namespace strings The namespaces privileges to grant. If empty, cluster-scoped privileges will be granted.
-g, --group strings The group to grant privileges.
-h, --help help for grant-privileges
--kubeconfig string The kubeconfig to grant privileges. If set, it will override all the other identity flags.
-n, --namespace --serviceaccount The namespace of the serviceaccount. This flag only works when --serviceaccount is set.
--readonly If set, only read privileges of resources will be granted. Otherwise, read/write privileges will be granted.
--serviceaccount string The serviceaccount to grant privileges.
-u, --user string The user to grant privileges.
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela auth](vela_auth) - Manage identity and authorizations.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

68
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/cli/vela_auth_list-privileges.md Normal file
View File

@ -0,0 +1,68 @@
---
title: vela auth list-privileges
---
List privileges for user/group/serviceaccount
### Synopsis
List privileges for user
List privileges that user has in clusters. Use --user/--group to check the privileges for specified user and group. They can be jointly configured to see the union of privileges. Use --serviceaccount and -n/--namespace to see the privileges for ServiceAccount. You can also use --kubeconfig to use the identity inside implicitly. The privileges will be shown in tree format.
This command supports listing privileges across multiple clusters, by using --cluster. If not set, the control plane will be used. This feature requires cluster-gateway to be properly setup to use.
The privileges are collected through listing all ClusterRoleBinding and RoleBinding, following the Kubernetes RBAC Authorization. Other authorization mechanism is not supported now. See https://kubernetes.io/docs/reference/access-authn-authz/rbac/ for details.
The ClusterRoleBinding and RoleBinding that matches the specified identity will be tracked. Related ClusterRoles and Roles are retrieved and the contained PolicyRules are demonstrated.
```
vela auth list-privileges
```
### Examples
```
# List privileges for User alice in the control plane
vela auth list-privileges --user alice
# List privileges for Group org:dev-team in the control plane
vela auth list-privileges --group org:dev-team
# List privileges for User bob with Groups org:dev-team and org:test-team in the control plane and managed cluster example-cluster
vela auth list-privileges --user bob --group org:dev-team --group org:test-team --cluster local --cluster example-cluster
# List privileges for ServiceAccount example-sa in demo namespace in multiple managed clusters
vela auth list-privileges --serviceaccount example-sa -n demo --cluster cluster-1 --cluster cluster-2
# List privileges for identity in kubeconfig
vela auth list-privileges --kubeconfig ./example.kubeconfig --cluster local --cluster cluster-1
```
### Options
```
-c, --cluster strings The cluster to list privileges. If not set, the command will list privileges in the control plane. (default [local])
-e, --env string The environment name for the CLI request
-g, --group strings The group to list privileges. Can be set together with --user.
-h, --help help for list-privileges
--kubeconfig string The kubeconfig to list privileges. If set, it will override all the other identity flags.
-n, --namespace --serviceaccount The namespace of the serviceaccount. This flag only works when --serviceaccount is set.
--serviceaccount string The serviceaccount to list privileges. Cannot be set with --user and --group.
-u, --user string The user to list privileges.
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela auth](vela_auth) - Manage identity and authorizations.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

37
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/cli/vela_cluster.md Normal file
View File

@ -0,0 +1,37 @@
---
title: vela cluster
---
Manage Kubernetes Clusters
### Synopsis
Manage Kubernetes Clusters for Continuous Delivery.
### Options
```
-h, --help help for cluster
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela cluster alias](vela_cluster_alias) - alias a named cluster.
* [vela cluster detach](vela_cluster_detach) - detach managed cluster.
* [vela cluster join](vela_cluster_join) - join managed cluster.
* [vela cluster labels](vela_cluster_labels) - Manage Kubernetes Cluster Labels
* [vela cluster list](vela_cluster_list) - list managed clusters
* [vela cluster probe](vela_cluster_probe) - health probe managed cluster.
* [vela cluster rename](vela_cluster_rename) - rename managed cluster.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

34
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/cli/vela_cluster_alias.md Normal file
View File

@ -0,0 +1,34 @@
---
title: vela cluster alias
---
alias a named cluster.
### Synopsis
alias a named cluster.
```
vela cluster alias CLUSTER_NAME ALIAS [flags]
```
### Options
```
-h, --help help for alias
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela cluster](vela_cluster) - Manage Kubernetes Clusters
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

35
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/cli/vela_cluster_detach.md Normal file
View File

@ -0,0 +1,35 @@
---
title: vela cluster detach
---
detach managed cluster.
### Synopsis
detach managed cluster.
```
vela cluster detach [CLUSTER_NAME] [flags]
```
### Options
```
-h, --help help for detach
-p, --kubeconfig-path string Specify the kubeconfig path of managed cluster. If you use ocm to manage your cluster, you must set the kubeconfig-path.
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela cluster](vela_cluster) - Manage Kubernetes Clusters
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

45
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/cli/vela_cluster_join.md Normal file
View File

@ -0,0 +1,45 @@
---
title: vela cluster join
---
join managed cluster.
### Synopsis
join managed cluster by kubeconfig.
```
vela cluster join [KUBECONFIG] [flags]
```
### Examples
```
# Join cluster declared in my-child-cluster.kubeconfig
> vela cluster join my-child-cluster.kubeconfig --name example-cluster
```
### Options
```
--create-namespace string Specifies the namespace need to create in managedCluster (default "vela-system")
-t, --engine string Specify the cluster management engine. If empty, it will use cluster-gateway cluster management solution. Default to be empty. (default "cluster-gateway")
-h, --help help for join
--in-cluster-boostrap If true, the registering managed cluster will use the internal endpoint prescribed in the hub cluster's configmap "kube-public/cluster-info to register "itself to the hub cluster. Otherwise use the original endpoint from the hub kubeconfig. (default true)
-n, --name string Specify the cluster name. If empty, it will use the cluster name in config file. Default to be empty.
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela cluster](vela_cluster) - Manage Kubernetes Clusters
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

32
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/cli/vela_cluster_labels.md Normal file
View File

@ -0,0 +1,32 @@
---
title: vela cluster labels
---
Manage Kubernetes Cluster Labels
### Synopsis
Manage Kubernetes Cluster Labels for Continuous Delivery.
### Options
```
-h, --help help for labels
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela cluster](vela_cluster) - Manage Kubernetes Clusters
* [vela cluster labels add](vela_cluster_labels_add) - add labels to managed cluster
* [vela cluster labels del](vela_cluster_labels_del) - delete labels for managed cluster
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

40
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/cli/vela_cluster_labels_add.md Normal file
View File

@ -0,0 +1,40 @@
---
title: vela cluster labels add
---
add labels to managed cluster
### Synopsis
add labels to managed cluster
```
vela cluster labels add CLUSTER_NAME LABELS [flags]
```
### Examples
```
vela cluster labels add my-cluster project=kubevela,owner=oam-dev
```
### Options
```
-h, --help help for add
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela cluster labels](vela_cluster_labels) - Manage Kubernetes Cluster Labels
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

40
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/cli/vela_cluster_labels_del.md Normal file
View File

@ -0,0 +1,40 @@
---
title: vela cluster labels del
---
delete labels for managed cluster
### Synopsis
delete labels for managed cluster
```
vela cluster labels del CLUSTER_NAME LABELS [flags]
```
### Examples
```
vela cluster labels del my-cluster project,owner
```
### Options
```
-h, --help help for del
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela cluster labels](vela_cluster_labels) - Manage Kubernetes Cluster Labels
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

34
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/cli/vela_cluster_list.md Normal file
View File

@ -0,0 +1,34 @@
---
title: vela cluster list
---
list managed clusters
### Synopsis
list worker clusters managed by KubeVela.
```
vela cluster list [flags]
```
### Options
```
-h, --help help for list
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela cluster](vela_cluster) - Manage Kubernetes Clusters
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

34
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/cli/vela_cluster_probe.md Normal file
View File

@ -0,0 +1,34 @@
---
title: vela cluster probe
---
health probe managed cluster.
### Synopsis
health probe managed cluster.
```
vela cluster probe [CLUSTER_NAME] [flags]
```
### Options
```
-h, --help help for probe
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela cluster](vela_cluster) - Manage Kubernetes Clusters
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

34
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/cli/vela_cluster_rename.md Normal file
View File

@ -0,0 +1,34 @@
---
title: vela cluster rename
---
rename managed cluster.
### Synopsis
rename managed cluster.
```
vela cluster rename [OLD_NAME] [NEW_NAME] [flags]
```
### Options
```
-h, --help help for rename
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela cluster](vela_cluster) - Manage Kubernetes Clusters
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

33
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/cli/vela_completion.md Normal file
View File

@ -0,0 +1,33 @@
---
title: vela completion
---
Output shell completion code for the specified shell (bash or zsh)
### Synopsis
Output shell completion code for the specified shell (bash or zsh).
The shell code must be evaluated to provide interactive completion of vela commands.
### Options
```
-h, --help help for completion
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela completion bash](vela_completion_bash) - generate autocompletions script for bash
* [vela completion zsh](vela_completion_zsh) - generate autocompletions script for zsh
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

44
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/cli/vela_completion_bash.md Normal file
View File

@ -0,0 +1,44 @@
---
title: vela completion bash
---
generate autocompletions script for bash
### Synopsis
Generate the autocompletion script for Vela for the bash shell.
To load completions in your current shell session:
$ source <(vela completion bash)
To load completions for every new session, execute once:
Linux:
$ vela completion bash > /etc/bash_completion.d/vela
MacOS:
$ vela completion bash > /usr/local/etc/bash_completion.d/vela
```
vela completion bash
```
### Options
```
-h, --help help for bash
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela completion](vela_completion) - Output shell completion code for the specified shell (bash or zsh)
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

41
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/cli/vela_completion_zsh.md Normal file
View File

@ -0,0 +1,41 @@
---
title: vela completion zsh
---
generate autocompletions script for zsh
### Synopsis
Generate the autocompletion script for Vela for the zsh shell.
To load completions in your current shell session:
$ source <(vela completion zsh)
To load completions for every new session, execute once:
$ vela completion zsh > "${fpath[1]}/_vela"
```
vela completion zsh
```
### Options
```
-h, --help help for zsh
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela completion](vela_completion) - Output shell completion code for the specified shell (bash or zsh)
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

46
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/cli/vela_component.md Normal file
View File

@ -0,0 +1,46 @@
---
title: vela component
---
List/get components
### Synopsis
List component types installed and discover more in registry.
```
vela component [flags]
```
### Examples
```
vela comp
```
### Options
```
--discover discover traits in registries
-h, --help help for component
--label --label type=terraform a label to filter components, the format is --label type=terraform
--registry string specify the registry name (default "default")
--token string specify token when using --url to specify registry url
--url string specify the registry URL
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela component get](vela_component_get) - get component from registry
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

43
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/cli/vela_component_get.md Normal file
View File

@ -0,0 +1,43 @@
---
title: vela component get
---
get component from registry
### Synopsis
get/download/install component from registry.
```
vela component get <component> [flags]
```
### Examples
```
vela comp get <component>
```
### Options
```
-h, --help help for get
```
### Options inherited from parent commands
```
--registry string specify the registry name (default "default")
--token string specify token when using --url to specify registry url
--url string specify the registry URL
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela component](vela_component) - List/get components
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

44
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/cli/vela_debug.md Normal file
View File

@ -0,0 +1,44 @@
---
title: vela debug
---
Debug running application
### Synopsis
Debug running application with debug policy.
```
vela debug [flags]
```
### Examples
```
vela debug <application-name>
```
### Options
```
-e, --env string specify environment name for application
-f, --focus string specify the focus value to debug, only valid for application with workflow
-h, --help help for debug
-n, --namespace string specify the Kubernetes namespace to use
-s, --step string specify the step or component to debug
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

40
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/cli/vela_def.md Normal file
View File

@ -0,0 +1,40 @@
---
title: vela def
---
Manage Definitions
### Synopsis
Manage X-Definitions for extension.
### Options
```
-h, --help help for def
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela def apply](vela_def_apply) - Apply X-Definition.
* [vela def del](vela_def_del) - Delete X-Definition.
* [vela def doc-gen](vela_def_doc-gen) - Generate documentation of definitions (Only Terraform typed definitions are supported)
* [vela def edit](vela_def_edit) - Edit X-Definition.
* [vela def gen-api](vela_def_gen-api) - Generate Go struct of Parameter from X-Definition.
* [vela def get](vela_def_get) - Get definition
* [vela def init](vela_def_init) - Init a new definition
* [vela def list](vela_def_list) - List definitions.
* [vela def render](vela_def_render) - Render X-Definition.
* [vela def vet](vela_def_vet) - Validate X-Definition.
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

46
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/cli/vela_def_apply.md Normal file
View File

@ -0,0 +1,46 @@
---
title: vela def apply
---
Apply X-Definition.
### Synopsis
Apply X-Definition from local storage to kubernetes cluster. It will apply file to vela-system namespace by default.
```
vela def apply DEFINITION.cue [flags]
```
### Examples
```
# Command below will apply the local my-webservice.cue file to kubernetes vela-system namespace
> vela def apply my-webservice.cue
# Command below will apply the ./defs/my-trait.cue file to kubernetes default namespace
> vela def apply ./defs/my-trait.cue --namespace default# Command below will convert the ./defs/my-trait.cue file to kubernetes CRD object and print it without applying it to kubernetes
> vela def apply ./defs/my-trait.cue --dry-run
```
### Options
```
--dry-run only build definition from CUE into CRB object without applying it to kubernetes clusters
-h, --help help for apply
-n, --namespace string Specify which namespace to apply. (default "vela-system")
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela def](vela_def) - Manage Definitions
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

43
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/cli/vela_def_del.md Normal file
View File

@ -0,0 +1,43 @@
---
title: vela def del
---
Delete X-Definition.
### Synopsis
Delete X-Definition in kubernetes cluster.
```
vela def del DEFINITION_NAME [flags]
```
### Examples
```
# Command below will delete TraitDefinition of annotations in default namespace
> vela def del annotations -t trait -n default
```
### Options
```
-h, --help help for del
-n, --namespace string Specify which namespace the definition locates.
-t, --type string Specify the definition type of target. Valid types: component, trait, policy, workload, scope, workflow-step
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela def](vela_def) - Manage Definitions
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

45
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/cli/vela_def_doc-gen.md Normal file
View File

@ -0,0 +1,45 @@
---
title: vela def doc-gen
---
Generate documentation of definitions (Only Terraform typed definitions are supported)
### Synopsis
Generate documentation of definitions
```
vela def doc-gen NAME [flags]
```
### Examples
```
1. Generate documentation for ComponentDefinition alibaba-vpc:
> vela def doc-gen alibaba-vpc -n vela-system
2. Generate documentation for local ComponentDefinition file alibaba-vpc.yaml:
> vela def doc-gen alibaba-vpc.yaml
```
### Options
```
-h, --help help for doc-gen
-n, --namespace string Specify the namespace of the definition.
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela def](vela_def) - Manage Definitions
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

46
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/cli/vela_def_edit.md Normal file
View File

@ -0,0 +1,46 @@
---
title: vela def edit
---
Edit X-Definition.
### Synopsis
Edit X-Definition in kubernetes. If type and namespace are not specified, the command will automatically search all possible results.
By default, this command will use the vi editor and can be altered by setting EDITOR environment variable.
```
vela def edit NAME [flags]
```
### Examples
```
# Command below will edit the ComponentDefinition (and other definitions if exists) of webservice in kubernetes
> vela def edit webservice
# Command below will edit the TraitDefinition of ingress in vela-system namespace
> vela def edit ingress --type trait --namespace vela-system
```
### Options
```
-h, --help help for edit
-n, --namespace string Specify which namespace to get. If empty, all namespaces will be searched.
-t, --type string Specify which definition type to get. If empty, all types will be searched. Valid types: workload, scope, workflow-step, component, trait, policy
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela def](vela_def) - Manage Definitions
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

45
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/cli/vela_def_gen-api.md Normal file
View File

@ -0,0 +1,45 @@
---
title: vela def gen-api
---
Generate Go struct of Parameter from X-Definition.
### Synopsis
Generate Go struct of Parameter from definition file.
* Currently, this function is still working in progress and not all formats of parameter in X-definition are supported yet.
```
vela def gen-api DEFINITION.cue [flags]
```
### Examples
```
# Command below will generate the Go struct for the my-def.cue file.
> vela def gen-api my-def.cue
```
### Options
```
-h, --help help for gen-api
--package-name string Specify the package name in generated Go code. (default "main")
--prefix string Specify the prefix of the generated Go struct.
--skip-package-name Skip package name in generated Go code.
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela def](vela_def) - Manage Definitions
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

45
i18n/zh/docusaurus-plugin-content-docs/version-v1.4/cli/vela_def_get.md Normal file
View File

@ -0,0 +1,45 @@
---
title: vela def get
---
Get definition
### Synopsis
Get definition from kubernetes cluster
```
vela def get NAME [flags]
```
### Examples
```
# Command below will get the ComponentDefinition(or other definitions if exists) of webservice in all namespaces
> vela def get webservice
# Command below will get the TraitDefinition of annotations in namespace vela-system
> vela def get annotations --type trait --namespace vela-system
```
### Options
```
-h, --help help for get
-n, --namespace string Specify which namespace to get. If empty, all namespaces will be searched.
-t, --type string Specify which definition type to get. If empty, all types will be searched. Valid types: workflow-step, component, trait, policy, workload, scope
```
### Options inherited from parent commands
```
-y, --yes Assume yes for all user prompts
```
### SEE ALSO
* [vela def](vela_def) - Manage Definitions
#### Go Back to [CLI Commands](vela) Homepage.
###### Auto generated by [spf13/cobra script in KubeVela](https://github.com/kubevela/kubevela/tree/master/hack/docgen).

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