align with en (#94)
This commit is contained in:
yangsoon
GitHub
parent
e136277247
commit
cf311b6a93
|
|
@ -30,6 +30,6 @@ vela system cue-packages
|
|||
|
||||
### SEE ALSO
|
||||
|
||||
* [vela system](vela_system.md) - System management utilities
|
||||
* [vela system](vela_system) - System management utilities
|
||||
|
||||
###### Auto generated by spf13/cobra on 2-May-2021
|
||||
|
|
|
|||
|
|
@ -34,6 +34,6 @@ vela live-diff -f app-v2.yaml -r app-v1 --context 10
|
|||
|
||||
### SEE ALSO
|
||||
|
||||
* [vela system](vela_system.md) - System management utilities
|
||||
* [vela system](vela_system) - System management utilities
|
||||
|
||||
###### Auto generated by spf13/cobra on 2-May-2021
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ title: How-to
|
|||
|
||||
In this section, it will introduce how to use [CUE](https://cuelang.org/) to declare app components via `ComponentDefinition`.
|
||||
|
||||
> Before reading this part, please make sure you've learned the [Definition CRD](../definition-and-templates.md) in KubeVela.
|
||||
> Before reading this part, please make sure you've learned the [Definition CRD](../definition-and-templates) in KubeVela.
|
||||
|
||||
## Declare `ComponentDefinition`
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ title: How-to
|
|||
|
||||
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.md).
|
||||
> Before reading this part, please make sure you've learned [the definition and template concepts](../definition-and-templates).
|
||||
|
||||
## Prerequisite
|
||||
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ Introduce how to automatically scale workloads by cron.
|
|||
timezone: "America/Los_Angeles"
|
||||
```
|
||||
|
||||
> The full specification of `autoscale` could show up by `$ vela show autoscale` or be found on [its reference documentation](../references/traits/autoscale)
|
||||
> The full specification of `autoscale` could show up by `$ vela show autoscale`.
|
||||
|
||||
2. Deploy an application
|
||||
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ The app will emit random latencies as metrics.
|
|||
EOF
|
||||
```
|
||||
|
||||
> The full specification of `metrics` could show up by `$ vela show metrics` or be found on [its reference documentation](../references/traits/metrics)
|
||||
> The full specification of `metrics` could show up by `$ vela show metrics`.
|
||||
|
||||
2. Deploy the application:
|
||||
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ services:
|
|||
domain: "example.com"
|
||||
```
|
||||
|
||||
> The full specification of `rollout` could show up by `$ vela show rollout` or be found on [its reference documentation](../references/traits/rollout)
|
||||
> The full specification of `rollout` could show up by `$ vela show rollout`.
|
||||
|
||||
Apply this `appfile.yaml`:
|
||||
|
||||
|
|
|
|||
|
|
@ -42,7 +42,7 @@ services:
|
|||
rewriteTarget: /
|
||||
```
|
||||
|
||||
> The full specification of `route` could show up by `$ vela show route` or be found on [its reference documentation](../references/traits/route)
|
||||
> The full specification of `route` could show up by `$ vela show route`.
|
||||
|
||||
Apply again:
|
||||
|
||||
|
|
|
|||
|
|
@ -219,7 +219,7 @@ spec:
|
|||
|
||||
### [可选] 配置其他类型的 workload
|
||||
|
||||
至此，我们成功地部署一个默认类型的 workload 的 *[web 服务](references/component-types/webservice)*。我们也可以添加 *[Task](references/component-types/task)* 类型的服务到同一个 app 中。
|
||||
至此，我们成功地部署一个默认类型的 workload 的 *[web 服务](../end-user/components/webservice)*。我们也可以添加 *[Task](../end-user/components/task)* 类型的服务到同一个 app 中。
|
||||
|
||||
```yaml
|
||||
services:
|
||||
|
|
|
|||
|
|
@ -98,7 +98,6 @@ worker Deployment Describes long-running, scalable, containerize
|
|||
The component definition objects are namespace isolated align with application, while the `vela-system` is a common system namespace of KubeVela,
|
||||
definitions laid here can be used by every application.
|
||||
|
||||
You can use [vela kubectl plugin](./kubectlplugin) to view the detail usage of specific component definition.
|
||||
|
||||
```shell
|
||||
$ kubectl vela show webservice
|
||||
|
|
@ -1,8 +1,8 @@
|
|||
---
|
||||
title: Debug and Test
|
||||
title: Dry-Run and Live-Diff
|
||||
---
|
||||
|
||||
You can make further debug and test for your application by using [vela kubectl plugin](./kubectlplugin).
|
||||
KubeVela allows you to dry-run and live-diff your application.
|
||||
|
||||
## Dry-Run the `Application`
|
||||
|
||||
|
|
@ -4,15 +4,8 @@ title: Define Application Health Probe
|
|||
|
||||
In this documentation, we will show how to define health probe for application
|
||||
|
||||
## Set Health Check Rule
|
||||
1.Create health scope instance.
|
||||
|
||||
Basically you can set application `spec.status.healthPolicy` field to specifying health check rule for application. [reference](../cue/status)
|
||||
|
||||
## Advanced Health Probe
|
||||
|
||||
By using HealthyScope you can check all pods of workload weather are healthy.
|
||||
|
||||
1.Create health scope by apply this yaml
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1alpha2
|
||||
kind: HealthScope
|
||||
|
|
@ -6,7 +6,6 @@ title: Expose Application
|
|||
|
||||
To expose your application publicly, you just need to add an `ingress` trait.
|
||||
|
||||
View ingress schema by [vela kubectl plugin](./kubectlplugin).
|
||||
|
||||
```shell
|
||||
$ kubectl vela show ingress
|
||||
|
|
@ -346,4 +346,4 @@ spec:
|
|||
...
|
||||
```
|
||||
|
||||
你可以通过查看 [the end user usage workflow](../end-user/cloud-resources) 了解其使用方式。
|
||||
你可以通过查看 [the end user usage workflow](../end-user/components/cloud-services) 了解其使用方式。
|
||||
|
|
@ -20,7 +20,6 @@ KubeVela 将 CUE 作为抽象最优方案的主要原因如下：
|
|||
|
||||
请确保你的环境中已经安装如下命令行：
|
||||
* [`cue` >=v0.2.2](https://cuelang.org/docs/install/)
|
||||
* [`vela` (>v1.0.0)](../install#4-optional-get-kubevela-cli)
|
||||
|
||||
## CUE 命令行基础
|
||||
|
||||
|
|
@ -4,7 +4,7 @@ title: How-to
|
|||
|
||||
In this section, it will introduce how to use [CUE](https://cuelang.org/) to declare app components via `ComponentDefinition`.
|
||||
|
||||
> Before reading this part, please make sure you've learned the [Definition CRD](../platform-engineers/definition-and-templates) in KubeVela.
|
||||
> Before reading this part, please make sure you've learned the [Definition CRD](../definition-and-templates) in KubeVela.
|
||||
|
||||
## Declare `ComponentDefinition`
|
||||
|
||||
|
|
@ -8,8 +8,6 @@ title: 调试， 测试 以及 Dry-run
|
|||
|
||||
请确保你的环境已经安装以下 CLI ：
|
||||
* [`cue` >=v0.2.2](https://cuelang.org/docs/install/)
|
||||
* [`vela` (>v1.0.0)](../install#4-optional-get-kubevela-cli)
|
||||
|
||||
|
||||
## 定义 Definition 和 Template
|
||||
|
||||
|
|
|
|||
|
|
@ -4,11 +4,11 @@ title: How-to
|
|||
|
||||
In this section, it will introduce how to declare Helm charts as app components via `ComponentDefinition`.
|
||||
|
||||
> Before reading this part, please make sure you've learned [the definition and template concepts](../platform-engineers/definition-and-templates).
|
||||
> Before reading this part, please make sure you've learned [the definition and template concepts](../definition-and-templates).
|
||||
|
||||
## Prerequisite
|
||||
|
||||
* [fluxcd/flux2](../install#3-optional-install-flux2), make sure you have installed the flux2 in the [installation guide](/docs/install).
|
||||
* [fluxcd/flux2](../../install#3-optional-install-flux2), make sure you have installed the flux2 in the [installation guide](/docs/install).
|
||||
|
||||
## Declare `ComponentDefinition`
|
||||
|
||||
|
|
@ -2,7 +2,7 @@
|
|||
title: KEDA 作为自动伸缩 Trait
|
||||
---
|
||||
|
||||
> 在继续之前，请确保你已了解 [Definition Objects](definition-and-templates) 和 [Defining Traits with CUE](/docs/cue/trait) 的概念。
|
||||
> 在继续之前，请确保你已了解 [Definition Objects](definition-and-templates) 和 [Defining Traits with CUE](./cue/trait) 的概念。
|
||||
|
||||
在下面的教程中，你将学习将 [KEDA](https://keda.sh/) 作为新的自动伸缩 trait 添加到基于 KubeVela 的平台中。
|
||||
|
||||
|
|
@ -97,7 +97,7 @@ schematic:
|
|||
|
||||
这是一个基于 CUE 的模板，仅开放 `type` 和 `value` 作为 trait 的属性供用户设置。
|
||||
|
||||
> 请查看 [Defining Trait with CUE](../cue/trait) 部分，以获取有关 CUE 模板的更多详细信息。
|
||||
> 请查看 [Defining Trait with CUE](./cue/trait) 部分，以获取有关 CUE 模板的更多详细信息。
|
||||
|
||||
## 步骤 2: 向 KubeVela 注册新的 Trait
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ title: How-to
|
|||
|
||||
In this section, it will introduce how to use raw K8s Object to declare app components via `ComponentDefinition`.
|
||||
|
||||
> Before reading this part, please make sure you've learned [the definition and template concepts](../platform-engineers/definition-and-templates).
|
||||
> Before reading this part, please make sure you've learned [the definition and template concepts](../definition-and-templates).
|
||||
|
||||
## Declare `ComponentDefinition`
|
||||
|
||||
|
|
@ -48,8 +48,8 @@ data:
|
|||
|
||||
具体来说，该 schema 是根据capability 定义中的 `parameter` 部分生成的：
|
||||
|
||||
* 对于基于 CUE 的定义：[`parameter`](../cue/component#Write-ComponentDefinition) CUE 模板中的关键词。
|
||||
* 对于基于 Helm 的定义：[`parameter`](../helm/component#Write-ComponentDefinition) 是从在 Helm Chart 中的 `values.yaml` 生成的。
|
||||
* 对于基于 CUE 的定义：`parameter` CUE 模板中的关键词。
|
||||
* 对于基于 Helm 的定义：`parameter` 是从在 Helm Chart 中的 `values.yaml` 生成的。
|
||||
|
||||
## 渲染表单
|
||||
|
||||
|
|
|
|||
|
|
@ -91,7 +91,7 @@ Hello World
|
|||
以下是一些推荐的后续步骤:
|
||||
|
||||
- 从[核心概念](./concepts)开始学习 KubeVela
|
||||
- 了解更多[`Application`](./application)的细节并且理解其是如何工作的。
|
||||
- 了解更多[`Application`](end-user/application)的细节并且理解其是如何工作的。
|
||||
- 加入CNCF [Slack](https://cloud-native.slack.com) 中的`#kubevela` channel 和 [Gitter](https://gitter.im/oam-dev/community)
|
||||
- 加入 KubeVela 中文社区钉钉群。钉钉群号：23310022。
|
||||
|
||||
|
|
|
|||
|
|
@ -1,266 +0,0 @@
|
|||
---
|
||||
title: Progressive Rollout
|
||||
---
|
||||
|
||||
在任何应用中，灰度发布、或者说应用升级，都是应用部署完成以后最主要的运维事项之一。KubeVela 作为“以应用为中心”的平台，旨在提供定制的解决方案来减轻应用运维人员的负担。
|
||||
|
||||
## 概述
|
||||
|
||||
在云原生社区中，有几种尝试解决渐进式灰度发布问题的尝试。但是没有一种提供了真正的滚动式升级。例如，flagger 只支持蓝绿发布，金丝雀发布 和 A/B 测试等模式。因此，我们决定把对基于批处理的滚动升级功能作为我们在KubeVela 中支持的第一种模式。
|
||||
|
||||
### 设计原则和目标
|
||||
|
||||
我们在设计 KubeVela 的 rollout 解决方案时会始终保证以下原则：
|
||||
|
||||
- 第一，我们希望所有类型的 rollout controllers 共享相同的核心 rollout 相关逻辑。Trait 和 应用相关的逻辑可以很轻松地把它们封装到其自己的代码包里。
|
||||
- 第二，rollout 的核心逻辑应该能够通过非常简单的扩展就能做到支持不同类型的工作负载，比如 Deployment，CloneSet，Statefulset，DaemonSet，或甚至是自定义的工作负载。
|
||||
- 第三，rollout 的核心逻辑应当包含一个具有完备文档的状态机，其中的每一步状态转换都应当是明确的。
|
||||
- 第四，这些 rollout controllers 可以支持应用在生产环境灰度发布/升级所需的所有场景，包括蓝绿发布，金丝雀发布 和 A/B 测试等模式。
|
||||
|
||||
## AppRollout 示例
|
||||
|
||||
这里是一个简单的 `AppRollout` 的示例，它分三个批次（batch）把一个应用从 v1 升级到 v2。第一个批次只升级 1 个 pod，然后剩下的批次平分剩下的实例。
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: AppRollout
|
||||
metadata:
|
||||
name: rolling-example
|
||||
spec:
|
||||
sourceAppRevisionName: test-rolling-v1
|
||||
targetAppRevisionName: test-rolling-v2
|
||||
componentList:
|
||||
- metrics-provider
|
||||
rolloutPlan:
|
||||
rolloutStrategy: "IncreaseFirst"
|
||||
rolloutBatches:
|
||||
- replicas: 1
|
||||
- replicas: 50%
|
||||
- replicas: 50%
|
||||
batchPartition: 1
|
||||
```
|
||||
|
||||
## 用户体验工作流
|
||||
|
||||
这里是一个基于 [CloneSet](https://openkruise.io/en-us/docs/cloneset.html) 的端到端的用户体验
|
||||
|
||||
1. 安装 CloneSet 并为其创建一个 `ComponentDefinition`。
|
||||
|
||||
```shell
|
||||
helm install kruise https://github.com/openkruise/kruise/releases/download/v0.7.0/kruise-chart.tgz
|
||||
```
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: ComponentDefinition
|
||||
metadata:
|
||||
name: clonesetservice
|
||||
namespace: vela-system
|
||||
annotations:
|
||||
definition.oam.dev/description: "Describes long-running, scalable, containerized services that have a stable network endpoint to receive external network traffic from customers.
|
||||
If workload type is skipped for any service defined in Appfile, it will be defaulted to `webservice` type."
|
||||
spec:
|
||||
workload:
|
||||
definition:
|
||||
apiVersion: apps.kruise.io/v1alpha1
|
||||
kind: CloneSet
|
||||
schematic:
|
||||
cue:
|
||||
template: |
|
||||
output: {
|
||||
apiVersion: "apps.kruise.io/v1alpha1"
|
||||
kind: "CloneSet"
|
||||
metadata: labels: {
|
||||
"app.oam.dev/component": context.name
|
||||
}
|
||||
spec: {
|
||||
if parameter["replicas"] != _|_ {
|
||||
replicas: parameter.replicas
|
||||
}
|
||||
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
|
||||
}
|
||||
|
||||
if parameter["env"] != _|_ {
|
||||
env: parameter.env
|
||||
}
|
||||
|
||||
if context["config"] != _|_ {
|
||||
env: context.config
|
||||
}
|
||||
|
||||
ports: [{
|
||||
containerPort: parameter.port
|
||||
}]
|
||||
|
||||
if parameter["cpu"] != _|_ {
|
||||
resources: {
|
||||
limits:
|
||||
cpu: parameter.cpu
|
||||
requests:
|
||||
cpu: parameter.cpu
|
||||
}
|
||||
}
|
||||
}]
|
||||
}
|
||||
}
|
||||
if parameter["updateStrategyType"] != _|_ {
|
||||
updateStrategy: {
|
||||
type: parameter.updateStrategyType
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
parameter: {
|
||||
// +usage=Which image would you like to use for your service
|
||||
// +short=i
|
||||
image: string
|
||||
|
||||
// +usage=Commands to run in the container
|
||||
cmd?: [...string]
|
||||
|
||||
// +usage=Which port do you want customer traffic sent to
|
||||
// +short=p
|
||||
port: *80 | int
|
||||
// +usage=Define arguments by using environment variables
|
||||
env?: [...{
|
||||
// +usage=Environment variable name
|
||||
name: string
|
||||
// +usage=The value of the environment variable
|
||||
value?: string
|
||||
// +usage=Specifies a source the value of this var should come from
|
||||
valueFrom?: {
|
||||
// +usage=Selects a key of a secret in the pod's namespace
|
||||
secretKeyRef: {
|
||||
// +usage=The name of the secret in the pod's namespace to select from
|
||||
name: string
|
||||
// +usage=The key of the secret to select from. Must be a valid secret key
|
||||
key: string
|
||||
}
|
||||
}
|
||||
}]
|
||||
// +usage=Number of CPU units for the service, like `0.5` (0.5 CPU core), `1` (1 CPU core)
|
||||
cpu?: string
|
||||
// +usage=Cloneset updateStrategy, candidates are `ReCreate`/`InPlaceIfPossible`/`InPlaceOnly`
|
||||
updateStrategyType?: string
|
||||
// +usage=Number of pods in the cloneset
|
||||
replicas?: int
|
||||
}
|
||||
```
|
||||
|
||||
2. 部署一个应用到集群
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: test-rolling
|
||||
annotations:
|
||||
"app.oam.dev/rolling-components": "metrics-provider"
|
||||
"app.oam.dev/rollout-template": "true"
|
||||
spec:
|
||||
components:
|
||||
- name: metrics-provider
|
||||
type: clonesetservice
|
||||
properties:
|
||||
cmd:
|
||||
- ./podinfo
|
||||
- stress-cpu=1
|
||||
image: stefanprodan/podinfo:4.0.6
|
||||
port: 8080
|
||||
updateStrategyType: InPlaceIfPossible
|
||||
replicas: 5
|
||||
```
|
||||
|
||||
3. 使用下面的 rollout 来升级应用到 v1
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: AppRollout
|
||||
metadata:
|
||||
name: rolling-example
|
||||
spec:
|
||||
# application (revision) reference
|
||||
targetAppRevisionName: test-rolling-v1
|
||||
componentList:
|
||||
- metrics-provider
|
||||
rolloutPlan:
|
||||
rolloutStrategy: "IncreaseFirst"
|
||||
rolloutBatches:
|
||||
- replicas: 10%
|
||||
- replicas: 40%
|
||||
- replicas: 50%
|
||||
```
|
||||
|
||||
用户可以查看 ApplicationRollout 的状态并等待 rollout 完成。
|
||||
|
||||
4. 用户可以继续修改应用镜像标签并部署。
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: test-rolling
|
||||
annotations:
|
||||
"app.oam.dev/rolling-components": "metrics-provider"
|
||||
"app.oam.dev/rollout-template": "true"
|
||||
spec:
|
||||
components:
|
||||
- name: metrics-provider
|
||||
type: clonesetservice
|
||||
properties:
|
||||
cmd:
|
||||
- ./podinfo
|
||||
- stress-cpu=1
|
||||
image: stefanprodan/podinfo:5.0.2
|
||||
port: 8080
|
||||
updateStrategyType: InPlaceIfPossible
|
||||
replicas: 5
|
||||
```
|
||||
|
||||
5. 使用应用 rollout 把应用从 v1 升级到 v2
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: AppRollout
|
||||
metadata:
|
||||
name: rolling-example
|
||||
spec:
|
||||
# application (revision) reference
|
||||
sourceAppRevisionName: test-rolling-v1
|
||||
targetAppRevisionName: test-rolling-v2
|
||||
componentList:
|
||||
- metrics-provider
|
||||
rolloutPlan:
|
||||
rolloutStrategy: "IncreaseFirst"
|
||||
rolloutBatches:
|
||||
- replicas: 1
|
||||
- replicas: 2
|
||||
- replicas: 2
|
||||
```
|
||||
|
||||
用户可以检查 ApplicationRollout 的状态并看到 rollout 完成了。此时 ApplicationRollout 的 `Rolling State` 变成了`rolloutSucceed`。
|
||||
|
||||
## 状态转移
|
||||
|
||||
下图是更高层面的状态转移图
|
||||
|
||||
|
||||
|
||||
## Roadmap
|
||||
|
||||
Our recent roadmap for progressive rollout is [here](./roadmap).
|
||||
Loading…
Reference in New Issue