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

Feat: tidy the operator guide and howto documents (#623) 

Signed-off-by: barnettZQG <barnett.zqg@gmail.com>
This commit is contained in:
barnettZQG 2022-04-24 21:08:29 +08:00 committed by GitHub
parent 50f56e8835
commit b39a341fbc
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
69 changed files with 740 additions and 1369 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
docs/case-studies/gitops.md
View File

@ -4,6 +4,8 @@ title: GitOps
This section will introduce how to use KubeVela in GitOps environment and why.
> This section is only apply to CLI.
## Introduction
GitOps is a continuous delivery method that allows developers to automatically deploy applications by changing code and declarative configurations in a Git repository, with Git-centric operations such as PR and commit. For detailed benefits of GitOps, please check [this article](https://www.weave.works/blog/what-is-gitops-really).
@ -19,7 +21,6 @@ KubeVela as an declarative application delivery control plane can be naturally u
- Kustomize-style patch for multi-env deployment without the need to learn Kustomize at all;
- ... and much more.
In this section, we will introduce steps of using KubeVela directly in GitOps approach.
This article will separate into two perspectives:

3
docs/case-studies/multi-cluster.md
View File

@ -15,7 +15,6 @@ There are many scenarios that developers or system operators need to deploy and
The following guide will introduce how to manage applications across clusters on KubeVela.
## Preparation
You can simply join an existing cluster into KubeVela by specifying its KubeConfig as below
@ -534,4 +533,4 @@ No more add-hoc scripts or glue code, KubeVela will get the application delivery
## Next Step
* Refer to more examples about using KubeVela with [GitOps](./gitops).
* Refer to more examples about [integrating with Jenkins](../tutorials/jenkins).

108
docs/end-user/components/cue/raw.md
View File

@ -1,108 +0,0 @@
---
title: Deploy Kubernetes Objects
---
Use raw Kubernetes resources directly.
## How to use
For example, a Job:
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: app-raw
spec:
components:
- name: myjob
type: k8s-objects
properties:
objects:
- apiVersion: batch/v1
kind: Job
metadata:
name: pi
spec:
template:
spec:
containers:
- name: pi
image: perl
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
restartPolicy: Never
backoffLimit: 4
```
More than one resources, you should put your main workload in the first place, vela traits will only affect on the first object:
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: app-stateful-service
spec:
components:
- name: my-sts
type: k8s-objects
properties:
objects:
- apiVersion: apps/v1
kind: StatefulSet
metadata:
name: web
spec:
selector:
matchLabels:
app: nginx # has to match .spec.template.metadata.labels
serviceName: "nginx"
replicas: 3 # by default is 1
template:
metadata:
labels:
app: nginx # has to match .spec.selector.matchLabels
spec:
terminationGracePeriodSeconds: 10
containers:
- name: nginx
image: k8s.gcr.io/nginx-slim:0.8
ports:
- containerPort: 80
name: web
volumeMounts:
- name: www
mountPath: /usr/share/nginx/html
volumeClaimTemplates:
- metadata:
name: www
spec:
accessModes: [ "ReadWriteOnce" ]
storageClassName: "my-storage-class"
resources:
requests:
storage: 1Gi
- apiVersion: v1
kind: Service
metadata:
name: nginx
labels:
app: nginx
spec:
ports:
- port: 80
name: web
clusterIP: None
selector:
app: nginx
```
## Attributes
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
|---------|-------------|-----------------------|----------|---------|
| objects | list objects of Kubernetes resource | [[]K8s-Object](#K8s-Object) | true | |
### K8s-Object
Just write the whole Kubernetes Resource in this property.

9
docs/end-user/components/cue/task.md
View File

@ -2,7 +2,9 @@
title: Deploy Task or Cron Task
---
* Describes jobs that run code or a script to completion
> This type is apply to CLI and UI.
## Describes jobs that run code or a script to completion
```yaml
apiVersion: core.oam.dev/v1beta1
@ -19,8 +21,7 @@ spec:
cmd: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
```
* Describes cron jobs that run code or a script to completion
## Describes cron jobs that run code or a script to completion
```yaml
apiVersion: core.oam.dev/v1beta1
@ -36,4 +37,4 @@ spec:
count: 10
cmd: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
schedule: "*/1 * * * *"
```
```

90
docs/end-user/components/helm.md
View File

@ -1,90 +0,0 @@
---
title: Deploy Helm Charts
---
KubeVela's Helm component meets the needs of users to connect to Helm Chart. You can deploy any ready-made Helm chart software package from Helm Repo, Git Repo or OSS bucket through the Helm component, and overwrite its parameters.
## Deploy From Helm Repo
In this `Application`, we hope to deliver a component called redis-comp. It is a chart from the [bitnami](https://charts.bitnami.com/bitnami).
```shell
cat <<EOF | vela up -f -
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: app-delivering-chart
spec:
components:
- name: redis-comp
type: helm
properties:
chart: redis-cluster
version: 6.2.7
url: https://charts.bitnami.com/bitnami
repoType: helm
EOF
```
Please copy the above code block and deploy it directly to the runtime cluster:
```shell
application.core.oam.dev/app-delivering-chart created
```
Finally, we use `vela ls` to view the application status after successful delivery:
```shell
APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
app-delivering-chart redis-comp helm running healthy 2021-08-28 18:48:21 +0800 CST
```
We also see that the PHASE of the app-delivering-chart APP is running and the STATUS is healthy.
## Deploy From OSS bucket
1. (Optional) If your OSS bucket needs identity verification, create a Secret:
```shell
$ kubectl create secret generic bucket-secret --from-literal=accesskey=<your-ak> --from-literal=secretkey=<your-sk>
secret/bucket-secret created
```
1. Example
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: bucket-app
spec:
components:
- name: bucket-comp
type: helm
properties:
repoType: oss
# required if bucket is private
secretRef: bucket-secret
chart: ./chart/podinfo-5.1.3.tgz
url: oss-cn-beijing.aliyuncs.com
oss:
bucketName: definition-registry
```
## Deploy From Git Repo
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: app-delivering-chart
spec:
components:
- name: terraform-controller
type: helm
properties:
repoType: git
url: https://github.com/oam-dev/terraform-controller
chart: ./chart
git:
branch: master
```

10
docs/end-user/components/kustomize.md
View File

@ -4,6 +4,16 @@ title: Pull based Component
Create a Kustomize Component, it could be from Git Repo or OSS bucket or image registry.
> This type is only apply to CLI.
## Enable the fluxcd addon
This component type is provided by the fluxcd addon, you must enable it firstly.
```shell
vale addon enable fluxcd
```
## Watch Files
### Deploy From OSS bucket

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

@ -2,13 +2,13 @@
title: Needs More Component？
---
## 1. Refer to [All Component References](./references) for all other component types.
* Refer to [All Component References](./references) for all other component types.
## 2. Get more from [install addons](../../how-to/cli/addon/addon).
* Get more from [install addons](../../how-to/cli/addon/addon).
## 3. Extend KubeVela by yourself
* Extend KubeVela by yourself
* Read [how to build definitions](../../platform-engineers/cue/definition-edit) to build your own capability from existing ones.
* [Build your own capability from scratch](../../platform-engineers/cue/advanced)
and learn more features about how to [define custom components](../../platform-engineers/components/custom-component).
* [Build your own addons](../../platform-engineers/addon/intro).
* Read [how to build definitions](../../platform-engineers/cue/definition-edit) to build your own capability from existing ones.
* [Build your own capability from scratch](../../platform-engineers/cue/advanced)
and learn more features about how to [define custom components](../../platform-engineers/components/custom-component).
* [Build your own addons](../../platform-engineers/addon/intro).

2
docs/end-user/components/ref-objects.md
View File

@ -9,6 +9,8 @@ Sometimes, you may want to distribute existing Kubernetes objects. For example,
> This document requires you to know how to deploy multi-cluster application with policy and workflow first. You can refer to [Multi-cluster Application Delivery](../../case-studies/multi-cluster) for details.
> This type is only apply to CLI.
## Refer to Existing Kubernetes Objects in Component
To use existing Kubernetes objects in the component, you need to use the `ref-objects` typed component and declare which resources you want to refer to. For example, in the following example, the secret `image-credential-to-copy` in namespace `examples` will be taken as the source object for the component. Then you can use the topology policy to dispatch it into hangzhou clusters.

1
docs/end-user/debug/health.md
View File

@ -1,5 +1,6 @@
---
title: Aggregated Health Probe
draft: true
---
The `HealthyScope` allows you to define an aggregated health probe for all components in same application.

9
docs/end-user/debug/monitoring.md
View File

@ -1,9 +0,0 @@
---
title: Monitoring
---
TBD, Content Overview：
1. We will move all installation scripts to a separate doc may be named Install Capability Providers (e.g. https://knative.dev/docs/install/install-extensions/)Install monitoring trait(along with prometheus/grafana controller).
2. Add monitoring trait into Application.
3. View it with grafana.

8
docs/end-user/workflow/built-in-workflow-defs.md
View File

@ -4,6 +4,14 @@ title: Built-in Workflow Steps
This documentation will walk through the built-in workflow steps that you can use to design an application deployment process.
## deploy
### Overview
### Parameter
### Example
## apply-application
### Overview

1
docs/getting-started/architecture.md
View File

@ -41,4 +41,3 @@ For learning how to program KubeVela in detail, please check the `Administrator
## Next Step
- View [Getting Started docs](../end-user/quick-start-cli) to look on more of what you can achieve with KubeVela.
- View [How To guides](../end-user/components/helm) to check out more features.

1
docs/getting-started/core-concept.md
View File

@ -38,4 +38,3 @@ Addon is where you can freely pull in third-party capability that fulfills your
- View [Architecture](./architecture) to learn the overall architecture of KubeVela.
- View [Getting Started docs](../end-user/quick-start-cli) to look on more of what you can achieve with KubeVela.
- View [How To guides](../end-user/components/helm) to check out more features.

35
docs/how-to/cli/addon/addon.md → docs/how-to/addon.md
View File

@ -1,10 +1,27 @@
---
title: Install Addon
title: Addon management
slug: how-to/cli/addon/addon
---
You can get more capabilities from KubeVela ecosystem by installing addons.
## List Addons
## Manage the addon via UI
Users with addon management permissions can enter the addon management page to enable or disable addons.
![addon list](https://static.kubevela.net/images/1.3/addon-list.jpg)
In the addon list, you can get the status of the addon and other info. Click the addon name could open the addon detail page, you can get the version list, definitions provided by the addon, and the readme message.
![addon detail](https://static.kubevela.net/images/1.3/addon-detail.jpg)
Select a version and deployed clusters, you can click the enable button to install this addon.
For enabled addons, if no applications to use definitions, you can click the disable button to uninstall it.
## Manage the addon via CLI
### List Addons
By default, the following command lists addons from a default addon registry (https://addons.kubevela.net) maintained by KubeVela team.
@ -31,7 +48,7 @@ velaux KubeVela KubeVela User Experience (UX). A
terraform-alibaba KubeVela Kubernetes Terraform Controller for Alibaba Cloud [1.0.2, 1.0.1] disabled
```
## Install Addon
### Install Addon
```
$ vela addon enable fluxcd
@ -45,7 +62,7 @@ I0111 21:45:25.660129 89345 apply.go:106] "creating object" name="component-ui
Addon: fluxcd enabled Successfully.
```
### Install with specified version
#### Install with specified version
You can choose one special version of this addon by add `--version` flag in this command. eg:
@ -61,7 +78,7 @@ vela addon enable <addon-name> --clusters={cluster1,cluster2}
You can view the new component or trait types added by `vela component` or `vela trait`. You can also find more details about [built-in addon docs](../../../reference/addons/overview).
## Uninstall Addon
### Uninstall Addon
> Please make sure this addon along with the capabilities is no longer used in any of your applications.
@ -70,7 +87,7 @@ $ vela addon disable fluxcd
Successfully disable addon:fluxcd
```
## List Registry
### List Registry
```
$ vela addon registry list
@ -78,21 +95,21 @@ Name Type URL
KubeVela helm https://addons.kubevela.net
```
## Add Registry
### Add Registry
```
$ vela addon registry add experimental --type=helm --endpoint=https://addons.kubevela.net/experimental/
Successfully add an addon registry experimental
```
## Delete Registry
### Delete Registry
```
$ vela addon registry delete experimental
Successfully delete an addon registry experimental
```
## Enable Addon offline
### Enable Addon offline
For some reason, if your cluster network cannot request the official addon registry you can enable an addon with a local dir. eg:

3
docs/how-to/dashboard/addon/overview.md
View File

@ -1,3 +0,0 @@
---
title: Overview
---

1
docs/how-to/dashboard/application/get-application-revision.md
View File

@ -13,4 +13,5 @@ Manually upgrade or triggered by webhooks will all list here.
### Next Step
* [Version control via CLI](../../../end-user/version-control)
* [Recycle Application Instance](./recycle-environment)

5
docs/how-to/dashboard/cluster/connect-cluster.md
View File

@ -1,5 +0,0 @@
---
title: Connect a kubernetes cluster
---
We support connect and detach the kubernetes cluster.

5
docs/how-to/dashboard/cluster/detach-cluster.md
View File

@ -1,5 +0,0 @@
---
title: Detach a kubernetes cluster
---
We support connect and detach the kubernetes cluster.

5
docs/how-to/dashboard/cluster/edit-cluster.md
View File

@ -1,5 +0,0 @@
---
title: Edit metadata of kubernetes cluster
---
We support connect and detach the kubernetes cluster.

3
docs/how-to/dashboard/cluster/overview.md
View File

@ -1,3 +0,0 @@
---
title: Overview
---

5
docs/how-to/dashboard/cluster/set-cluster-dashboard.md
View File

@ -1,5 +0,0 @@
---
title: Set cluster dashboard
---
We support connect and detach the kubernetes cluster.

5
docs/how-to/dashboard/trait/overview.md
View File

@ -1,6 +1,7 @@
---
title: Manage Traits
description: Manage traits for application
draft: true
---
After deploying an application, VelaUX will automatically bind a `scaler` trait to the application. You can update, delete or bind other traits in the dashboard.
@ -25,9 +26,7 @@ Click the gear icon to enter the edit page of the trait. You can set the number
## Delete traits
Click the trash icon to delete the trait.
![delete-trait](../../../resources/delete-trait.png)
Open the component configuration page, and click the trash icon of the trait to delete.
## More

1
docs/how-to/dashboard/workflow/overview.md
View File

@ -1,6 +1,7 @@
---
title: Manage Workflows
description: Manager workflows for application
draft: true
---
When an application is created, it is associated with an environment. Each environment is associated with a workflow for deployment. After a workflow is created, there is only one step by default. You can enter workflow editing mode by clicking the `Edit` button.

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

@ -1,5 +1,5 @@
---
title: Custom Installation
title: Custom installation and upgrade
---
import Tabs from "@theme/Tabs";

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

@ -1,5 +1,6 @@
---
title: Extend CRD Operator as Component Type
draft: true
---
Let's use [OpenKruise](https://github.com/openkruise/kruise) as example of extend CRD as KubeVela Component.

1
docs/platform-engineers/cloud-services.md
View File

@ -1,5 +1,6 @@
---
title: Overview
draft: true
---
Cloud services are important components of your application, and KubeVela allows you to provision and consume them in a consistent experience.

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

@ -1,5 +1,6 @@
---
title: Crossplane
draft: true
---
In this documentation, we will use Alibaba Cloud's RDS (Relational Database Service), and Alibaba Cloud's OSS (Object Storage System) as examples to show how to enable cloud services as part of the application deployment.

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

@ -1,90 +0,0 @@
---
title: How-to
---
> ⚠️ This usage has been deprecated in version 1.2.x. Please refer to [doc](../../end-user/components/helm) for more info to use helm type component.
In this section, it will introduce how to declare Helm charts as components via `ComponentDefinition`.
> Before reading this part, please make sure you've learned [the definition and template concepts](../definition-and-templates).
## Prerequisite
* Make sure you have enabled Helm support in the [installation guide](../../install#4-enable-helm-support).
## Declare `ComponentDefinition`
Here is an example `ComponentDefinition` about how to use Helm as schematic module.
```yaml
apiVersion: core.oam.dev/v1beta1
kind: ComponentDefinition
metadata:
name: webapp-chart
annotations:
definition.oam.dev/description: helm chart for webapp
spec:
workload:
definition:
apiVersion: apps/v1
kind: Deployment
schematic:
helm:
release:
chart:
spec:
chart: "podinfo"
version: "5.1.4"
repository:
url: "http://oam.dev/catalog/"
```
In detail:
- `.spec.workload` is required to indicate the workload type of this Helm based component. Please also check for [known limitations](known-issues?id=workload-type-indicator) if you have multiple workloads packaged in one chart.
- `.spec.schematic.helm` contains information of Helm `release` and `repository` which leverages `fluxcd/flux2`.
- i.e. the spec of `release` aligns with [`HelmReleaseSpec`](https://github.com/fluxcd/helm-controller/blob/main/docs/api/helmrelease.md) and spec of `repository` aligns with [`HelmRepositorySpec`](https://github.com/fluxcd/source-controller/blob/main/docs/api/source.md#source.toolkit.fluxcd.io/v1beta1.HelmRepository).
## Declare an `Application`
Here is an example `Application`.
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: myapp
namespace: default
spec:
components:
- name: demo-podinfo
type: webapp-chart
properties:
image:
tag: "5.1.2"
```
The component `properties` is exactly the [overlay values](https://github.com/captainroy-hy/podinfo/blob/master/charts/podinfo/values.yaml) of the Helm chart.
Deploy the application and after several minutes (it may take time to fetch Helm chart), you can check the Helm release is installed.
```shell
helm ls -A
```
```console
myapp-demo-podinfo default 1 2021-03-05 02:02:18.692317102 +0000 UTC deployed podinfo-5.1.4 5.1.4
```
Check the workload defined in the chart has been created successfully.
```shell
kubectl get deploy
```
```console
NAME READY UP-TO-DATE AVAILABLE AGE
myapp-demo-podinfo 1/1 1 1 66m
```
Check the values (`image.tag = 5.1.2`) from application's `properties` are assigned to the chart.
```shell
kubectl get deployment myapp-demo-podinfo -o json | jq '.spec.template.spec.containers[0].image'
```
```console
"ghcr.io/stefanprodan/podinfo:5.1.2"
```

82
docs/platform-engineers/helm/known-issues.md
View File

@ -1,82 +0,0 @@
---
title: Known Limitations
---
## Limitations
Here are some known limitations for using Helm chart as application component.
### Workload Type Indicator
Following best practices of microservice, KubeVela recommends only one workload resource present in one Helm chart. Please split your "super" Helm chart into multiple charts (i.e. components). Essentially, KubeVela relies on the `workload` filed in component definition to indicate the workload type it needs to take care, for example:
```yaml
apiVersion: core.oam.dev/v1beta1
kind: ComponentDefinition
...
spec:
workload:
definition:
apiVersion: apps/v1
kind: Deployment
```
```yaml
...
spec:
workload:
definition:
apiVersion: apps.kruise.io/v1alpha1
kind: Cloneset
```
Note that KubeVela won't fail if multiple workload types are packaged in one chart, the issue is for further operational behaviors such as rollout, revisions, and traffic management, they can only take effect on the indicated workload type.
### Always Use Full Qualified Name
The name of the workload should be templated with [fully qualified application name](https://github.com/helm/helm/blob/543364fba59b0c7c30e38ebe0f73680db895abb6/pkg/chartutil/create.go#L415) and please do NOT assign any value to `.Values.fullnameOverride`. As a best practice, Helm also highly recommend that new charts should be created via `$ helm create` command so the template names are automatically defined as per this best practice.
### Control the Application Upgrade
Changes made to the component `properties` will trigger a Helm release upgrade. This process is handled by Flux v2 Helm controller, hence you can define remediation
strategies in the schematic based on [Helm Release
documentation](https://github.com/fluxcd/helm-controller/blob/main/docs/api/helmrelease.md#upgraderemediation)
and [specification](https://toolkit.fluxcd.io/components/helm/helmreleases/#configuring-failure-remediation)
in case failure happens during this upgrade.
For example:
```yaml
apiVersion: core.oam.dev/v1beta1
kind: ComponentDefinition
metadata:
name: webapp-chart
spec:
...
schematic:
helm:
release:
chart:
spec:
chart: "podinfo"
version: "5.1.4"
upgrade:
remediation:
retries: 3
remediationStrategy: rollback
repository:
url: "http://oam.dev/catalog/"
```
Though one issue is for now it's hard to get helpful information of a living Helm release to figure out what happened if upgrading failed. We will enhance the observability to help users track the situation of Helm release in application level.
## Issues
The known issues will be fixed in following releases.
### Rollout Strategy
For now, Helm based components cannot benefit from [rolling update API](https://github.com/oam-dev/kubevela/blob/master/design/vela-core/rollout-design.md#applicationdeployment-workflow). As shown in [this sample](./trait#update-an-applicatiion), if the application is updated, it can only be rollouted directly without canary or blue-green approach.
### Updating Traits Properties may Also Lead to Pods Restart
Changes on traits properties may impact the component instance and Pods belonging to this workload instance will restart. In CUE based components this is avoidable as KubeVela has full control on the rendering process of the resources, though in Helm based components it's currently deferred to Flux v2 controller.

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

@ -1,169 +0,0 @@
---
title: Attach Traits
---
Traits in KubeVela can be attached to Helm based component seamlessly.
In this sample application below, we add two traits, [scaler](https://github.com/oam-dev/kubevela/blob/master/charts/vela-core/templates/defwithtemplate/scaler.yaml)
and [virtualgroup](https://github.com/oam-dev/kubevela/blob/master/docs/examples/helm-module/virtual-group-td.yaml) to a Helm based component.
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: myapp
namespace: default
spec:
components:
- name: demo-podinfo
type: webapp-chart
properties:
image:
tag: "5.1.2"
traits:
- type: scaler
properties:
replicas: 4
- type: virtualgroup
properties:
group: "my-group1"
type: "cluster"
```
> Note: when use traits with Helm based component, please *make sure the target workload in your Helm chart strictly follows the qualified-full-name convention in Helm.* [For example in this chart](https://github.com/captainroy-hy/podinfo/blob/c2b9603036f1f033ec2534ca0edee8eff8f5b335/charts/podinfo/templates/deployment.yaml#L4), the workload name is composed of [release name and chart name](https://github.com/captainroy-hy/podinfo/blob/c2b9603036f1f033ec2534ca0edee8eff8f5b335/charts/podinfo/templates/_helpers.tpl#L13).
> This is because KubeVela relies on the name to discovery the workload, otherwise it cannot apply traits to the workload. KubeVela will generate a release name based on your `Application` name and component name automatically, so you need to make sure never override the full name template in your Helm chart.
## Verify traits work correctly
> You may need to wait a few seconds to check the trait attached because of reconciliation interval.
Check the `scaler` trait takes effect.
```shell
kubectl get manualscalertrait
```
```console
NAME AGE
demo-podinfo-scaler-d8f78c6fc 13m
```
```shell
kubectl get deployment myapp-demo-podinfo -o json | jq .spec.replicas
```
```console
4
```
Check the `virtualgroup` trait.
```shell
kubectl get deployment myapp-demo-podinfo -o json | jq .spec.template.metadata.labels
```
```console
{
"app.cluster.virtual.group": "my-group1",
"app.kubernetes.io/name": "myapp-demo-podinfo"
}
```
## Update Application
After the application is deployed and workloads/traits are created successfully,
you can update the application, and corresponding changes will be applied to the
workload instances.
Let's make several changes on the configuration of the sample application.
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: myapp
namespace: default
spec:
components:
- name: demo-podinfo
type: webapp-chart
properties:
image:
tag: "5.1.3" # 5.1.2 => 5.1.3
traits:
- type: scaler
properties:
replicas: 2 # 4 => 2
- type: virtualgroup
properties:
group: "my-group2" # my-group1 => my-group2
type: "cluster"
```
Apply the new configuration and check the results after several minutes.
Check the new values (`image.tag = 5.1.3`) from application's `properties` are assigned to the chart.
```shell
kubectl get deployment myapp-demo-podinfo -o json | jq '.spec.template.spec.containers[0].image'
```
```console
"ghcr.io/stefanprodan/podinfo:5.1.3"
```
Under the hood, Helm makes an upgrade to the release (revision 1 => 2).
```shell
helm ls -A
```
```console
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
myapp-demo-podinfo default 2 2021-03-15 08:52:00.037690148 +0000 UTC deployed podinfo-5.1.4 5.1.4
```
Check the `scaler` trait.
```shell
kubectl get deployment myapp-demo-podinfo -o json | jq .spec.replicas
```
```console
2
```
Check the `virtualgroup` trait.
```shell
kubectl get deployment myapp-demo-podinfo -o json | jq .spec.template.metadata.labels
```
```console
{
"app.cluster.virtual.group": "my-group2",
"app.kubernetes.io/name": "myapp-demo-podinfo"
}
```
## Detach Trait
Let's have a try detach a trait from the application.
```yaml
apiVersion: core.oam.dev/v1alpha2
kind: Application
metadata:
name: myapp
namespace: default
spec:
components:
- name: demo-podinfo
type: webapp-chart
settings:
image:
tag: "5.1.3"
traits:
# - name: scaler
# properties:
# replicas: 2
- name: virtualgroup
properties:
group: "my-group2"
type: "cluster"
```
Apply the application and check `manualscalertrait` has been deleted.
```shell
kubectl get manualscalertrait
```
```console
No resources found
```

3
docs/platform-engineers/initializer-platform-eng.md
View File

@ -1,3 +0,0 @@
---
title: 平台环境初始化
---

20
docs/platform-engineers/system-operation/managing-clusters.md
View File

@ -2,7 +2,18 @@
title: Managing Clusters
---
Users could manage clusters in KubeVela through a list of Vela CLI commands.
## Manage the cluster via UI
* Support connecting the exist kubernetes cluster.
* Support connecting the ACK cluster.
Users with cluster management permissions can enter the cluster management page to add or detach managed clusters.
![cluster-management](https://static.kubevela.net/images/1.3/cluster-management.jpg)
For connecting the ACK clusters, the platform will save some cloud info, Region, VPC, Dashboard Address, etc. When users use the cluster to create a Target, the cloud information is automatically assigned to the Target, which the cloud service applications can use.
## Manage the cluster via CLI
### vela cluster list
@ -10,8 +21,9 @@ This command could list all clusters managed by KubeVela currently.
```bash
$ vela cluster list
CLUSTER TYPE ENDPOINT
cluster-prod tls https://47.88.4.97:6443
cluster-staging tls https://47.88.7.230:6443
CLUSTER ALIAS TYPE ENDPOINT ACCEPTED LABELS
local Internal - true
ask-beijing X509Certificate https://*.*.*.*:6443 true
```
### vela cluster join
@ -36,4 +48,4 @@ This command can rename cluster managed by KubeVela.
```shell script
$ vela cluster rename cluster-prod cluster-production
```
```

4
docs/platform-engineers/system-operation/offline-installation.md
View File

@ -1,4 +1,6 @@
# Air-gapped Installation
---
title: Air-gapped Installation
---
Air-gapped Installation of KubeVela includes the installation of KubeVela core and addons, they all contain the configuration files and images.

10
docs/quick-start.md
View File

@ -26,22 +26,14 @@ spec:
ports:
- port: 8000
expose: true
traits:
- type: gateway
properties:
domain: testsvc.example.com
http:
"/": 8000
# YAML ends
EOF
```
This command will deploy a web service component to target environment, which in our case is the Kubernetes cluster that KubeVela itself is installed.
After deployed, you can now directly visit this application as it already attached with a `ingress` trait (assume your cluster has [ingress controller](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/) installed).
```
$ curl -H "Host:testsvc.example.com" http://<some ip address>/
$ vela port-forward first-vela-app 8000:8000
<xmp>
Hello World

20
docs/tutorials/helm.md
View File

@ -56,19 +56,15 @@ After filling in the above parameters, click `Create` to complete the applicatio
## Modify deployment parameters
Here we're unlocking new skills! Modify the parameters of the application. For any type of application, he can enter the application configuration page at any time by clicking the component name. It is automatically generated by combining the parameters defined by the Definition of each application type and the KubeVela UISchema specification.
Clicking the component name, you can open the component configuration page. For the Helm Chart component, we can set the Values configuration options to change the application deployment parameters. the Values configuration options are generated by `values.yaml`, you can set the custom value for every option.
After modifying the deployment parameters, the workflow of the environment must be executed to make the modified parameters take effect in the specified environment. Due to the existence of Revision, the configuration parameters will be saved in each historical version.
At this point, Helm Chart in KubeVela is no stranger to you, go ahead and try more!
## Deploy via CLI
You can also create the application with helm component via CLI:
```shell
cat <<EOF | vela up -f -
# YAML begins
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
@ -85,14 +81,16 @@ spec:
values:
master.persistence.size: 16Gi
replica.persistence.size: 16Gi
# YAML ends
EOF
```
Deploy this application：
```shell
vela up -f https://kubevela.io/example/applications/app-with-chart-redis.yaml
```
> Currently, The application created by CLI will be synced to UI, but it will be readonly.
You can also save the YAML file as helm-redis.yaml and use the `vela up -f helm-redis.yaml` command to deploy.
Next, check the deployment status of the application through `vela status helm-redis`
```
@ -125,6 +123,8 @@ Services:
No trait applied
```
At this point, Helm Chart in KubeVela is no stranger to you, go ahead and try more!
## Next step
- [Deploy Kubernetes Objects](./k8s-object)

2
docs/tutorials/jenkins.md
View File

@ -13,7 +13,7 @@ In this section, we will demonstrate how to integrate KubeVela with Jenkins in d
### Prerequisite
The following requirements are needed to be ensured before starting this tutorial
- KubeVela v1.2.0 with VelaUX installed.
- KubeVela v1.2.0+ with VelaUX installed.
- Jenkins installed.
- VelaUX can be accessed by Jenkins. (If KubeVela is installed in an offline environment, you need to check this condition.)

109
docs/tutorials/k8s-object.mdx
View File

@ -85,12 +85,113 @@ If continued, the deployment goes on. In the list of instances, you can check ou
![](../resources/multiple-target-pods.jpg)
Congrats! Now you've learned how to deploy Kubernetes objects.
## Deploy kubernetes objects via CLI.
<!-- ## Video tutorial TODO v1.2 -->
This is a demo application with a kubernetes objects, the most kubernetes app are consists of Deployment and Service.
There are two policies and three workflow steps, this means deploying the app to two namespaces and waiting for human review after the first step is successful.
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: app-with-k8s-objects
namespace: default
spec:
components:
- name: k8s-demo-service
properties:
objects:
- apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
spec:
replicas: 2
selector:
matchLabels:
app: nginx
strategy:
type: Recreate
template:
metadata:
labels:
app: nginx
spec:
containers:
- image: nginx
name: nginx
ports:
- containerPort: 80
- apiVersion: v1
kind: Service
metadata:
annotations:
service.beta.kubernetes.io/aws-load-balancer-type: nlb
labels:
app: nginx
name: nginx
namespace: default
spec:
externalTrafficPolicy: Local
ports:
- name: http
port: 80
protocol: TCP
targetPort: 80
selector:
app: nginx
type: LoadBalancer
type: k8s-objects
policies:
- name: topology-default
type: topology
properties:
clusters: ["local"]
namespace: default
- name: topology-production
type: topology
properties:
clusters: ["local"]
namespace: production
workflow:
steps:
- name: deploy2default
properties:
policies: ["topology-default"]
type: deploy
- name: suspend
type: suspend
- name: deploy2production
properties:
policies: ["topology-production"]
type: deploy
```
- About the topology policy, refence: [Topology](../end-user/policies/references#override)
- About the deploy workflow step, refence: [Deploy](../end-user/workflow/built-in-workflow-defs#deploy)
Deploy this application by the following command:
- create the namespace with the name `production` before deploying the application.
```shell
$ vela up -f https://kubevela.io/example/applications/create-namespace.yaml
```
- deploy the demo application.
```shell
$ vela up -f https://kubevela.io/example/applications/app-with-k8s-objects.yaml
```
- review and resume the workflow after the workflow becomes suspended.
```shell
$ vela workflow resume app-with-k8s-objects
```
Congrats! Now you've learned how to deploy Kubernetes objects.
## Next step
<!-- 1. [Getting into more of Workflow](./multi-cluster) TODO v1.2 -->
- [Deploy Helm Chart](./helm)

22
i18n/zh/docusaurus-plugin-content-docs/current.json
View File

@ -187,8 +187,8 @@
"message": "操作手册",
"description": "CLI 和 Dashboard 的操作指导手册"
},
"sidebar.docs.category.Manage applications": {
"message": "应用管理",
"sidebar.docs.category.Deploy applications": {
"message": "交付应用",
"description": "通过 Dashboard 对应用的管理操作说明"
},
"sidebar.docs.category.Manage traits": {
@ -255,16 +255,16 @@
"message": "基础内容",
"description": "Basic information"
},
"sidebar.docs.category.Deploy Components": {
"message": "部署组件",
"description": "Deploy Components description"
"sidebar.docs.category.Deploy with more workload type": {
"message": "更多组件类型",
"description": "非常用的组件类型"
},
"sidebar.docs.category.VelaUX": {
"message": "可视化交付平台（VelaUX）",
"description": "VelaUX description"
"sidebar.docs.category.User Guide": {
"message": "用户手册",
"description": "引导用户学习使用 KubeVela 各项特性"
},
"sidebar.docs.category.Vela-Core": {
"message": "核心引擎（Vela-Core）",
"description": "Vela-Core description"
"sidebar.docs.category.Install or upgrade": {
"message": "平台安装或升级手册",
"description": "详细解读平台的各种部署方式"
}
}

2
i18n/zh/docusaurus-plugin-content-docs/current/case-studies/gitops.md
View File

@ -4,6 +4,8 @@ title: GitOps 交付
本案例将介绍如何在 GitOps 场景下使用 KubeVela，并介绍这样做的好处是什么。
> 该教程仅适用于 CLI 用户。
## 简介
GitOps 是一种现代化的持续交付手段，它允许开发人员通过直接更改 Git 仓库中的代码和配置来自动部署应用，在提高部署生产力的同时也通过分支回滚等能力提高了可靠性。其具体的好处可以查看[这篇文章](https://www.weave.works/blog/what-is-gitops-really)，本文将不再赘述。

1
i18n/zh/docusaurus-plugin-content-docs/current/case-studies/jenkins-cicd.md
View File

@ -1,5 +1,6 @@
---
title: Jenkins CI 集成
draft: true
---
本文将介绍如何使用 KubeVela 同已有的 CI 工具（比如 Jenkins）共同协作来进行应用的持续交付，并解释这样集成的好处是什么。

99
i18n/zh/docusaurus-plugin-content-docs/current/end-user/components/cue/raw.md
View File

@ -1,99 +0,0 @@
---
title: 部署 Kubernetes 资源模板
---
KubeVela 可以以资源模板的方式直接部署任何 Kubernetes 对象。
## 如何使用
比如一个 Job。
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: app-raw
spec:
components:
- name: myjob
type: k8s-objects
properties:
objects:
- apiVersion: batch/v1
kind: Job
metadata:
name: pi
spec:
template:
spec:
containers:
- name: pi
image: perl
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
restartPolicy: Never
backoffLimit: 4
```
也支持多个资源，但是要把你的主要工作负载放在第一个，KubeVela 的 traits 只会对第一个位置的 Kubernetes 对象生效。
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: app-stateful-service
spec:
components:
- name: my-sts
type: k8s-objects
properties:
objects:
- apiVersion: apps/v1
kind: StatefulSet
metadata:
name: web
spec:
selector:
matchLabels:
app: nginx # has to match .spec.template.metadata.labels
serviceName: "nginx"
replicas: 3 # by default is 1
template:
metadata:
labels:
app: nginx # has to match .spec.selector.matchLabels
spec:
terminationGracePeriodSeconds: 10
containers:
- name: nginx
image: k8s.gcr.io/nginx-slim:0.8
ports:
- containerPort: 80
name: web
volumeMounts:
- name: www
mountPath: /usr/share/nginx/html
volumeClaimTemplates:
- metadata:
name: www
spec:
accessModes: [ "ReadWriteOnce" ]
storageClassName: "my-storage-class"
resources:
requests:
storage: 1Gi
- apiVersion: v1
kind: Service
metadata:
name: nginx
labels:
app: nginx
spec:
ports:
- port: 80
name: web
clusterIP: None
selector:
app: nginx
```

8
i18n/zh/docusaurus-plugin-content-docs/current/end-user/components/cue/task.md
View File

@ -1,9 +1,10 @@
---
title: 一次性任务
title: 部署一次性或周期性任务
---
* 一次性任务（Task）描述运行代码或脚本以完成的作业。
> 此类型适用于 UI 和 CLI
### 一次性任务（Task）描述运行代码或脚本以完成的作业
```yaml
apiVersion: core.oam.dev/v1beta1
@ -20,8 +21,7 @@ spec:
cmd: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
```
* 描述一个定时任务
### 描述一个定时任务
```yaml
apiVersion: core.oam.dev/v1beta1

92
i18n/zh/docusaurus-plugin-content-docs/current/end-user/components/helm.md
View File

@ -1,92 +0,0 @@
---
title: 部署 Helm 组件
---
KubeVela 的 `helm` 组件满足了用户对接 Helm Chart 的需求，你可以通过 `helm` 组件部署任意来自 Helm 仓库、Git 仓库或者 OSS bucket 的现成 Helm Chart 软件包，并对其进行参数覆盖。
## 部署来自 Helm 仓库的 Chart
来自 Helm 仓库的 Chart 包部署方式，我们以一个 redis-comp 组件为例。它是来自 [bitnami](https://charts.bitnami.com/) Helm 仓库的 Chart。Chart 类型为 `redis-cluster`，版本 `6.2.7`。
```shell
cat <<EOF | vela up -f -
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: app-delivering-chart
spec:
components:
- name: redis-comp
type: helm
properties:
chart: redis-cluster
version: 6.2.7
url: https://charts.bitnami.com/bitnami
repoType: helm
EOF
```
请复制上面的代码块，直接部署到运行时集群：
```shell
application.core.oam.dev/app-delivering-chart created
```
最后我们使用 `vela ls` 来查看交付成功后的应用状态：
```shell
APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
app-delivering-chart redis-comp helm running healthy 2021-08-28 18:48:21 +0800 CST
```
我们也看到 app-delivering-chart APP 的 PHASE 为 running，同时 STATUS 为 healthy。
## 部署来自 OSS bucket 的 Chart
1. （可选）如果你的 OSS bucket 需要身份验证, 创建 Secret 对象:
```shell
$ kubectl create secret generic bucket-secret --from-literal=accesskey=<your-ak> --from-literal=secretkey=<your-sk>
secret/bucket-secret created
```
2. 部署 chart
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: bucket-app
spec:
components:
- name: bucket-comp
type: helm
properties:
repoType: oss
# required if bucket is private
secretRef: bucket-secret
chart: ./chart/podinfo-5.1.3.tgz
url: oss-cn-beijing.aliyuncs.com
oss:
bucketName: definition-registry
```
上面的示例中，Application 中名为 bucket-comp 的组件交付了一个来自 endpoint 为 oss-cn-beijing.aliyuncs.com 的 OSS bucket definition-registry 的 chart。Chart 路径为 ./chart/podinfo-5.1.3.tgz。
## 部署来自 Git 仓库的 Chart
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: app-delivering-chart
spec:
components:
- name: terraform-controller
type: helm
properties:
repoType: git
url: https://github.com/oam-dev/terraform-controller
chart: ./chart
git:
branch: master
```
上面的示例中，Application 中名为 terraform-controller 的组件交付了一个来自 https://github.com/oam-dev/terraform-controller 的 Github 仓库的 chart。Chart 路径为 ./chart，仓库分支为 master。

2
i18n/zh/docusaurus-plugin-content-docs/current/end-user/components/kustomize.md
View File

@ -6,6 +6,8 @@ KubeVela 的 [`kustomize` 组件](https://github.com/kubernetes-sigs/kustomize)
除了监听文件外，该组件还能监听镜像仓库中的镜像变动并交付。
> 该类型仅适用于 CLI
## 监听文件/文件夹
### 监听 OSS bucket 中的文件

14
i18n/zh/docusaurus-plugin-content-docs/current/end-user/components/more.md
View File

@ -2,13 +2,13 @@
title: 获得更多组件类型？
---
## 1. 查看 [所有组件参考列表](./references)。
* 查看 [所有组件参考列表](./references)。
## 2. 从[插件安装](../../how-to/cli/addon/addon)中获得。
* 从[插件安装](../../how-to/cli/addon/addon)中获得。
## 3. 自己动手扩展
* 自己动手扩展
* 阅读[如何通过已经存在的 Definition 修改从而自定义组件类型](../../platform-engineers/cue/definition-edit)。
* [构建自己的能力](../../platform-engineers/cue/advanced)
学习[从零开始构建组件](../../platform-engineers/components/custom-component)。
* [构建自己的插件](../../platform-engineers/addon/intro)。
* 阅读[如何通过已经存在的 Definition 修改从而自定义组件类型](../../platform-engineers/cue/definition-edit)。
* [构建自己的能力](../../platform-engineers/cue/advanced)
学习[从零开始构建组件](../../platform-engineers/components/custom-component)。
* [构建自己的插件](../../platform-engineers/addon/intro)。

1
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/architecture.md
View File

@ -40,4 +40,3 @@ KubeVela 本身是一个的应用交付与管理控制平面，它架在 Kuberne
## 下一步
- 查看 [快速开始](../end-user/quick-start-cli)，了解更多使用场景和最佳实践。
- 查看 [操作手册](../end-user/components/helm)，一步步了解更多的功能。

3
i18n/zh/docusaurus-plugin-content-docs/current/getting-started/core-concept.md
View File

@ -38,5 +38,4 @@ Kubernetes 集群描述，它包括了集群通信密钥等信息，Kubernetes
## 下一步
- 查看 [架构文档](./architecture)，了解 KubeVela 的整体架构。
- 查看 [快速开始](../end-user/quick-start-cli)，了解更多使用场景和最佳实践。
- 查看 [操作手册](../end-user/components/helm) 以便了解更多功能。
- 查看 [快速开始](../end-user/quick-start-cli)，了解更多使用场景和最佳实践。

34
i18n/zh/docusaurus-plugin-content-docs/current/how-to/cli/addon/addon.md → i18n/zh/docusaurus-plugin-content-docs/current/how-to/addon.md
View File

@ -1,10 +1,24 @@
---
title: 安装插件
title: 插件管理
---
你可以通过安装 KubeVela 的插件（Addon）获取更多的系统功能。
## 查看所有插件
## 通过 UI 管理插件
具有插件管理权限的用户可以进入插件管理页面，进行插件启用/停用等操作。
![addon list](https://static.kubevela.net/images/1.3/addon-list.jpg)
如上图所示，在插件列表中，你可以查看到插件启用状态和其他基础信息。点击插件名称可以进入到插件详情页面，你可以查询到插件的版本列表，提供的扩展类型和介绍信息。
![addon detail](https://static.kubevela.net/images/1.3/addon-detail.jpg)
选择一个部署版本（默认为最新），设置需要部署的集群后，你可以点击 启用 按钮安装该插件。对于已启用的插件，如果没有应用使用该插件提供的扩展，你可以点击禁用按钮来卸载它。
## 通过 CLI 管理插件
### 查看所有插件
KubeVela 官方团队维护了一个默认的插件仓库 (https://addons.kubevela.net) ，默认情况下会从这个仓库实时发现。
@ -30,7 +44,7 @@ velaux KubeVela KubeVela User Experience (UX). A
terraform-alibaba KubeVela Kubernetes Terraform Controller for Alibaba Cloud [1.0.2, 1.0.1] disabled
```
## 安装插件
### 安装插件
```
$ vela addon enable fluxcd
@ -44,7 +58,7 @@ I0111 21:45:25.660129 89345 apply.go:106] "creating object" name="component-ui
Addon: fluxcd enabled Successfully.
```
### 安装特定版本的插件
#### 安装特定版本的插件
你可以通过通过设置 `--version` 启动参数，来指定安装插件的某个特定版本。例如：
@ -63,7 +77,7 @@ vela addon enable <addon-name> --clusters={cluster1,cluster2}
安装完成后，插件中的功能会以组件，运维特征，工作流步骤等形式呈现，你可以通过 `vela component`，`vela trait` 等命令查看新增的能力，也可以在[插件的参考文档](../../../reference/addons/overview)中查看每个官方插件对应的能力.
## 删除/卸载已安装的插件
### 删除/卸载已安装的插件
> 删除前请确认插件对应的能力没有被任何应用使用。
@ -72,7 +86,7 @@ $ vela addon disable fluxcd
Successfully disable addon:fluxcd
```
## 查看插件的下载仓库
### 查看插件的下载仓库
```
$ vela addon registry list
@ -84,7 +98,7 @@ KubeVela 社区在 Github 上维护了一个官方的[正式插件包仓库](htt
同时这些文件会被同步到 [对象存储](https://addons.kubevela.net) 当中，以加快下载速度。
## 添加插件包仓库
### 添加插件包仓库
你可以添加自己的插件包仓库，目前支持 OSS 和 Github 两种仓库类型。
@ -93,14 +107,14 @@ $ vela addon registry add experimental --type OSS --endpoint=https://addons.kube
Successfully add an addon registry experimental
```
## 删除一个插件包仓库
### 删除一个插件包仓库
```
$ vela addon registry delete experimental
Successfully delete an addon registry experimental
```
## 多集群环境中启用插件包
### 多集群环境中启用插件包
如果你的环境中添加了若干个子集群，启用插件包时会默认在管控集群和所有子集群中安装此插件包。但如果子集群在某个插件包启用之后加入环境当中，则需要通过升级操作在新加入集群中安装此插件包。如下所示
@ -110,7 +124,7 @@ Addon:
enabled Successfully
```
## 离线安装插件包
### 离线安装插件包
如果因为某些原因，你的环境无法通过访问插件包仓库，你可以通过指定本地的插件包目录来进行离线安装。如下所示：

43
i18n/zh/docusaurus-plugin-content-docs/current/how-to/dashboard/addon/overview.md
View File

@ -1,43 +0,0 @@
---
title: 管理插件
---
你可以在 VelaUX 的 Addon 页面管理平台插件，以获取更多的系统功能。
![alt](../../../resources/addon-list.jpg)
## 启用/停用插件 (Enable/Disable Addon)
如下图所示，在某个插件页面点击 `Enable` 启用一个插件
![alt](../../../resources/addon.jpg)
如果某个插件需要依赖其他插件，只有当被依赖的的插件被启用之后，该插件才能被启用，如下图所示。
![alt](../../../resources/addon-dependency.jpg)
有些复杂的插件需要设置一些参数才能启用，如下图所示。
![alt](../../../resources/addon-parameter.jpg)
通过点击插件页面的 `Disable` 停用一个插件
> 停用前请确认插件对应的能力没有被任何应用所使用。
你也可以通过点击页面的 `Upgrade` 来更新插件。
## 多集群环境中启用插件
如果插件的部署目标设置为子集群部署，在启用插件时首先需要选择你希望启用的集群。如果插件启用完成后又新增了集群，你需要增加选择新的集群然后更新插件即可。
## 插件仓库 (Addon Registry)
插件仓库是一个存储、发现和下载插件的地方。 插件仓库的地址可以是一个 Git 仓库或者一个对象存储 Bucket。
KubeVela 社区在 Github 上维护了一个官方的[正式插件仓库](https://github.com/oam-dev/catalog/tree/master/addons) 和一个[试验阶段插件仓库](https://github.com/oam-dev/catalog/tree/master/experimental) 。
你也可以参考这两个仓库，自己定制一个插件仓库， 下图展示如何通过 VelaUX 来管理插件仓库，你可以在这里添加、更新或删除一个插件仓库。
![alt](../../../resources/addon-registry.jpg)
需要注意的是，KubeVela 默认没有添加试验性的插件仓库，但你可以通过点击 `Add Experimental Registry` 一键将它添加进来，并使用其中的插件。

1
i18n/zh/docusaurus-plugin-content-docs/current/how-to/dashboard/application/get-application-revision.md
View File

@ -11,4 +11,5 @@ description: 查看应用当前部署版本和历史部署版本。
### 下一步
* [通过 CLI 进行版本管理](../../../end-user/version-control)
* [回收应用实例](./recycle-environment)

5
i18n/zh/docusaurus-plugin-content-docs/current/how-to/dashboard/config/helm-repo.md
View File

@ -1,6 +1,5 @@
---
标题: helm 仓库
描述: 配置 helm 仓库
title: 配置 Helm 仓库
---
在本教程中，我们将会介绍如何通过集成配置，创建 helm 仓库，并在创建应用时使用该仓库。
@ -9,7 +8,7 @@
## 创建一个 Helm 仓库
例如在本图中，你可以设置 helm 仓库的 url，并且如果你的仓库还开启了 `HTTP basic authentication` 你也可以为这个仓库设置 `username` 和 `paswword`。
例如在本图中，你可以设置 helm 仓库的 url，并且如果你的仓库还开启了 `HTTP basic authentication` 你也可以为这个仓库设置 `username` 和 `password`。
在本例子中，我们使用 [azure](https://marketplace.azurecr.io/helm/v1/repo) 作为 helm 仓库。

2
i18n/zh/docusaurus-plugin-content-docs/current/how-to/dashboard/user/rbac.md
View File

@ -2,7 +2,7 @@
title: RBAC 授权
---
RBAC 功能可以限制对 VelaUX 资源的访问。 VelaUX 的 UI 和 API 都会进行严格的权限校验。我们设计了平台级角色和项目级角色，每一个角色可绑定一组权限策略，用户绑定到角色即获取对应的权限。
RBAC 功能可以限制对 KubeVela 资源的访问。UI 和 API 都会进行严格的权限校验。我们设计了平台级角色和项目级角色，每一个角色可绑定一组权限策略，用户绑定到角色即获取对应的权限。
## 内置权限策略

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

@ -1,5 +1,5 @@
---
title: 自定义安装
title: 自定义安装和升级
---
import Tabs from "@theme/Tabs";

89
i18n/zh/docusaurus-plugin-content-docs/current/platform-engineers/helm/component.md
View File

@ -1,89 +0,0 @@
---
title: 怎么用 helm
---
在本节中，将介绍如何通过 `ComponentDefinition` 将 Helm charts 声明为应用程序组件。
> 在阅读本部分之前，请确保你已经了解了[定义和模板概念](../definition-and-templates)。
## 先决条件
* [fluxcd/flux2](../../install#3-optional-install-flux2)，请确保你已经在[安装指南](../../install)中安装了 flux2。
## 声明 `ComponentDefinition`
这是一个关于如何使用 Helm 作为 schematic 模块的示例 `ComponentDefinition`。
```yaml
apiVersion: core.oam.dev/v1beta1
kind: ComponentDefinition
metadata:
name: webapp-chart
annotations:
definition.oam.dev/description: helm chart for webapp
spec:
workload:
definition:
apiVersion: apps/v1
kind: Deployment
schematic:
helm:
release:
chart:
spec:
chart: "podinfo"
version: "5.1.4"
repository:
url: "http://oam.dev/catalog/"
```
详细：
- 需要`.spec.workload` 来指示这个基于 Helm 的组件的工作负载类型。 如果你将多个工作负载打包在一个 chart 中，请同时检查 [已知限制](./known-issues#=workload-type-indicator)。
- `.spec.schematic.helm` 包含 Helm `release` 和利用 `fluxcd/flux2` 的 `repository` 的信息。
- 即`release`的pec与[`HelmReleaseSpec`](https://github.com/fluxcd/helm-controller/blob/main/docs/api/helmrelease.md) 对齐，`repository`的 spec 和[`HelmRepositorySpec`](https://github.com/fluxcd/source-controller/blob/main/docs/api/source.md#source.toolkit.fluxcd.io/v1beta1.HelmRepository)对齐。
## 声明一个`Application`
这是一个示例 `Application`。
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: myapp
namespace: default
spec:
components:
- name: demo-podinfo
type: webapp-chart
properties:
image:
tag: "5.1.2"
```
组件 `properties` 正是 Helm Chart 的 [overlay values](https://github.com/captainroy-hy/podinfo/blob/master/charts/podinfo/values.yaml)。
部署应用程序，几分钟后（获取 Helm Chart 可能需要一些时间），你可以检查 Helm 版本是否已安装。
```shell
$ helm ls -A
myapp-demo-podinfo default 1 2021-03-05 02:02:18.692317102 +0000 UTC deployed podinfo-5.1.4 5.1.4
```
检查 Chart 中定义的工作负载是否已成功创建。
```shell
$ kubectl get deploy
NAME READY UP-TO-DATE AVAILABLE AGE
myapp-demo-podinfo 1/1 1 1 66m
```
检查应用程序的 `properties` 中的值（`image.tag = 5.1.2`）是否已分配给 Chart 。
```shell
$ kubectl get deployment myapp-demo-podinfo -o json | jq '.spec.template.spec.containers[0].image'
"ghcr.io/stefanprodan/podinfo:5.1.2"
```
### 从基于 Helm 的组件生成表单
KubeVela 会根据 Helm Chart 中的 [`values.schema.json`](https://helm.sh/docs/topics/charts/#schema-files) 自动生成 OpenAPI v3 JSON schema，并将其存储在一个 ` ConfigMap` 在与定义对象相同的 `namespace` 中。 此外，如果 Chart 作者未提供 `values.schema.json`，KubeVela 将根据其 `values.yaml` 文件自动生成 OpenAPI v3 JSON 模式。
请查看 [Generate Forms from Definitions](/docs/platform-engineers/openapi-v3-json-schema) 指南，了解有关使用此架构呈现 GUI 表单的更多详细信息。

78
i18n/zh/docusaurus-plugin-content-docs/current/platform-engineers/helm/known-issues.md
View File

@ -1,78 +0,0 @@
---
title: 已知限制
---
## 限制
以下是使用 Helm 图表作为应用程序组件的一些已知限制。
### 工作负载类型指示器
遵循微服务的最佳实践，KubeVela 建议在一个 Helm 图表中只存在一种工作负载资源。 请将你的“超级”Helm 图表拆分为多个图表（即组件）。 本质上，KubeVela 依赖于组件定义中的`workload`来指示它需要注意的工作负载类型，例如：
```yaml
apiVersion: core.oam.dev/v1beta1
kind: ComponentDefinition
...
spec:
workload:
definition:
apiVersion: apps/v1
kind: Deployment
```
```yaml
...
spec:
workload:
definition:
apiVersion: apps.kruise.io/v1alpha1
kind: Cloneset
```
请注意，如果多个工作负载类型打包在一个图表中，KubeVela 不会失败，问题在于进一步的操作行为，例如推出、修订和流量管理，它们只能对指定的工作负载类型生效。
### 始终使用完整的限定名称
工作负载的名称应使用 [完全限定的应用程序名称](https://github.com/helm/helm/blob/543364fba59b0c7c30e38ebe0f73680db895abb6/pkg/chartutil/create.go#L415) 进行模板化，并且请不要为`.Values.fullnameOverride`。作为最佳实践，Helm 还强烈建议通过 `$ helm create` 命令创建新图表，以便根据此最佳实践自动定义模板名称。
### 控制应用程序升级
对组件`properties` 所做的更改将触发 Helm 版本升级。此过程由 Flux v2 Helm 控制器处理，因此你可以定义基于 [Helm Release 文档](https://github.com/fluxcd/helm-controller/blob/main/docs/api/helmrelease.md#upgraderemediation) 和 [规范](https://toolkit.fluxcd.io/components/helm/helmreleases/#configuring-failure-remediation)的修复，以防在此升级过程中发生故障。
例如：
```yaml
apiVersion: core.oam.dev/v1beta1
kind: ComponentDefinition
metadata:
name: webapp-chart
spec:
...
schematic:
helm:
release:
chart:
spec:
chart: "podinfo"
version: "5.1.4"
upgrade:
remediation:
retries: 3
remediationStrategy: rollback
repository:
url: "http://oam.dev/catalog/"
```
尽管目前存在一个问题，但很难获得有关 Helm 实时发布的有用信息，以了解升级失败时发生的情况。我们将增强可观察性，帮助用户在应用层面跟踪 Helm 发布的情况。
## 问题
已知问题将在后续版本中修复。
### 推出策略
目前，基于 Helm 的组件无法受益于 [应用程序级部署策略](https://github.com/oam-dev/kubevela/blob/master/design/vela-core/rollout-design.md#applicationdeployment-workflow)。如[本示例](./trait#update-an-applicatiion)所示，如果应用更新了，只能直接 rollout，没有 canary 或者 blue-green 方式。
### 更新特征属性也可能导致 Pod 重启
特性属性的更改可能会影响组件实例，属于此工作负载实例的 Pod 将重新启动。在基于 CUE 的组件中，这是可以避免的，因为 KubeVela 可以完全控制资源的渲染过程，尽管在基于 Helm 的组件中，它目前被推迟到 Flux v2 控制器。

153
i18n/zh/docusaurus-plugin-content-docs/current/platform-engineers/helm/trait.md
View File

@ -1,153 +0,0 @@
---
标题: 添加 Trait 特性
---
KubeVela 中的 Trait 特性可以从基于Helm的组件无缝添加.
在以下应用实例中，我们将基于 Helm 组件添加两个 Trait 特性 [scaler](https://github.com/oam-dev/kubevela/blob/master/charts/vela-core/templates/defwithtemplate/manualscale.yaml) 和 [virtualgroup](https://github.com/oam-dev/kubevela/blob/master/docs/examples/helm-module/virtual-group-td.yaml).
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: myapp
namespace: default
spec:
components:
- name: demo-podinfo
type: webapp-chart
properties:
image:
tag: "5.1.2"
traits:
- type: scaler
properties:
replicas: 4
- type: virtualgroup
properties:
group: "my-group1"
type: "cluster"
```
> 注意: 当我们使用基于 Helm 的 Trait 特性时, *请确认在你 Helm 图标中的目标负载严格按照 qualified-full-name convention in Helm 的命名方式.* [以此表为例](https://github.com/captainroy-hy/podinfo/blob/c2b9603036f1f033ec2534ca0edee8eff8f5b335/charts/podinfo/templates/deployment.yaml#L4),
> 负载名为[版本名和图表名](https://github.com/captainroy-hy/podinfo/blob/c2b9603036f1f033ec2534ca0edee8eff8f5b335/charts/podinfo/templates/_helpers.tpl#L13).
> 这是因为 KubeVela 依赖命名去发现负载,否则将不能把 Trait 特性赋予负载. KubeVela 将会基于你的应用和组件自动生成版本名, 所以你需要保证不能超出你的 Helm 图表中命名模版格式.
## 验证特性工作正确
> 因为应用内部的调整生效需要几秒钟时间.
检查缩放组 `scaler` 特性生效.
```shell
$ kubectl get manualscalertrait
NAME AGE
demo-podinfo-scaler-d8f78c6fc 13m
```
```shell
$ kubectl get deployment myapp-demo-podinfo -o json | jq .spec.replicas
4
```
检查虚拟组 `virtualgroup` 特性.
```shell
$ kubectl get deployment myapp-demo-podinfo -o json | jq .spec.template.metadata.labels
{
"app.cluster.virtual.group": "my-group1",
"app.kubernetes.io/name": "myapp-demo-podinfo"
}
```
## 更新应用
当应用已被部署且 workload 负载/ Trait 特性都被顺利建立时,
你可以更新应用, 变化会被负载实例所响应.
让我们对实例应用的配置做几个改动.
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: myapp
namespace: default
spec:
components:
- name: demo-podinfo
type: webapp-chart
properties:
image:
tag: "5.1.3" # 5.1.2 => 5.1.3
traits:
- type: scaler
properties:
replicas: 2 # 4 => 2
- type: virtualgroup
properties:
group: "my-group2" # my-group1 => my-group2
type: "cluster"
```
在几分钟后应用新配置并检查效果.
检查从应用属性 `properties` 的新值 (`image.tag = 5.1.3`) 已被赋予图表.
```shell
$ kubectl get deployment myapp-demo-podinfo -o json | jq '.spec.template.spec.containers[0].image'
"ghcr.io/stefanprodan/podinfo:5.1.3"
```
实际上, Helm 更新了版本号 (revision 1 => 2).
```shell
$ helm ls -A
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
myapp-demo-podinfo default 2 2021-03-15 08:52:00.037690148 +0000 UTC deployed podinfo-5.1.4 5.1.4
```
检查 `scaler` 的特性.
```shell
$ kubectl get deployment myapp-demo-podinfo -o json | jq .spec.replicas
2
```
检查 `virtualgroup` 的特性.
```shell
$ kubectl get deployment myapp-demo-podinfo -o json | jq .spec.template.metadata.labels
{
"app.cluster.virtual.group": "my-group2",
"app.kubernetes.io/name": "myapp-demo-podinfo"
}
```
## 去除 Trait 特性
让我们试试从应用中去除特性.
```yaml
apiVersion: core.oam.dev/v1alpha2
kind: Application
metadata:
name: myapp
namespace: default
spec:
components:
- name: demo-podinfo
type: webapp-chart
settings:
image:
tag: "5.1.3"
traits:
# - name: scaler
# properties:
# replicas: 2
- name: virtualgroup
properties:
group: "my-group2"
type: "cluster"
```
更新应用实例并检查 `manualscalertrait` 已被删除.
```shell
$ kubectl get manualscalertrait
No resources found
```

21
i18n/zh/docusaurus-plugin-content-docs/current/platform-engineers/system-operation/managing-clusters.md
View File

@ -2,16 +2,27 @@
title: 集群管理
---
KubeVela 多集群功能中的集群管理是通过 Vela CLI 的一系列相关命令完成的。
## 通过 UI 管理集群
* 支持添加已存在的 Kubernetes 集群；
* 支持添加阿里云 ACK 集群；
具有集群管理权限的用户可以进入集群管理页面，添加或移除托管的集群。
![cluster-management](https://static.kubevela.net/images/1.3/cluster-management.jpg)
从 ACK 添加的集群平台会获取并记录集群所在的区域、VPC、Dashboard地址等信息，用户使用该集群创建交付目标时将自动引用，这些信息用以辅助云服务的创建。
## 通过 CLI 管理集群
### vela cluster list
该命令可列出当前 KubeVela 正在管理的所有子集群。
```bash
$ vela cluster list
CLUSTER TYPE ENDPOINT
cluster-prod tls https://47.88.4.97:6443
cluster-staging tls https://47.88.7.230:6443
$ vela cluster list
CLUSTER ALIAS TYPE ENDPOINT ACCEPTED LABELS
local Internal - true
ask-beijing X509Certificate https://*.*.*.*:6443 true
```
### vela cluster join

7
i18n/zh/docusaurus-plugin-content-docs/current/platform-engineers/system-operation/offline-installation.md
View File

@ -1,6 +1,6 @@
# KubeVela Offline Installation Guide
---
title: 离线安装
---
KubeVela 离线部署包含 KubeVela Core 和 KubeVela Addon 的离线部署。
@ -56,5 +56,4 @@ charts/vela-core/templates/defwithtemplate/nocalhost.yaml: image: "
重新打包上面修改好的 Helm Chart 包，直接安装或者传入离线环境的 Helm Chart 仓库。
## KubeVela Addon 离线部署

107
i18n/zh/docusaurus-plugin-content-docs/current/quick-start.md
View File

@ -2,80 +2,93 @@
title: 交付第一个应用
---
> 在实践之前，请确保你已经按照 [快速安装](./install.mdx) 文档，在你的控制平面集群中安装了 KubeVela Core 和 VelaUX。
>
> 如果你希望通过使用 KubeVela CLI 来进行应用交付，请查看 Vela CLI 手册的 [交付第一个应用](./end-user/quick-start-cli)。
> 开始之前，请确认你已完成 KubeVela 的安装，参考 [安装指导文档](./install.mdx)
欢迎来到 KubeVela！在本小节中，我们会向你介绍如何使用 VelaUX 来交付一个简单的应用。
欢迎使用 KubeVela, 在该章节中你可以学习到使用 KubeVela 部署一个基础的应用。
你将会操作的步骤有：
## 通过 CLI 部署应用
1. 准备一个服务镜像，本例中我们将使用： [crccheck/hello-world](https://hub.docker.com/r/crccheck/hello-world)，请确保你的环境可以正常下载该镜像；
2. 基于服务镜像创建第一个 `webservice` 类型的 `Application`，这是无状态服务最简化的交付方式；
3. 查看应用实例运行状态；
一个基础的应用定义及部署方式如下所述：
你将学习到内容的有：
- 初步接触 [应用(Application)](./getting-started/core-concept#应用（application）)、[环境(Environment)](getting-started/core-concept#环境（Environment））) 和 [交付目标(Target)](getting-started/core-concept#交付目标（target）) 等核心概念。
- 通过操作 VelaUX 完整交付一个应用。
## 登陆到 VelaUX
正常安装 VelaUX 后你需要登陆。默认账号为admin，通过以下方式获取密码
```shell
# 首次安装时获取
vela logs -n vela-system --name apiserver addon-velaux | grep "initialized admin username"
```yaml
cat <<EOF | vela up -f -
# YAML begins
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: first-vela-app
spec:
components:
- name: express-server
type: webservice
properties:
image: crccheck/hello-world
ports:
- port: 8000
expose: true
# YAML ends
EOF
```
如果日志中已不存在信息，可查询 `vela-system` 命名空间下的 `admin` 名称的 Secret。
复制上述命名并执行后，一个简单的应用即可完成部署，需要注意的是需要你的部署环境可以正常获取 `crccheck/hello-world` 镜像。部署完成后可以通过下述方式来访问该应用。
## 选择应用的部署类型/规划应用部署环境
```
$ vela port-forward first-vela-app 8000:8000
<xmp>
Hello World
你进入的第一个页面即应用交付管理页面，在该页面中你可以查看到有权查看的所有应用列表。管理员初次进入时你可以看到一个只读的 `addon-velaux` 应用，它是VelaUX addon的运行应用，我们仅能进行运行数据观测。
![dashboard](https://static.kubevela.net/images/1.3/dashboard.jpg)
## .
## ## ## ==
## ## ## ## ## ===
/""""""""""""""""\___/ ===
~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ / ===- ~~~
\______ o _,/
\ \ _,'
`'--.._\..--''
</xmp>
```
然后点击右上角的 `New Application` 按钮开始创建应用，按照 UI 提示填写以下四个维度的信息：
到这里，你已完成了第一个简单应用的部署，它仅包括一个组件，暂未涉及运维特征、工作流和多集群等特性。
- 应用的名称等基础信息；
- 选择所属的项目，我们已为你自动生成了默认项目，你也可以点击 `New` 进行创建；
- 选择应用的部署类型，本例中我们选择 `webservice` 类型，部署无状态服务，请注意，企业大多数业务应用都可以直接使用该类型进行部署。
- 规划应用交付的环境，我们选择基于默认 `Default` 交付目标创建的默认 `Default` 环境；
> 目前，通过 CLI 创建的应用会同步到 UI 进行可视化，但它是只读的。
![new-app](https://static.kubevela.net/images/1.3/new-app.jpg)
## 通过 UI 部署应用
## 设置应用的部署参数
登陆到 KubeVela UI 控制后，默认你将进入应用管理页面。点击页面右上方的 `新建应用` 按钮，输入应用基础信息：
接下来看到应用的部署配置页面，我们需要配置的以下信息：
1. 应用名称、别名等基础信息；
2. 选择一个应用所属项目，平台默认生成了 `Default` 项目，你可以根据需要创建新的项目；
3. 选择主组件类型，这里我们选择默认的 `webservice` 类型。
4. 选择部署环境，部署环境选项由不同的项目决定。
- Image 地址，填入 `crccheck/hello-world`。
### 设置部署参数
> 其他参数设置在当前用例中无需进行设置。
设置完应用基础信息后进入第二步，设置主组件的部署参数，我们需要设置的参数包括：
![](./resources/port-first-vela-app.png)
- 镜像地址： `crccheck/hello-world`
- 端口信息：将默认的 80 端口变更为 8080 端口。
确认创建后即可进入应用管理页面，这时应用还没有开始进行部署，VelaUX 默认生成了默认环境的交付 [工作流](./getting-started/core-concept#工作流（workflow）) 和调整应用副本数量的 [运维特征](./getting-started/core-concept#运维特征（trait）)。
![create hello world app](https://static.kubevela.net/images/1.3/create-helloworld.jpg)
![](./resources/created-first-vela-app.jpg)
确认创建后即可完成应用配置，控制台创建的应用默认会根据所选环境生成 [工作流](./getting-started/core-concept#workflow) 和一个设置副本数的 [运维特征](./getting-started/core-concept#trait)。
## 执行环境的部署
### 执行工作流部署应用
直接点击页面右上方的部署按钮。工作流执行完成后刷新应用部署状态页面即可查看到该应用交付的资源清单和组件状态。切换到实例页面可查询到该应用生成的实例信息。
点击应用详情页右上方的 `部署` 按钮，选择指定环境的工作流即可开始部署应用。
![](./resources/succeed-first-vela-app.jpg)
## 应用删除
### 删除应用
体验完成后如何你需要删除部署的应用，你需要进行如下操作：
如果在你测试完成后需要删除该应用，操作方式如下：
（1）进入应用的环境页面，点击 `Recycle`，即可完成该环境的部署资源回收。
1. 进入应用环境页面，点击 `回收` 按钮完成所有环境的资源回收。
2. 回到应用列表页面，点击卡片中的操作按钮，点击删除选项确认删除即可。
（2）回到应用列表页面，点击应用卡片的操作按钮，选择删除即可。
通过上述操作，你已经完成了第一个应用的交付，完成了进阶。
到此，你完成了 KubeVela 的初体验。
## 下一步
- 阅读并参考 [实践教程](./tutorials/k8s-object) 章节文章，解锁更多 KubeVela 能力。
- 阅读 [核心概念](./getting-started/core-concept) 文档获取核心概念解读。
- 阅读 [用户手册](./tutorials/webservice) 获取更多特性玩法。

64
i18n/zh/docusaurus-plugin-content-docs/current/tutorials/helm.md
View File

@ -32,6 +32,12 @@ description: 本文介绍通过 KubeVela 交付 Helm Chart
当观察到插件显示为 `enabled` 状态，即代表插件启用已经完成。可以开始交付 Helm 应用了。
你也可以通过 CLI 来启用插件：
```shell
vale addon enable fluxcd
```
## 通过 Chart 创建 Redis 应用
相信你通过之前的文章，已经掌握了应用的创建能力。我们需要使用 Chart 创建 Redis 应用，只需要选择应用部署类型为 `helm`，然后选择你准备好的具有默认 StorageClass 可以提供 PV 的集群 Target，然后进入部署参数配置页面。
@ -50,10 +56,66 @@ description: 本文介绍通过 KubeVela 交付 Helm Chart
## 修改部署参数
这里我们解锁新技能，修改应用的部署参数。对于任何应用类型，它都可以在任何时候通过点击 `Baseline Config` 页面右上方的 `Edit Properties` 按钮进入部署参数的修改页面。该页面与我们创建应用时设置应用部署参数的页面完全一致，它是由每一个应用类型的 Definition 定义的参数结合 KubeVela UISchema 规范自动生成。
在 UI 中点击配置页面的组件名称即可进入组件的配置页面，对于 Helm Chart 部署的组件，我们能够通过设置 Values 配置项来变更部署参数，也可以支持变更 Chart 的来源。其中 Values 配置项会基于 `values.yaml` 文件中的默认值来生成配置提醒，你可以选择需要配置的行并为其设置需要的值。
修改部署参数后，必须执行环境的工作流才能将修改后的参数在指定的环境生效，由于版本管理的机制存在，历史配置参数会在版本中得以保存。
## 通过 CLI 部署
你也可以通过 CLI 来部署 Helm Chart 类型的应用, 基础配置如下：
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: helm-redis
spec:
components:
- name: redis
type: helm
properties:
repoType: "helm"
url: "https://charts.bitnami.com/bitnami"
chart: "redis"
version: "16.8.5"
values:
master.persistence.size: 16Gi
replica.persistence.size: 16Gi
```
你可以通过下述命令完成部署：
```shell
vela up -f https://kubevela.io/example/applications/app-with-chart-redis.yaml
```
接下来，通过 `vela status helm-redis` 命令查询部署应用的状态，直到进入下述状态即部署成功。
```
About:
Name: helm-redis
Namespace: default
Created at: 2022-04-21 17:19:12 +0800 CST
Status: running
Workflow:
mode: DAG
finished: true
Suspend: false
Terminated: false
Steps
- id:n1gxswwina
name:redis
type:apply-component
phase:succeeded
message:
Services:
- Name: redis
Cluster: local Namespace: default
Type: helm
Healthy Fetch repository successfully, Create helm release successfully
No trait applied
```
到此，你已经掌握了 Helm 应用的交付能力，快去交付更多的 Helm 应用吧。
## 下一步

4
i18n/zh/docusaurus-plugin-content-docs/current/tutorials/jenkins.md
View File

@ -1,5 +1,5 @@
---
title: 对接 Jenkins
title: 集成 Jenkins 进行持续交付
---
### 简介
@ -10,6 +10,8 @@ KubeVela 应用的工作流可以通过 Webhook 触发器触发。这使得诸
本文将详细介绍如何对接 KubeVela 与 Jenkins。
> 该教程仅适用于 UI 用户。
### 准备
在开始本文教程之前，需要先确认一下的事项

108
i18n/zh/docusaurus-plugin-content-docs/current/tutorials/k8s-object.mdx
View File

@ -86,9 +86,113 @@ KubeVela 支持面向应用组织多个 Kubernetes 资源进行交付，常见
![](../resources/multiple-target-pods.jpg)
到此你已经完成了交付 Kubernetes 原生资源的学习！
## 通过 CLI 交付
<!-- ## 参考视频 TODO v1.2 -->
通过 CLI 部署的应用没有环境的概念，你可以通过部署多个应用来实现与控制台中类似的环境隔离。
这是一个部署 Kubernetes 原生资源的示例应用，我们知道大多数 Kubernetes 应用都由 Deployment 和 Service 组成。该应用配置中包括了 2 个部署策略和 3 个工作流步骤，这些配置的表达的含义是部署应用到两个命名空间且在第一个完成部署后需要人工审核。
```yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: app-with-k8s-objects
namespace: default
spec:
components:
- name: k8s-demo-service
properties:
objects:
- apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
spec:
replicas: 2
selector:
matchLabels:
app: nginx
strategy:
type: Recreate
template:
metadata:
labels:
app: nginx
spec:
containers:
- image: nginx
name: nginx
ports:
- containerPort: 80
- apiVersion: v1
kind: Service
metadata:
annotations:
service.beta.kubernetes.io/aws-load-balancer-type: nlb
labels:
app: nginx
name: nginx
namespace: default
spec:
externalTrafficPolicy: Local
ports:
- name: http
port: 80
protocol: TCP
targetPort: 80
selector:
app: nginx
type: LoadBalancer
type: k8s-objects
policies:
- name: topology-default
type: topology
properties:
clusters: ["local"]
namespace: default
- name: topology-production
type: topology
properties:
clusters: ["local"]
namespace: production
workflow:
steps:
- name: deploy2default
properties:
policies: ["topology-default"]
type: deploy
- name: suspend
type: suspend
- name: deploy2production
properties:
policies: ["topology-production"]
type: deploy
```
- 关于 Topology 策略参考: [Topology](../end-user/policies/references#override)
- 关于 Deploy 步骤参考: [Deploy](../end-user/workflow/built-in-workflow-defs#deploy)
通过下述命令来部署该应用：
- 在部署之前创建所需的命名空间 `production`
```shell
$ vela up -f https://kubevela.io/example/applications/create-namespace.yaml
```
- 部署该应用
```shell
$ vela up -f https://kubevela.io/example/applications/app-with-k8s-objects.yaml
```
- 查询应用状态进入暂停状态后执行审核命令：
```shell
$ vela workflow resume app-with-k8s-objects
```
到此你已经完成了交付 Kubernetes 原生资源的学习！
## 下一步

2
i18n/zh/docusaurus-plugin-content-docs/current/tutorials/sso.md
View File

@ -1,5 +1,5 @@
---
title: 使用单点登录
title: 单点登录
---
## 简介

4
i18n/zh/docusaurus-plugin-content-docs/current/tutorials/trigger.md
View File

@ -1,5 +1,5 @@
---
title: 在持续交付中集成镜像仓库
title: 集成镜像仓库进行持续交付
---
## 简介
@ -10,6 +10,8 @@ title: 在持续交付中集成镜像仓库
本文将详细介绍如何使用 KubeVela 触发器来完成基于镜像版本的自动化部署，在本文的例子当中，我们将使用 GitLab 作为代码仓库，Harbor 作为镜像仓库来完成演示。
> 该教程仅适用于 UI 用户。
## 创建应用
要使用触发器，首先我们需要在 VelaUX 上新建一个应用。在这里，我们可以新建一个 WebService 类型的应用，并使用 LoadBalancer 为其暴露 80 端口以便访问。

105
i18n/zh/docusaurus-plugin-content-docs/current/tutorials/webservice.md
View File

@ -9,60 +9,111 @@ description: 参考本文章，学习使用容器镜像部署企业业务应用
- 完成你的业务容器化，无论你的业务使用何种开发语言，请先将其通过 CI 系统或在本地完成运行镜像打包。
> KubeVela 未来计划提供支持多种开发语言的容器打包方案，帮助你低门槛完成业务容器化。
- 将你的业务镜像存放于镜像仓库中，KubeVela 管理的集群可以正常获取该镜像。
- 明确你的业务需要设置哪些环境变量，是否有其他中间件依赖（比如数据库、缓存等），如果有，请先部署中间件服务。
- 启用了 VelaUX 插件，如果你仅是 CLI 用户，直接参考 [通过 CLI 部署](#deploy-via-cli)
## 创建应用
进入 KubeVela 应用管理页面（目录：Applictaions），点击 `New Application` 进入应用创建流程。首先设置应用的名称、别名和描述；选择类型 `webservice`；选择发布的环境，初始情况下已经存在 Default 环境可选，你也可以进入环境管理页面(目录：Envs) 创建新的环境。
进入应用管理页面，点击右上方的 `新建应用` 按钮，进入应用创建弹窗页面，输入应用名称等基础信息，选择 `webservice` 主组件类型，并选择需要部署的环境。点击下一步进入组件部署属性配置页面，如图所示，填写镜像名称、启动命令，端口等信息。根据你的集群支持情况选择合适的服务暴露方式。
![create webservice application](../resources/create-webservice.jpg)
![set webservice application](https://static.kubevela.net/images/1.3/create-webservice.jpg)
点击 `Next Step` 进入部署参数设置页面。在当前页面中，我们需要设置业务应用的镜像名称（Image），如果需要设置镜像的启动命令，可以打开 `CMD` 栏目，添加启用命令，如果需要设置环境变量，可以打开 `ENV` 栏目，按照需要设置环境变量。
![set webservice application](../resources/set-webservice.jpg)
截图所示部署的业务是 `Wordpress`，填写了镜像名称 `wordpress` 和设置了四个环境变量，若你也使用该镜像进行测试，请设置正确的数据库地址变量。
点击 `Create` 完成应用的创建流程，进入应用管理页面。
确认提交后即完成应用初始化配置。
## 部署应用
点击页面右上方的 `Deploy` 按钮，开始应用的部署。点击该按钮的含义是执行默认的工作流。请注意，KubeVela 已经为应用的每一个发布环境生成了对应的工作流。在 `Baseline Config` 的右方即为应用需要交付的环境，点击环境名称即可进入该环境页面查询应用部署状态和应用实例信息。
应用创建后默认不会自动部署，需要点击页面右上方的部署按钮，并选择需要执行的工作流，每一个工作流对应部署一个环境。部署开始后可以点击 `基础配置` 旁边的不同 Tab 即进入不同环境的管理页面。
![webservice application env page](../resources/webservice-env.jpg)
若该环境中包括多个交付目标，可以切换不同的交付目标查看应用实例列表。点击 `Check the details`，在弹窗中可以查看到应用的部署整体进度和创建的资源信息。
每一个环境视图目前提供了部署资源状态、应用实例和应用日志的查询页面。部署资源状态页面展示了该应用实际分发的底层资源列表即各组件状态；应用实例页面中展示该应用部署的所有实例信息，点击实例行即可查询该实例的详细信息；日志页面可以查询该应用所有运行实例的标准输出日志。
在实例列表中可以查看应用实例的交付状态，若其一直处于非运行态，可点击实例行最前方的+号展开实例详情，查看详细信息。
## 更新镜像版本
## 变更镜像版本
当我们完成初始部署后，后续随着我们业务开发和升级需要变更镜像版本或其他部署参数。
当应用完成第一次部署后，我们的业务可能在持续开发，后续产生的新版本镜像，我们需要变更镜像版本。点击 `Baseline Config`，进入应用配置页面，点击 `Edit Properties` 按钮即可再次进入部署参数设置页面，在该页面中可以变更镜像名称，版本和环境变量等参数。
回到基础配置页面，点击需要修改的组件名称即可进入组件设置弹窗页面，在该页面中你可以修改部署镜像、环境变量等部署参数，也可以变更组件别名或描述等基础信息。
## 变更应用的副本数量
## 更新副本数
如果业务应用需要设置多个副本，进入应用配置页面，在运维特征管理中，已经默认挂载了名为 `Set Replicas` 的运维特征，点击设置图标按钮即可进入副本数调整设置页面，填写你需要设置的副本数量，点击 `Update` 按钮提交即可。
如果你的业务需要扩大或减小规模，我们使用调整副本数的运维特征来设置副本数量，在控制台中创建的应用该运维特征会自动创建。点击组件卡片上的`Scaler`运维特征即可进入配置页面，你可以手动设置需要的副本数量。
![set application replicas](../resources/set-replicas.jpg)
## 应用升级
## 升级应用
上述两个步骤分别改变了应用的部署参数和运维特征，但是它还处于草稿状态，我们需要再次点击部署按钮即可将应用完成升级。
上述两个步骤我们只是修改了应用的配置参数，但其不是立即在部署环境中生效的，我们可以再次点击部署按钮选择需要升级的环境对应的工作流执行，即可完成指定环境的升级。
## 应用回收与删除
## 通过 CLI 部署应用
若你测试完成需要将应用删除，需要首先回收所有部署的环境，同样点击环境名称进入环境实例列表查询页面，点击 `Recycle` 按钮即可回收应用在该环境的部署。回收完成后应用在该环境进入未部署状态。
如果你不使用 UI，通过 CLI 也可以完成业务应用示例的部署，通过执行下述命令即可：
当所有环境都已回收完成后，可进行应用删除操作。目前应用删除入口在应用列表页面。点击左侧目录，回到应用列表页面，鼠标应用名称右侧的操作图标上，点击 `Remove` 选项即可。
```yaml
cat <<EOF | vela up -f -
# YAML begins
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: webservice-app
spec:
components:
- name: frontend
type: webservice
properties:
image: oamdev/testapp:v1
cmd: ["node", "server.js"]
ports:
- port: 8080
expose: true
exposeType: LoadBalancer
cpu: "0.5"
memory: "512Mi"
traits:
- type: scaler
properties:
replicas: 1
# YAML ends
EOF
```
![delete application](../resources/app-delete.jpg)
> 目前，通过 CLI 部署的应用会同步到控制台中，但其为只读状态。
到此，你已经基本掌握了业务应用的部署方法，更多的部署参数支持都集中在应用部署参数设置页面之中。
你也可以复制上述的应用配置并创建一个 YAML 文件 `webservice-app.yaml`，然后使用命令 `vela up -f webservice-app.yaml` 来完成部署。
接下来你可以通过 `vela status webservice-app` 命令获取应用的部署状态。
```
About:
Name: test-app
Namespace: default
Created at: 2022-04-21 12:03:42 +0800 CST
Status: running
Workflow:
mode: DAG
finished: true
Suspend: false
Terminated: false
Steps
- id:y4n26n7uql
name:frontend
type:apply-component
phase:succeeded
message:
Services:
- Name: frontend
Cluster: local Namespace: default
Type: webservice
Healthy Ready:1/1
Traits:
✅ scaler
```
## 下一步
[学习基于 Helm Chart 部署中间件应用](./helm)
[学习基于 Helm Chart 部署应用](./helm)

90
sidebars.js
View File

@ -34,11 +34,10 @@ module.exports = {
"end-user/components/more",
],
},
"case-studies/multi-cluster",
"tutorials/jenkins",
"tutorials/trigger",
"case-studies/multi-cluster",
"case-studies/gitops",
"case-studies/initialize-env",
{
type: "category",
label: "How-to Guides",
@ -53,34 +52,10 @@ module.exports = {
],
},
{
"Multi-Cluster Delivery": [
"platform-engineers/system-operation/managing-clusters",
],
},
"end-user/traits/ingress",
"end-user/traits/service-binding",
"end-user/traits/sidecar",
"end-user/policies/health",
"end-user/workflow/webhook-notification",
{
"Day-2 Operations": [
"end-user/traits/rollout",
"end-user/traits/more",
],
},
{
"Advanced Features": [
"end-user/workflow/component-dependency-parameter",
"end-user/version-control",
"end-user/policies/apply-once",
"end-user/policies/gc",
],
},
{
"Manage applications": [
"Deploy applications": [
"how-to/dashboard/application/create-application",
"how-to/dashboard/application/bind-new-environment",
"tutorials/workflows",
"how-to/dashboard/application/deploy-application",
"how-to/dashboard/application/get-application-instance",
"tutorials/scaler",
@ -93,30 +68,32 @@ module.exports = {
],
},
{
"Manage workflows": [
"tutorials/workflows",
"how-to/dashboard/workflow/overview",
"Day-2 Operations": [
"end-user/traits/rollout",
"end-user/traits/ingress",
"end-user/traits/service-binding",
"end-user/traits/sidecar",
"end-user/policies/health",
"end-user/workflow/webhook-notification",
"end-user/service-account-integration",
"how-to/dashboard/trigger/overview",
"end-user/traits/more",
],
},
{
"Manage traits": ["how-to/dashboard/trait/overview"],
},
{
"Manage triggers": ["how-to/dashboard/trigger/overview"],
},
{
"Manage resource": ["how-to/dashboard/target/overview"],
},
"how-to/dashboard/user/user",
"how-to/dashboard/user/rbac",
"how-to/dashboard/user/project",
{
"Manage integration configs": [
"how-to/dashboard/config/dex-connectors",
"how-to/dashboard/config/helm-repo",
],
},
"how-to/dashboard/addon/overview",
{
"Advanced Features": [
"end-user/workflow/component-dependency-parameter",
"end-user/version-control",
"end-user/policies/apply-once",
"end-user/policies/gc",
],
},
],
},
],
@ -126,9 +103,23 @@ module.exports = {
label: "Operator Manual",
items: [
"tutorials/sso",
"platform-engineers/system-operation/bootstrap-parameters",
"end-user/service-account-integration",
"platform-engineers/system-operation/offline-installation",
"how-to/dashboard/user/user",
"how-to/dashboard/user/rbac",
"how-to/dashboard/user/project",
{
"Manage resource": [
"platform-engineers/system-operation/managing-clusters",
"how-to/dashboard/target/overview",
],
},
"how-to/addon",
{
"Install or upgrade": [
"platform-engineers/system-operation/bootstrap-parameters",
"platform-engineers/advanced-install",
"platform-engineers/system-operation/offline-installation",
],
},
"platform-engineers/system-operation/observability",
"platform-engineers/system-operation/performance-finetuning",
{
@ -153,10 +144,7 @@ module.exports = {
],
},
{
Addons: [
"how-to/cli/addon/addon",
"platform-engineers/addon/intro",
],
Addons: ["platform-engineers/addon/intro"],
},
"platform-engineers/components/custom-component",
{

16
static/example/applications/app-with-chart-redis.yaml Normal file
View File

@ -0,0 +1,16 @@
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: helm-redis
spec:
components:
- name: redis
type: helm
properties:
repoType: "helm"
url: "https://charts.bitnami.com/bitnami"
chart: "redis"
version: "16.8.5"
values:
master.persistence.size: 16Gi
replica.persistence.size: 16Gi

74
static/example/applications/app-with-k8s-objects.yaml Normal file
View File

@ -0,0 +1,74 @@
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: app-with-k8s-objects
namespace: default
spec:
components:
- name: k8s-demo-service
properties:
objects:
- apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
spec:
replicas: 2
selector:
matchLabels:
app: nginx
strategy:
type: Recreate
template:
metadata:
labels:
app: nginx
spec:
containers:
- image: nginx
name: nginx
ports:
- containerPort: 80
- apiVersion: v1
kind: Service
metadata:
annotations:
service.beta.kubernetes.io/aws-load-balancer-type: nlb
labels:
app: nginx
name: nginx
namespace: default
spec:
externalTrafficPolicy: Local
ports:
- name: http
port: 80
protocol: TCP
targetPort: 80
selector:
app: nginx
type: LoadBalancer
type: k8s-objects
policies:
- name: topology-default
type: topology
properties:
clusters: ["local"]
namespace: default
- name: topology-production
type: topology
properties:
clusters: ["local"]
namespace: production
workflow:
steps:
- name: deploy2default
properties:
policies: ["topology-default"]
type: deploy
- name: suspend
type: suspend
- name: deploy2production
properties:
policies: ["topology-production"]
type: deploy

15
static/example/applications/create-namespace.yaml Normal file
View File

@ -0,0 +1,15 @@
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: init-namespace
namespace: default
spec:
components:
- name: production
properties:
objects:
- kind: Namespace
apiVersion: v1
metadata:
name: production
type: k8s-objects