Feat: add high Availability doc (#1063)
Signed-off-by: Jianbo Sun <jianbo.sjb@alibaba-inc.com> Signed-off-by: Jianbo Sun <jianbo.sjb@alibaba-inc.com>
This commit is contained in:
Jianbo Sun
GitHub
parent
1f89fc0602
commit
a7ce475ce6
|
|
@ -0,0 +1,46 @@
|
|||
---
|
||||
title: High Availability
|
||||
---
|
||||
|
||||
If you're using KubeVela in production, make sure they're deployed in high availability mode like the architecture below.
|
||||
|
||||
|
||||
|
||||
|
||||
## KubeVela Core Controller
|
||||
|
||||
:::note
|
||||
First of all, please make sure you have a high availability Kubernetes cluster for all the control plane components.
|
||||
:::
|
||||
|
||||
KubeVela core controller is a standard Kubernetes CRD controller, it uses a master-slave mode for high availability. When set for more than one replicas, it will trigger leader election and make one replica as the master.
|
||||
|
||||
The recommend installation is:
|
||||
|
||||
```
|
||||
helm install --create-namespace -n vela-system kubevela kubevela/vela-core --set replicaCount=3 --wait
|
||||
```
|
||||
|
||||
If you have already installed, you can scale up with the command:
|
||||
|
||||
```
|
||||
kubectl scale deploy -n vela-system kubevela-vela-core --replicas=3
|
||||
```
|
||||
|
||||
## Cluster Gateway
|
||||
|
||||
The cluster gateway is a stateless component, it installed along with KubeVela core by default. You can scale it up when needed by:
|
||||
|
||||
```
|
||||
kubectl scale deploy -n vela-system kubevela-cluster-gateway --replicas=3
|
||||
```
|
||||
|
||||
## VelaUX
|
||||
|
||||
VelaUX is an addon, it composed by 3 major parts: nginx for frontend, APIServer as backend, and its database.
|
||||
|
||||
We strongly recommend to use high availability mongodb cluster as the database driver. The frontend and backend are both stateless services, just configure multiple replicas for them. As a result, the high availability installation command just like below:
|
||||
|
||||
```
|
||||
vela addon enable velaux dbType=mongodb dbURL=mongodb://<MONGODB_USER>:<MONGODB_PASSWORD>@<MONGODB_URL> replicas=3
|
||||
```
|
||||
|
|
@ -23,19 +23,19 @@ kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/release-1.6/
|
|||
```
|
||||
helm repo add kubevela https://charts.kubevela.net/core
|
||||
helm repo update
|
||||
helm upgrade -n vela-system --install kubevela kubevela/vela-core --version 1.6.0 --wait
|
||||
helm upgrade -n vela-system --install kubevela kubevela/vela-core --version 1.6.1 --wait
|
||||
```
|
||||
|
||||
3. Download and upgrade to the corresponding CLI
|
||||
|
||||
```
|
||||
curl -fsSl https://kubevela.io/script/install.sh | bash -s 1.6.0
|
||||
curl -fsSl https://kubevela.io/script/install.sh | bash -s 1.6.1
|
||||
```
|
||||
|
||||
4. Upgrade VelaUX or other addon
|
||||
|
||||
```
|
||||
vela addon upgrade velaux --version 1.6.0
|
||||
vela addon upgrade velaux --version 1.6.1
|
||||
```
|
||||
|
||||
## From v1.4.x to v1.5.x
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 285 KiB |
|
|
@ -26,7 +26,7 @@ module.exports = {
|
|||
id: 'start',
|
||||
content:
|
||||
'<div class="header-item">⭐️ If you like KubeVela, give it a star on <a target="_blank" rel="noopener noreferrer" href="https://github.com/kubevela/kubevela">GitHub</a>!⭐️</div>' +
|
||||
'<div class="header-item"><span>KubeVela v1.6.0 is now available.(2022-11-02)</span> <a target="_blank" style="color: var(--ifm-color-primary)" rel="noopener noreferrer" href="https://github.com/kubevela/kubevela/releases/v1.6.0">Read Release Note</a></div>',
|
||||
'<div class="header-item"><span>KubeVela v1.6.1 is now available.(2022-11-09)</span> <a target="_blank" style="color: var(--ifm-color-primary)" rel="noopener noreferrer" href="https://github.com/kubevela/kubevela/releases/v1.6.1">Read Release Note</a></div>',
|
||||
},
|
||||
algolia: {
|
||||
appId: 'PXMFHFWUGZ',
|
||||
|
|
|
|||
|
|
@ -0,0 +1,460 @@
|
|||
---
|
||||
title: 流水线的 K8S API
|
||||
---
|
||||
|
||||
独立运行的流水线功能相较于 KubeVela 本身具备的应用级工作流，具有以下特性：
|
||||
|
||||
1. 它可以管理多个 KubeVela 应用，跨多个环境创建。
|
||||
2. 它**不绑定应用**，可以**独立使用**，如针对一组资源做扩缩容，针对一个应用做面向流程的灰度发布，批量执行一组运维操作。
|
||||
3. 它是**一次性**的，不对资源做管理，即使删除流水线也不会删除创建出来的资源。
|
||||
4. 它与应用流水线的执行引擎是同源的，这也完全继承了 KubeVela 轻量级工作流的特性，相较于传统的基于容器的 CI 流水线，KubeVela 的流水线在执行各类资源操作时不依赖容器、无需额外的计算资源。
|
||||
|
||||
:::tip
|
||||
为了更好地复用已有的能力及保证技术一致性，我们将原本应用工作流中的工作流引擎部分进行了拆分。
|
||||
应用内工作流和应用间流水线都使用了这个 [工作流引擎](https://github.com/kubevela/workflow) 作为底层的技术实现。应用工作流体现为应用中的 `Workflow` 字段，而流水线则体现为 [WorkflowRun](https://github.com/kubevela/workflow) 资源。
|
||||
|
||||
这意味着绝大部分工作流步骤在二者间都是通用的，如：暂停，通知，发送 HTTP 请求，读取配置等。
|
||||
|
||||
但 WorkflowRun 中只有步骤的配置，**没有**组件、运维特征、策略的配置。因此，与组件等相关的步骤只能在应用内工作流中使用，如：部署/更新组件、运维特征等。
|
||||
:::
|
||||
|
||||
## WorkflowRun
|
||||
|
||||
WorkflowRun 为流水线执行的 K8S API。你可以选择在 WorkflowRun 里执行一个外部的 Workflow 模板或者执行直接在里面配置要执行的步骤（如果你同时声明了二者，WorkflowRun 里的步骤配置会覆盖模板中的内容）。一个 WorkflowRun 的组成如下：
|
||||
|
||||
```
|
||||
apiVersion: core.oam.dev/v1alpha1
|
||||
kind: WorkflowRun
|
||||
metadata:
|
||||
name: <名称>
|
||||
namespace: <命名空间>
|
||||
spec:
|
||||
mode: <可选项，WorkflowRun 的执行模式，默认步骤的执行模式是 StepByStep，子步骤为 DAG>
|
||||
steps: <DAG 或者 StepByStep>
|
||||
subSteps: <DAG 或者 StepByStep>
|
||||
context:
|
||||
<可选项，自定义上下文参数>
|
||||
workflowRef: <可选项，用于运行的外部 Workflow 模板>
|
||||
workflowSpec: <可选项，用于运行的配置>
|
||||
steps:
|
||||
- name: <名称>
|
||||
type: <类型>
|
||||
dependsOn:
|
||||
<可选项，该步骤需要依赖的步骤名称数组>
|
||||
meta: <可选项，该步骤的额外信息>
|
||||
alias: <可选项，该步骤的别名>
|
||||
properties:
|
||||
<步骤参数值>
|
||||
if: <可选项，用于判断该步骤是否要被执行>
|
||||
timeout: <可选项，该步骤的超时时间>
|
||||
outputs: <可选项，该步骤的输出>
|
||||
- name: <输出名>
|
||||
valueFrom: <输出来源>
|
||||
inputs: <可选项，该步骤的输入>
|
||||
- name: <输入来源名>
|
||||
parameterKey: <可选项，该输入要被设置为步骤的某个参数名>
|
||||
subSteps:
|
||||
<可选项，如果步骤类型为 step-group，可在这里声明子步骤>
|
||||
```
|
||||
|
||||
## 状态
|
||||
|
||||
### WorkflowRun 状态
|
||||
|
||||
WorkflowRun 拥有以下几种状态：
|
||||
|
||||
| WorkflowRun 状态 | 说明 |
|
||||
| :-------: | :-----------------------------------: |
|
||||
| executing | 当 WorkflowRun 中的步骤正在执行时，其状态为 executing |
|
||||
| suspending | 当 WorkflowRun 被暂停时，其状态为 suspending |
|
||||
| terminated | 当 WorkflowRun 被终止时，其状态为 terminated |
|
||||
| failed | 当 WorkflowRun 执行完成，且有步骤失败时，其状态为 failed |
|
||||
| succeeded | 当 WorkflowRun 执行完成，且所有步骤的状态均为成功或者跳过时，其状态为 succeeded |
|
||||
|
||||
### WorkflowRun 步骤状态
|
||||
|
||||
WorkflowRun 步骤拥有以下几种状态：
|
||||
|
||||
| 步骤状态 | 说明 |
|
||||
| :-------: | :-----------------------------------: |
|
||||
| running | 该步骤正在执行 |
|
||||
| succeeded | 该步骤执行完成，且状态为成功 |
|
||||
| failed | 该步骤执行失败 |
|
||||
| skipped | 该步骤被跳过，没有被执行 |
|
||||
| pending | 步骤等待某些条件来执行，如：等待 inputs 的输入 |
|
||||
|
||||
#### WorkflowRun 步骤失败原因
|
||||
|
||||
对于执行失败的步骤，步骤状态的 Message 中会显示报错信息，步骤状态的 Reason 会显示失败原因，分为以下几种：
|
||||
|
||||
| 步骤失败原因 | 说明 |
|
||||
| :-------: | :-----------------------------------: |
|
||||
| Execute | 步骤执行出错 |
|
||||
| Terminate | 步骤被终止 |
|
||||
| Output | 步骤在输出 Output 时出错 |
|
||||
| FailedAfterRetries | 步骤执行失败达到重试上限 |
|
||||
| Timeout | 步骤因超时出错 |
|
||||
| Action | 步骤定义中执行了 [op.#Fail](../../platform-engineers/workflow/cue-actions#fail) |
|
||||
|
||||
## 执行模式
|
||||
|
||||
你可以在 WorkflowRun 或者 Workflow 模板中定义执行模式：
|
||||
|
||||
```
|
||||
mode:
|
||||
steps: <DAG or StepByStep>
|
||||
subSteps: <DAG or StepByStep>
|
||||
```
|
||||
|
||||
如果没有显示指定，默认 WorkflowRun 会以顺序（StepByStep）执行步骤，并行（DAG）执行子步骤的模式来执行。
|
||||
|
||||
:::caution
|
||||
如果你同时在 WorkflowRun 和 Workflow 中指定了执行模式，那么 WorkflowRun 中的模式会覆盖 Workflow 模板中的执行模式。
|
||||
:::
|
||||
|
||||
## 内置步骤
|
||||
|
||||
你可以在 WorkflowRun 中使用**不带有**label: `custom.definition.oam.dev/scope: Application` 的 KubeVela [内置步骤](../workflow/built-in-workflow-defs)。
|
||||
|
||||
## 自定义步骤
|
||||
|
||||
你可以参考 [自定义步骤文档](../../platform-engineers/workflow/workflow) 来自定义你的步骤。
|
||||
|
||||
:::caution
|
||||
在自定义 WorkflowRun 的步骤过程中，你无法使用[对当前应用的操作](../../platform-engineers/workflow/cue-actions#对当前应用的操作)
|
||||
:::
|
||||
|
||||
## 核心功能
|
||||
|
||||
### 操作 WorkflowRun
|
||||
|
||||
:::tip
|
||||
vela workflow 命令可以操作应用内的工作流，也可以操作 WorkflowRun。
|
||||
它默认会先去找同名的应用，如果找不到则会去找 WorkflowRun。
|
||||
你也可以在使用时通过 `--type=workflow` 来表明操作对象为 WorkflowRun。
|
||||
:::
|
||||
|
||||
#### 暂停
|
||||
|
||||
如果你有一个正在执行中的 WorkflowRun，那么，你可以用 `suspend` 命令来暂停这个工作流。
|
||||
|
||||
```bash
|
||||
vela workflow suspend <name>
|
||||
```
|
||||
|
||||
:::tip
|
||||
如果工作流已经执行完毕，使用 `vela workflow suspend` 命令不会产生任何效果。
|
||||
:::
|
||||
|
||||
#### 继续
|
||||
|
||||
当 WorkflowRun 进入暂停状态后，你可以使用 `vela workflow resume` 命令来手动继续工作流。workflow resume 命令会把 WorkflowRun 从暂停状态恢复到执行状态。
|
||||
|
||||
```bash
|
||||
vela workflow resume <name>
|
||||
```
|
||||
|
||||
#### 终止
|
||||
|
||||
当 WorkflowRun 正在执行时，如果你想终止它，你可以使用 `vela workflow terminate` 命令来终止 WorkflowRun。
|
||||
|
||||
```bash
|
||||
vela workflow terminate <name>
|
||||
```
|
||||
|
||||
#### 查看日志
|
||||
|
||||
如果你想查看 WorkflowRun 的日志，你可以使用 `vela workflow logs` 命令来查看日志。
|
||||
|
||||
:::tip
|
||||
只有配置了 [op.#Log](../../platform-engineers/workflow/cue-actions#log) 的步骤才会有日志输出。
|
||||
:::
|
||||
|
||||
```bash
|
||||
vela workflow logs <name>
|
||||
```
|
||||
|
||||
### 暂停和继续
|
||||
|
||||
#### 手动暂停
|
||||
|
||||
参考 [操作 WorkflowRun](#暂停)。
|
||||
|
||||
#### 自动暂停（使用暂停步骤）
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1alpha1
|
||||
kind: WorkflowRun
|
||||
metadata:
|
||||
name: suspend
|
||||
namespace: default
|
||||
spec:
|
||||
workflowSpec:
|
||||
steps:
|
||||
- name: step1
|
||||
type: apply-deployment
|
||||
properties:
|
||||
image: nginx
|
||||
- name: step2-suspend
|
||||
type: suspend
|
||||
- name: step2
|
||||
type: apply-deployment
|
||||
properties:
|
||||
image: nginx
|
||||
```
|
||||
|
||||
WorkflowRun 将在执行完第一个步骤后自动暂停，直至你继续了这个 WorkflowRun，第三个步骤才会被执行。
|
||||
|
||||
#### 手动继续
|
||||
|
||||
参考 [操作 WorkflowRun](#继续)。
|
||||
|
||||
#### 自动继续
|
||||
|
||||
在 `suspend` 类型的步骤中配置 `duration: <duration>`，当 `duration` 时间超过后，WorkflowRun 将自动继续执行。
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1alpha1
|
||||
kind: WorkflowRun
|
||||
metadata:
|
||||
name: suspend
|
||||
namespace: default
|
||||
spec:
|
||||
workflowSpec:
|
||||
steps:
|
||||
- name: step1
|
||||
type: apply-deployment
|
||||
properties:
|
||||
image: nginx
|
||||
- name: step2-suspend
|
||||
type: suspend
|
||||
properties:
|
||||
duration: 10s
|
||||
- name: step2
|
||||
type: apply-deployment
|
||||
properties:
|
||||
image: nginx
|
||||
```
|
||||
|
||||
当第一个步骤执行完成后，WorkflowRun 将进入暂停状态，十秒过后，WorkflowRun 将自动继续执行第三个步骤。
|
||||
|
||||
### 子步骤
|
||||
|
||||
步骤中有一个特殊的步骤类型：`step-group`。在使用步骤组类型的步骤时，你可以在其中声明子步骤。
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1alpha1
|
||||
kind: WorkflowRun
|
||||
metadata:
|
||||
name: group
|
||||
namespace: default
|
||||
spec:
|
||||
workflowSpec:
|
||||
steps:
|
||||
- name: my-group
|
||||
type: step-group
|
||||
subSteps:
|
||||
- name: sub1
|
||||
type: apply-deployment
|
||||
properties:
|
||||
image: nginx
|
||||
- name: sub2
|
||||
type: apply-deployment
|
||||
properties:
|
||||
image: nginx
|
||||
```
|
||||
|
||||
### 依赖关系
|
||||
|
||||
你可以通过 `dependsOn` 来指定步骤之间的依赖关系。
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1alpha1
|
||||
kind: WorkflowRun
|
||||
metadata:
|
||||
name: dependency
|
||||
namespace: default
|
||||
spec:
|
||||
mode:
|
||||
steps: DAG
|
||||
workflowSpec:
|
||||
steps:
|
||||
- name: step1
|
||||
type: apply-deployment
|
||||
dependsOn:
|
||||
- step2
|
||||
- step3
|
||||
properties:
|
||||
image: nginx
|
||||
- name: step2
|
||||
type: apply-deployment
|
||||
properties:
|
||||
image: nginx
|
||||
- name: step3
|
||||
type: apply-deployment
|
||||
properties:
|
||||
image: nginx
|
||||
```
|
||||
|
||||
step1 将在 step2 和 step3 执行完成后执行。
|
||||
|
||||
### 数据传递
|
||||
|
||||
你可以通过 `inputs` 和 `outputs` 完成步骤间的数据传递，具体介绍请参考 [步骤间的输入输出](../workflow/inputs-outputs#outputs)。
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1alpha1
|
||||
kind: WorkflowRun
|
||||
metadata:
|
||||
name: request-http
|
||||
namespace: default
|
||||
spec:
|
||||
workflowSpec:
|
||||
steps:
|
||||
- name: request
|
||||
type: request
|
||||
properties:
|
||||
url: https://api.github.com/repos/kubevela/workflow
|
||||
outputs:
|
||||
- name: stars
|
||||
valueFrom: |
|
||||
import "strconv"
|
||||
"Current star count: " + strconv.FormatInt(response["stargazers_count"], 10)
|
||||
- name: notification
|
||||
type: notification
|
||||
inputs:
|
||||
- from: stars
|
||||
parameterKey: slack.message.text
|
||||
properties:
|
||||
slack:
|
||||
url:
|
||||
value: <your slack url>
|
||||
```
|
||||
|
||||
该 WorkflowRun 中，第一步会去请求 GitHub API，拿到 workflow 仓库的 star 数作为 Output，再在下一步中使用这个 Output 作为 Input，从而将 star 数的信息发送到 Slack。
|
||||
|
||||
### 超时
|
||||
|
||||
你可以为步骤指定 `timeout` 来表示该步骤的超时时间。
|
||||
|
||||
`timeout` 遵循 `duration` 格式，例如 `30s`, `1m` 等。你可以参考 Golang 的 [parseDuration](https://pkg.go.dev/time#ParseDuration)。
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1alpha1
|
||||
kind: WorkflowRun
|
||||
metadata:
|
||||
name: timeout
|
||||
namespace: default
|
||||
spec:
|
||||
workflowSpec:
|
||||
steps:
|
||||
- name: suspend
|
||||
type: suspend
|
||||
timeout: 3s
|
||||
```
|
||||
|
||||
如果上述 WorkflowRun 没有在三秒内被继续执行，那么 suspend 步骤将因超时而失败。
|
||||
|
||||
### 条件判断
|
||||
|
||||
你可以在步骤中使用 `if` 来判断是否执行该步骤。
|
||||
|
||||
#### 不使用 if
|
||||
|
||||
在步骤不指定 if 的情况下，如果步骤之前的步骤执行失败，那么该步骤将被跳过，不会被执行。
|
||||
|
||||
#### if: always
|
||||
|
||||
在步骤中指定 if: always 的情况下，无论步骤之前的步骤是否执行成功，该步骤都会被执行。
|
||||
|
||||
#### 自定义 if
|
||||
|
||||
你也可以编写自己的判断逻辑来确定是否应该执行该步骤。注意： `if` 里的值将作为 CUE 代码执行。WorkflowRun 在 `if` 中提供了一些内置变量，它们是：
|
||||
|
||||
* `status`：status 中包含了所有 WorkflowRun 步骤的状态信息。你可以使用 `status.<step-name>.phase == "succeeded"` 来判断步骤的状态，也可以使用简化方式`status.<step-name>.succeeded` 来进行判断。
|
||||
* `inputs`：inputs 中包含了该步骤的所有 inputs 参数。你可以使用 `inputs.<input-name> == "value"` 来获取判断步骤的输入。
|
||||
* `context`：context 中包含了 WorkflowRun 的所有 context 参数。你可以使用 `context.<context-name> == "value"` 来获取判断 WorkflowRun 的 context。
|
||||
|
||||
:::tip
|
||||
注意，如果你的步骤名、inputs 名或者 context 名并不是一个有效的 CUE 变量名（如：包含 `-`，或者以数字开头等），你可以用如下方式引用：`status["invalid-name"].failed`。
|
||||
:::
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1alpha1
|
||||
kind: WorkflowRun
|
||||
metadata:
|
||||
name: if-condition
|
||||
namespace: default
|
||||
spec:
|
||||
workflowSpec:
|
||||
steps:
|
||||
- name: suspend
|
||||
type: suspend
|
||||
timeout: 3s
|
||||
- name: my-step
|
||||
type: apply-deployment
|
||||
if: status.suspend.failed
|
||||
properties:
|
||||
image: nginx
|
||||
- name: my-step2
|
||||
type: apply-deployment
|
||||
if: status.suspend.succecceed
|
||||
properties:
|
||||
image: busybox
|
||||
```
|
||||
|
||||
上述 WorkflowRun 中，如果 suspend 步骤因超时而失败，那么 my-step 步骤将会被执行，否则 my-step2 步骤将会被执行。
|
||||
|
||||
### 自定义上下文参数
|
||||
|
||||
WorkflowRun 中的步骤拥有一些内置的上下文参数，你也可以在 `context` 中声明你自己的上下文参数。
|
||||
|
||||
:::tip
|
||||
如果你的自定义上下文参数与内置上下文参数重名，那么内置上下文参数将会被自定义参数覆盖。
|
||||
:::
|
||||
|
||||
你可以通过条件判断和自定义参数的结合，来控制 WorkflowRun 在不同情况下的执行。
|
||||
|
||||
```
|
||||
apiVersion: core.oam.dev/v1alpha1
|
||||
kind: WorkflowRun
|
||||
metadata:
|
||||
name: deploy-run
|
||||
namespace: default
|
||||
spec:
|
||||
context:
|
||||
env: test
|
||||
workflowRef: deploy-template
|
||||
|
||||
---
|
||||
apiVersion: core.oam.dev/v1alpha1
|
||||
kind: Workflow
|
||||
metadata:
|
||||
name: deploy-template
|
||||
namespace: default
|
||||
steps:
|
||||
- name: apply
|
||||
type: apply-deployment
|
||||
if: context.env == "dev"
|
||||
properties:
|
||||
image: nginx
|
||||
- name: apply-test
|
||||
type: apply-deployment
|
||||
if: context.env == "test"
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
```
|
||||
|
||||
上述 WorkflowRun 将引用 deploy-template Workflow 作为执行模板，如果 context 中的 env 参数为 dev，那么 apply 步骤将会被执行，否则 apply-test 步骤将会被执行。
|
||||
|
||||
### 内置上下文参数
|
||||
|
||||
WorkflowRun 中的内置上下文参数如下：
|
||||
|
||||
| Context Variable | Description | Type |
|
||||
| :------------------------------: | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :--------: |
|
||||
| `context.name` | WorkflowRun 的名称 | string |
|
||||
| `context.namespace` | WorkflowRun 的命名空间 | string |
|
||||
| `context.stepName` | 当前步骤的名称 | string |
|
||||
| `context.stepSessionID` | 当前步骤的 ID | string |
|
||||
| `context.spanID` | 当前步骤此次执行的 Trace ID | string |
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
const {Component} = require('react');
|
||||
const { Component } = require('react');
|
||||
|
||||
module.exports = {
|
||||
docs: [
|
||||
|
|
@ -214,6 +214,7 @@ module.exports = {
|
|||
'platform-engineers/system-operation/enable-addon-offline',
|
||||
'platform-engineers/system-operation/migration-from-old-version',
|
||||
'platform-engineers/system-operation/system-info-diagnose',
|
||||
'platform-engineers/system-operation/high-availability'
|
||||
],
|
||||
},
|
||||
{
|
||||
|
|
|
|||
|
|
@ -0,0 +1,459 @@
|
|||
---
|
||||
title: K8S API for Pipeline
|
||||
---
|
||||
|
||||
Compared with the Application Workflow, the standalone pipeline has the following characteristics:
|
||||
|
||||
1. It can manage multiple KubeVela Applications across multiple environments.
|
||||
2. It is **not bound** to Applications and can be used **independently**. For example, it can expand or shrink a set of resources, perform process-oriented canary publishing for an Application, and perform a set of operation and maintenance operations in batches.
|
||||
3. It is **one-time** and does not manage resources. Even if the pipeline is deleted, the created resources will not be deleted.
|
||||
4. It uses the same execution engine as the Application Workflow, which completely inherits the features of KubeVela's lightweight workflow. Compared with the traditional container-based CI pipeline, KubeVela's pipeline does not depend on containers, No additional computing resources are required.
|
||||
|
||||
:::tip
|
||||
In order to better reuse the existing capabilities and ensure technical consistency, we split the workflow engine part of the original application workflow. Both in-application workflow and pipeline use this [workflow engine](https://github.com/kubevela/workflow) as the underlying technology implementation. The application workflow is represented by the `Workflow` field in the application, and the pipeline is represented by the [WorkflowRun](https://github.com/kubevela/workflow) resource.
|
||||
|
||||
This means that most of the workflow steps are common between the two, such as: suspend, notification, send HTTP request, read configuration, etc.
|
||||
|
||||
However, in WorkflowRun, there is only the configuration of steps, and **no configuration of components, traits, and policies**. Therefore, steps related to components/traits/policy can only be used in in-app workflows, such as: deploying/updating components, traits, etc.
|
||||
:::
|
||||
|
||||
## WorkflowRun
|
||||
|
||||
WorkflowRun is the K8S API for pipeline. You can choose to execute an external Workflow template in the WorkflowRun or execute the steps in the WorkflowRun spec (if you declare both, the step in the WorkflowRun spec will override the content in the template). A WorkflowRun consists of the following:
|
||||
|
||||
```
|
||||
apiVersion: core.oam.dev/v1alpha1
|
||||
kind: WorkflowRun
|
||||
metadata:
|
||||
name: <name>
|
||||
namespace: <namespace>
|
||||
spec:
|
||||
mode: <optional execute mode for the workflowRun, default execute mode is StepByStep for steps, DAG for subSteps>
|
||||
steps: <DAG or StepByStep>
|
||||
subSteps: <DAG or StepByStep>
|
||||
context:
|
||||
<optional custom contest values>
|
||||
workflowRef: <optional external workflow template to run>
|
||||
workflowSpec: <optional workflow spec to run>
|
||||
steps:
|
||||
- name: <name>
|
||||
type: <type>
|
||||
dependsOn:
|
||||
<optional array of step names, specify the dependency for the step>
|
||||
meta: <optional meta data for the step>
|
||||
alias: <optional alias of the step>
|
||||
properties:
|
||||
<parameter values>
|
||||
if: <optional if condition to decide whether this step should be executed>
|
||||
timeout: <optional timeout for the step>
|
||||
outputs: <optional outputs value>
|
||||
- name: <name>
|
||||
valueFrom: <value source of the output>
|
||||
inputs: <optional inputs value>
|
||||
- name: <name>
|
||||
parameterKey: <optional set the inputs data to the steps'parameter>
|
||||
subSteps:
|
||||
<optional sub steps if the type of this step is step-group>
|
||||
```
|
||||
|
||||
## Status
|
||||
|
||||
### WorkflowRun Status
|
||||
|
||||
WorkflowRun has the following status:
|
||||
|
||||
| WorkflowRun State | Description |
|
||||
| :-------: | :-----------------------------------: |
|
||||
| executing | When a step in a WorkflowRun is executing, its status is executing |
|
||||
| suspending | When a step in a WorkflowRun is suspended, its status is suspending |
|
||||
| terminated | When a WorkflowRun is terminated, its status is terminated |
|
||||
| failed | When the WorkflowRun is executed completely and a step fails, its status is failed |
|
||||
| succeeded | When the WorkflowRun is executed completely and the status of all steps is successful or skipped, its status is succeeded |
|
||||
|
||||
### WorkflowRun Step Status
|
||||
|
||||
WorkflowRun steps have the following status:
|
||||
|
||||
| Step Status | Description |
|
||||
| :-------: | :-----------------------------------: |
|
||||
| running | This step is being executed |
|
||||
| succeeded | The step is executed successfully |
|
||||
| failed | The step failed |
|
||||
| skipped | The step is skipped and not executed |
|
||||
| pending | The step is wait for certain conditions to execute, such as: waiting for the inputs |
|
||||
|
||||
#### The Failed Reason of WorkflowRun Step
|
||||
|
||||
For steps that fail to execute, the `message` of the step status will display the failed message, and the `reason` will display the failed reason, which is divided into the following types:
|
||||
|
||||
| Step Failed Reason | Description |
|
||||
| :-------: | :-----------------------------------: |
|
||||
| Execute | The step fails in execution |
|
||||
| Terminate | The step is terminated |
|
||||
| Output | The step has an error when outputting the Output |
|
||||
| FailedAfterRetries | The Step fails in execution and the retry limit is reached |
|
||||
| Timeout | The step is timeout |
|
||||
| Action | [op.#Fail](../../platform-engineers/workflow/cue-actions#fail) is used in the step's definition |
|
||||
|
||||
## Execution Mode
|
||||
|
||||
You can define execution mode in WorkflowRun or Workflow templates:
|
||||
|
||||
```
|
||||
mode:
|
||||
steps: <DAG or StepByStep>
|
||||
subSteps: <DAG or StepByStep>
|
||||
```
|
||||
|
||||
If not explicitly specified, the WorkflowRun will execute the steps sequentially (StepByStep) and execute sub-steps in parallel (DAG) by default.
|
||||
|
||||
:::caution
|
||||
If you specify the execution mode in both WorkflowRun and Workflow, the mode in WorkflowRun will override the mode in the Workflow template.
|
||||
:::
|
||||
|
||||
## Built-in Steps
|
||||
|
||||
You can use KubeVela [built-in steps](../workflow/built-in-workflow-defs) that without label: `custom.definition.oam.dev/scope: Application` in WorkflowRun.
|
||||
|
||||
## Custom Steps
|
||||
|
||||
You can refer to the [custom steps documentation](../../platform-engineers/workflow/workflow) to customize your steps.
|
||||
|
||||
:::caution
|
||||
You cannot use [application operations](../../platform-engineers/workflow/cue-actions#application-operations).
|
||||
:::
|
||||
|
||||
## Core Features
|
||||
|
||||
### Operate WorkflowRun
|
||||
|
||||
:::tip
|
||||
The vela workflow command can operate both Application Workflow and WorkflowRun.
|
||||
By default, it will look for the application with the same name first, and if it is not found, it will look for WorkflowRun.
|
||||
You can also use `--type=workflow` to indicate that the operation object is WorkflowRun.
|
||||
:::
|
||||
|
||||
#### Suspend
|
||||
|
||||
If you have an executing WorkflowRun, you can use `vela workflow suspend` to suspend the workflow.
|
||||
|
||||
```bash
|
||||
vela workflow suspend <name>
|
||||
```
|
||||
|
||||
:::tip
|
||||
If the workflow has executed completely, using the `vela workflow suspend` command has no effect.
|
||||
:::
|
||||
|
||||
#### Resume
|
||||
|
||||
When the WorkflowRun is suspended, you can use `vela workflow resume` command to manually resume the workflow.
|
||||
|
||||
```bash
|
||||
vela workflow resume <name>
|
||||
```
|
||||
|
||||
#### Terminate
|
||||
|
||||
If you have an executing WorkflowRun, you can use `vela workflow terminate` to terminate the workflow.
|
||||
|
||||
```bash
|
||||
vela workflow terminate <name>
|
||||
```
|
||||
|
||||
#### Check the Logs
|
||||
|
||||
If you want to view the WorkflowRun logs, you can use `vela workflow logs` command to view the logs.
|
||||
|
||||
:::tip
|
||||
Only steps configured with [op.#Log](../../platform-engineers/workflow/cue-actions#log) in its definition will have log output.
|
||||
:::
|
||||
|
||||
```bash
|
||||
vela workflow logs <name>
|
||||
```
|
||||
|
||||
### Suspend and Resume
|
||||
|
||||
#### Suspend Manually
|
||||
|
||||
Please refer to [Operate WorkflowRun](#suspend).
|
||||
|
||||
#### Suspend Automatically（using suspend step）
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1alpha1
|
||||
kind: WorkflowRun
|
||||
metadata:
|
||||
name: suspend
|
||||
namespace: default
|
||||
spec:
|
||||
workflowSpec:
|
||||
steps:
|
||||
- name: step1
|
||||
type: apply-deployment
|
||||
properties:
|
||||
image: nginx
|
||||
- name: step2-suspend
|
||||
type: suspend
|
||||
- name: step2
|
||||
type: apply-deployment
|
||||
properties:
|
||||
image: nginx
|
||||
```
|
||||
|
||||
The WorkflowRun will automatically suspend when the first step is completed, and the third step will not be executed until you continue the WorkflowRun.
|
||||
|
||||
#### Resume Manually
|
||||
|
||||
Please refer to [Operate WorkflowRun](#resume).
|
||||
|
||||
#### Resume Automatically
|
||||
|
||||
Configure `duration: <duration>` in the `suspend` type of step, when the `duration` time expires, WorkflowRun will automatically continue to execute.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1alpha1
|
||||
kind: WorkflowRun
|
||||
metadata:
|
||||
name: suspend
|
||||
namespace: default
|
||||
spec:
|
||||
workflowSpec:
|
||||
steps:
|
||||
- name: step1
|
||||
type: apply-deployment
|
||||
properties:
|
||||
image: nginx
|
||||
- name: step2-suspend
|
||||
type: suspend
|
||||
properties:
|
||||
duration: 10s
|
||||
- name: step2
|
||||
type: apply-deployment
|
||||
properties:
|
||||
image: nginx
|
||||
```
|
||||
|
||||
When the first step is completed, the WorkflowRun will suspend, and after ten seconds, the WorkflowRun will automatically continue to execute the third step.
|
||||
|
||||
### Sub Steps
|
||||
|
||||
There is a special step type called `step-group`. When using a `step-group` type of step, you can declare sub steps in it.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1alpha1
|
||||
kind: WorkflowRun
|
||||
metadata:
|
||||
name: group
|
||||
namespace: default
|
||||
spec:
|
||||
workflowSpec:
|
||||
steps:
|
||||
- name: my-group
|
||||
type: step-group
|
||||
subSteps:
|
||||
- name: sub1
|
||||
type: apply-deployment
|
||||
properties:
|
||||
image: nginx
|
||||
- name: sub2
|
||||
type: apply-deployment
|
||||
properties:
|
||||
image: nginx
|
||||
```
|
||||
|
||||
### Dependency
|
||||
|
||||
You can specify dependencies between steps with `dependsOn`.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1alpha1
|
||||
kind: WorkflowRun
|
||||
metadata:
|
||||
name: dependency
|
||||
namespace: default
|
||||
spec:
|
||||
mode:
|
||||
steps: DAG
|
||||
workflowSpec:
|
||||
steps:
|
||||
- name: step1
|
||||
type: apply-deployment
|
||||
dependsOn:
|
||||
- step2
|
||||
- step3
|
||||
properties:
|
||||
image: nginx
|
||||
- name: step2
|
||||
type: apply-deployment
|
||||
properties:
|
||||
image: nginx
|
||||
- name: step3
|
||||
type: apply-deployment
|
||||
properties:
|
||||
image: nginx
|
||||
```
|
||||
|
||||
step1 will be executed after step2 and step3 are completed.
|
||||
|
||||
### Data Passing
|
||||
|
||||
Data passing between steps can be done through `inputs` and `outputs`. For details, please refer to [Input and output between steps](../workflow/inputs-outputs#outputs).
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1alpha1
|
||||
kind: WorkflowRun
|
||||
metadata:
|
||||
name: request-http
|
||||
namespace: default
|
||||
spec:
|
||||
workflowSpec:
|
||||
steps:
|
||||
- name: request
|
||||
type: request
|
||||
properties:
|
||||
url: https://api.github.com/repos/kubevela/workflow
|
||||
outputs:
|
||||
- name: stars
|
||||
valueFrom: |
|
||||
import "strconv"
|
||||
"Current star count: " + strconv.FormatInt(response["stargazers_count"], 10)
|
||||
- name: notification
|
||||
type: notification
|
||||
inputs:
|
||||
- from: stars
|
||||
parameterKey: slack.message.text
|
||||
properties:
|
||||
slack:
|
||||
url:
|
||||
value: <your slack url>
|
||||
```
|
||||
|
||||
In this WorkflowRun, the first step will request the GitHub API to get the number of stars in the workflow repository as Output, and then use this Output as Input in the next step to send the star number as the message to Slack.
|
||||
|
||||
### Timeout
|
||||
|
||||
You can specify `timeout` for a step to indicate the timeout for that step.
|
||||
|
||||
`timeout` follows the `duration` format, e.g. `30s`, `1m`, etc. You can refer to Golang's [parseDuration](https://pkg.go.dev/time#ParseDuration).
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1alpha1
|
||||
kind: WorkflowRun
|
||||
metadata:
|
||||
name: timeout
|
||||
namespace: default
|
||||
spec:
|
||||
workflowSpec:
|
||||
steps:
|
||||
- name: suspend
|
||||
type: suspend
|
||||
timeout: 3s
|
||||
```
|
||||
|
||||
If the above WorkflowRun is not resumed within three seconds, the suspend step will fail with timeout.
|
||||
|
||||
### If Conditions
|
||||
|
||||
You can use `if` in a step to determine whether to execute the step.
|
||||
|
||||
#### No If specified
|
||||
|
||||
If the step does not specify `if`, if the step before the step fails to execute, then the step will be skipped and will not be executed.
|
||||
|
||||
#### if: always
|
||||
|
||||
With `if: always` specified in a step, the step will be executed no matter what.
|
||||
|
||||
#### Custom If
|
||||
|
||||
You can also write your own judgment logic to determine whether the step should be executed. Note: The value in `if` will be executed as CUE code. WorkflowRun provides some built-in variables in `if`, these are:
|
||||
|
||||
* `status`：`status` contains status information for all workflow steps. You can use `status.<step-name>.phase == "succeeded"` to determine the status of a step, or you can use the simplified `status.<step-name>.succeeded` to determine.
|
||||
* `inputs`：`inputs` contains all the inputs parameters of the step. You can use `inputs.<input-name> == "value"` to get input for the step.
|
||||
* `context`: `context` contains all the context data of WorkflowRun. You can use `context.<context-name> == "value"` to get the context of the WorkflowRun.
|
||||
|
||||
:::tip
|
||||
Note that if your step name or inputs name is not a valid CUE variable name (eg: contains `-`, or starts with a number, etc.), you can refer to it as follows: `status["invalid-name"].failed`.
|
||||
:::
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1alpha1
|
||||
kind: WorkflowRun
|
||||
metadata:
|
||||
name: if-condition
|
||||
namespace: default
|
||||
spec:
|
||||
workflowSpec:
|
||||
steps:
|
||||
- name: suspend
|
||||
type: suspend
|
||||
timeout: 3s
|
||||
- name: my-step
|
||||
type: apply-deployment
|
||||
if: status.suspend.failed
|
||||
properties:
|
||||
image: nginx
|
||||
- name: my-step2
|
||||
type: apply-deployment
|
||||
if: status.suspend.succecceed
|
||||
properties:
|
||||
image: busybox
|
||||
```
|
||||
|
||||
In the above WorkflowRun, if the suspend step fails due to a timeout, then the my-step step will be executed, otherwise the my-step2 step will be executed.
|
||||
|
||||
### Custom Context Data
|
||||
|
||||
Steps in WorkflowRun have some built-in context data, and you can also declare your custom context parameters in `context`.
|
||||
|
||||
:::tip
|
||||
If your custom context data has the same name as a built-in context data, the built-in context parameter will be overridden by the custom parameter.
|
||||
:::
|
||||
|
||||
You can control the execution of WorkflowRun in different situations through the combination of conditional if and custom data.
|
||||
|
||||
```
|
||||
apiVersion: core.oam.dev/v1alpha1
|
||||
kind: WorkflowRun
|
||||
metadata:
|
||||
name: deploy-run
|
||||
namespace: default
|
||||
spec:
|
||||
context:
|
||||
env: test
|
||||
workflowRef: deploy-template
|
||||
|
||||
---
|
||||
apiVersion: core.oam.dev/v1alpha1
|
||||
kind: Workflow
|
||||
metadata:
|
||||
name: deploy-template
|
||||
namespace: default
|
||||
steps:
|
||||
- name: apply
|
||||
type: apply-deployment
|
||||
if: context.env == "dev"
|
||||
properties:
|
||||
image: nginx
|
||||
- name: apply-test
|
||||
type: apply-deployment
|
||||
if: context.env == "test"
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
```
|
||||
|
||||
The above WorkflowRun will refer to the `deploy-template` Workflow as the execution template. If the `env` in the context is `dev`, then the apply step will be executed, otherwise the apply-test step will be executed.
|
||||
|
||||
### Built-in Context Data
|
||||
|
||||
The built-in context data in WorkflowRun are as follows:
|
||||
|
||||
| Context Variable | Description | Type |
|
||||
| :------------------------------: | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------: | :--------: |
|
||||
| `context.name` | The name of the WorkflowRun | string |
|
||||
| `context.namespace` | The namespace of the WorkflowRun | string |
|
||||
| `context.stepName` | The name of the current step | string |
|
||||
| `context.stepSessionID` | The ID of the current step | string |
|
||||
| `context.spanID` | The trace ID of current step in this reconcile | string |
|
||||
|
|
@ -0,0 +1,46 @@
|
|||
---
|
||||
title: High Availability
|
||||
---
|
||||
|
||||
If you're using KubeVela in production, make sure they're deployed in high availability mode like the architecture below.
|
||||
|
||||
|
||||
|
||||
|
||||
## KubeVela Core Controller
|
||||
|
||||
:::note
|
||||
First of all, please make sure you have a high availability Kubernetes cluster for all the control plane components.
|
||||
:::
|
||||
|
||||
KubeVela core controller is a standard Kubernetes CRD controller, it uses a master-slave mode for high availability. When set for more than one replicas, it will trigger leader election and make one replica as the master.
|
||||
|
||||
The recommend installation is:
|
||||
|
||||
```
|
||||
helm install --create-namespace -n vela-system kubevela kubevela/vela-core --set replicaCount=3 --wait
|
||||
```
|
||||
|
||||
If you have already installed, you can scale up with the command:
|
||||
|
||||
```
|
||||
kubectl scale deploy -n vela-system kubevela-vela-core --replicas=3
|
||||
```
|
||||
|
||||
## Cluster Gateway
|
||||
|
||||
The cluster gateway is a stateless component, it installed along with KubeVela core by default. You can scale it up when needed by:
|
||||
|
||||
```
|
||||
kubectl scale deploy -n vela-system kubevela-cluster-gateway --replicas=3
|
||||
```
|
||||
|
||||
## VelaUX
|
||||
|
||||
VelaUX is an addon, it composed by 3 major parts: nginx for frontend, APIServer as backend, and its database.
|
||||
|
||||
We strongly recommend to use high availability mongodb cluster as the database driver. The frontend and backend are both stateless services, just configure multiple replicas for them. As a result, the high availability installation command just like below:
|
||||
|
||||
```
|
||||
vela addon enable velaux dbType=mongodb dbURL=mongodb://<MONGODB_USER>:<MONGODB_PASSWORD>@<MONGODB_URL> replicas=3
|
||||
```
|
||||
|
|
@ -23,19 +23,19 @@ kubectl apply -f https://raw.githubusercontent.com/oam-dev/kubevela/release-1.6/
|
|||
```
|
||||
helm repo add kubevela https://charts.kubevela.net/core
|
||||
helm repo update
|
||||
helm upgrade -n vela-system --install kubevela kubevela/vela-core --version 1.6.0 --wait
|
||||
helm upgrade -n vela-system --install kubevela kubevela/vela-core --version 1.6.1 --wait
|
||||
```
|
||||
|
||||
3. Download and upgrade to the corresponding CLI
|
||||
|
||||
```
|
||||
curl -fsSl https://kubevela.io/script/install.sh | bash -s 1.6.0
|
||||
curl -fsSl https://kubevela.io/script/install.sh | bash -s 1.6.1
|
||||
```
|
||||
|
||||
4. Upgrade VelaUX or other addon
|
||||
|
||||
```
|
||||
vela addon upgrade velaux --version 1.6.0
|
||||
vela addon upgrade velaux --version 1.6.1
|
||||
```
|
||||
|
||||
## From v1.4.x to v1.5.x
|
||||
|
|
|
|||
|
|
@ -67,6 +67,53 @@ fail: op.#Fail & {
|
|||
}
|
||||
```
|
||||
|
||||
## Data Control
|
||||
|
||||
### Log
|
||||
|
||||
Output the log or configure the log source for this step. If `op.#Log` is used in a step definition, then you can use `vela workflow logs <name>` to view the log for that step.
|
||||
|
||||
**Parameters**
|
||||
|
||||
```
|
||||
#Log: {
|
||||
// +usage=The data to print in the controller logs
|
||||
data?: {...} | string
|
||||
// +usage=The log level of the data
|
||||
level: *3 | int
|
||||
// +usage=The log source of this step. You can specify it from a url or resources. Note that if you set source in multiple op.#Log, only the latest one will work
|
||||
source?: close({
|
||||
// +usage=Specify the log source url of this step
|
||||
url: string
|
||||
}) | close({
|
||||
// +usage=Specify the log resources of this step
|
||||
resources?: [...{
|
||||
// +usage=Specify the name of the resource
|
||||
name?: string
|
||||
// +usage=Specify the cluster of the resource
|
||||
cluster?: string
|
||||
// +usage=Specify the namespace of the resource
|
||||
namespace?: string
|
||||
// +usage=Specify the label selector of the resource
|
||||
labelSelector?: {...}
|
||||
}]
|
||||
})
|
||||
}
|
||||
```
|
||||
|
||||
**Example**
|
||||
|
||||
```
|
||||
import "vela/op"
|
||||
|
||||
myLog: op.#Log & {
|
||||
data: "my custom log"
|
||||
resources: [{
|
||||
labelsSelector: {"test-key": "test-value"}
|
||||
}]
|
||||
}
|
||||
```
|
||||
|
||||
### Message
|
||||
|
||||
Write message to the workflow step status.
|
||||
|
|
@ -80,6 +127,16 @@ Write message to the workflow step status.
|
|||
}
|
||||
```
|
||||
|
||||
**Example**
|
||||
|
||||
```
|
||||
import "vela/op"
|
||||
|
||||
msg: op.#Message & {
|
||||
message: "custom message"
|
||||
}
|
||||
```
|
||||
|
||||
### DoVar
|
||||
|
||||
Used to save or read user-defined data in the context of workflow.
|
||||
|
|
|
|||
|
|
@ -245,7 +245,7 @@ In a workflow step definition, you can use the following context data:
|
|||
| `context.appRevision` | The revision of the Application. | string |
|
||||
| `context.stepName` | The name of current step. | string |
|
||||
| `context.stepSessionID` | The ID of current step. | string |
|
||||
| `context.spanID` | The trace ID of current step in this reconcile. ID | string |
|
||||
| `context.spanID` | The trace ID of current step in this reconcile. | string |
|
||||
| `context.workflowName` | The workflow name specified in annotation. | string |
|
||||
| `context.publishVersion` | The version of application instance specified in annotation. | string |
|
||||
|
||||
|
|
|
|||
|
|
@ -47,8 +47,8 @@ The following definitions will be enabled after the installation of fluxcd addon
|
|||
| values | optional, override the Values.yaml inchart, using for the rendering of Helm | |
|
||||
| installTimeout | optional, the timeout for operation `helm install`, and 10 minutes by default | 20m |
|
||||
| interval | optional, the Interval at which to reconcile the Helm release, default to 30s | 1m |
|
||||
| oss | optional, The [oss](#OSS) source configuration | |
|
||||
| git | optional, The [git](#OSS) source configuration | dev |
|
||||
| oss | optional, The [oss](#oss) source configuration | |
|
||||
| git | optional, The [git](#git) source configuration | dev |
|
||||
|
||||
##### OSS
|
||||
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 285 KiB |
|
|
@ -142,6 +142,14 @@
|
|||
"end-user/workflow/timeout"
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "category",
|
||||
"label": "Pipeline",
|
||||
"collapsed": true,
|
||||
"items": [
|
||||
"end-user/pipeline/workflowrun"
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "category",
|
||||
"label": "GitOps",
|
||||
|
|
@ -217,7 +225,8 @@
|
|||
"platform-engineers/system-operation/vela-cli-image",
|
||||
"platform-engineers/system-operation/enable-addon-offline",
|
||||
"platform-engineers/system-operation/migration-from-old-version",
|
||||
"platform-engineers/system-operation/system-info-diagnose"
|
||||
"platform-engineers/system-operation/system-info-diagnose",
|
||||
"platform-engineers/system-operation/high-availability"
|
||||
]
|
||||
},
|
||||
{
|
||||
|
|
|
|||
Loading…
Reference in New Issue