Wei (段少)
GitHub
parent
1bad646012
commit
9d9f5c39f2
|
|
@ -1,34 +1,42 @@
|
|||
---
|
||||
title: AutoScaler
|
||||
title: Modify Replicas
|
||||
description: This article introduces how KubeVela adjusts the number of application copies.
|
||||
---
|
||||
|
||||
## Specification
|
||||
This section introduces how manually modify replicas to apply.
|
||||
|
||||
## Before starting
|
||||
|
||||
| NAME | DESCRIPTION | TYPE | REQUIRED | DEFAULT |
|
||||
| ------- | ------------------------------------------------------------------------------- | ---- | -------- | ------- |
|
||||
| min | Specify the minimal number of replicas to which the autoscaler can scale down | int | true | 1 |
|
||||
| max | Specify the maximum number of of replicas to which the autoscaler can scale up | int | true | 10 |
|
||||
| cpuUtil | Specify the average cpu utilization, for example, 50 means the CPU usage is 50% | int | true | 50 |
|
||||
- You've walked through at least one type of application deployment.
|
||||
|
||||
## How to use
|
||||
## Attaching Trait
|
||||
|
||||
```yaml
|
||||
# sample.yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: website
|
||||
spec:
|
||||
components:
|
||||
- name: frontend # This is the component I want to deploy
|
||||
type: webservice
|
||||
properties:
|
||||
image: nginx
|
||||
traits:
|
||||
- type: cpuscaler # Automatically scale the component by CPU usage after deployed
|
||||
properties:
|
||||
min: 1
|
||||
max: 10
|
||||
cpuPercent: 60
|
||||
```
|
||||
KubeVela has a built-in `scaler` Trait by default, which supports the adjustment of replicas in typical workloads, such as `webservice` and `k8s-objects` applications.
|
||||
|
||||
> For k8s-objects type applications, when multiple resources are involved, please put the workload resources such as Deployment, Statefulset, Job in the first place so that the Trait of `scaler` can take effect.
|
||||
|
||||
Let's take first-vela-app in `Deliver First Application` as an example. First, open the application's `Benchmark Config`-`Properties` page:
|
||||
|
||||
|
||||
|
||||
Next, we click the Settings (gear) button on the right side of Set Replicas to adjust replicas to 3. After clicking save, the changes will be temporarily stored.
|
||||
|
||||
Then to make it effective in a certain environment, we need to click the `Deploy` button or the multi-environment workflow selection button next to it and select the corresponding environment to perform the deployment.
|
||||
|
||||
After the deployment is complete, you can enter the environment instance page. You'll find 3 rows of data that have appeared in the instance list.
|
||||
|
||||
|
||||
|
||||
> Trait can extend more powerful features, such as HPA.
|
||||
|
||||
## Edit deployment parameters
|
||||
|
||||
For applications created using Helm or other custom deployment types, if Traits are not applicable, you can directly edit the deployment parameters to adjust the number of application instances.
|
||||
|
||||
For example, in Helm applications, the general Chart package provides parameters for setting the number of replicas, which can be set by setting Values.
|
||||
|
||||
Take [apache chart](https://github.com/bitnami/charts/tree/master/bitnami/apache) as an example, set `replicaCount=3` in Values to adjust the number of replicas.
|
||||
|
||||
## Next step
|
||||
|
||||
- [Customize Scaler Trait](../platform-engineers/traits/customize-trait)
|
||||
|
|
@ -1,307 +1,56 @@
|
|||
---
|
||||
title: Multi-Cluster App Delivery
|
||||
title: Manage Workflow
|
||||
description: This article introduces the usage of Workflow and gives you a full picture of it.
|
||||
---
|
||||
|
||||
This section will introduce how to use KubeVela for multi-cluster application delivery and why.
|
||||
This section introduces the usage of Workflow and gives you a full picture of it.
|
||||
|
||||
## Introduction
|
||||
In the section of [Deploy Kubernetes Raw Resources](./k8s-object), we first learned the usage of workflow, that is, manual approval in the process of multi-cluster publishing. Now we continue to introduce the following topics:
|
||||
|
||||
There are more and more situations come out that organizations need multi-cluster technology for application delivery:
|
||||
1. Learn more about Workflow, Revision, and Environment, as well as all the built-in Workflow steps.
|
||||
2. Implement notifications in the workflow.
|
||||
3. Perform data initialization in the workflow.
|
||||
|
||||
- For scalability, a single Kubernetes cluster has its limit around 5K nodes or less, it is unable to handle the large scale application load.
|
||||
- For stability/availability, application can deploy in multi-cluster for backup which provides more stability and availability.
|
||||
- For security, you may need to deploy in different zones/areas as government policy requires.
|
||||
## Before starting
|
||||
|
||||
The following guide will the multi-cluster that helps you easily deploy an application to different environments.
|
||||
We assume that you've learned from [Deliver the first application](../quick-start), [Deliver Docker image](./webservice), and other articles to understand the basic
|
||||
|
||||
## Preparation
|
||||
## Workflow and Revision
|
||||
|
||||
You can simply join an existing cluster into KubeVela by specify its KubeConfig like below.
|
||||
When the application is deployed, a certain workflow is executed to release a version. The Revision follows the execution status of the workflow, which means that if the workflow is successfully executed, Revision will increase by +1.
|
||||
|
||||
```shell script
|
||||
vela cluster join <your kubeconfig path>
|
||||
```
|
||||
The workflow is bound to the environment where the application is released, that is, each environment of the application has an independent workflow.
|
||||
|
||||
It will use field `context.cluster` in KubeConfig as the cluster name automatically,
|
||||
you can also specify the name by `--name` parameter. For example:
|
||||
|
||||
|
||||
```shell
|
||||
vela cluster join stage-cluster.kubeconfig --name cluster-staging
|
||||
vela cluster join prod-cluster.kubeconfig --name cluster-prod
|
||||
```
|
||||
After docking with the CI system, Revision can be associated with Code Commit to trace the history. Later, the version rollback function will be implemented, and you can choose to roll back an environment to a specified version at any time.
|
||||
|
||||
After clusters joined, you could list all clusters managed by KubeVela currently.
|
||||
## Built-in Workflow steps
|
||||
|
||||
```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
|
||||
```
|
||||
In [Deliver Kubernetes Native Resources](./k8s-object), we used the manual review step `suspend`. Let's take a look at what the other built-in steps do:
|
||||
|
||||
You can also detach a cluster if you're not using it any more.
|
||||
- `deploy2env`: The application is delivered to the designated Target. This step will be automatically generated according to the Target configured in the environment.
|
||||
- `deploy-cloud-resource`: Cloud resource applications are delivered to the designated Target. Note that the difference between this type of step and deploy2env is that the CR resource created by the control cloud resource is deployed to the control cluster. After the service is created and the access key (Secret) is generated, the Secret is distributed to the Target designated cluster and Namespace.
|
||||
- `share-cloud-resource`: Distribute the secret generated by a cloud service to the specified targets. Thus when one cloud service is created in a multi-cluster application, and its access key can be shared to the other of multiple clusters.
|
||||
- `notification`: three notification modes: DingTalk, Mail, and Slack, place them in any stage of the workflow to implement message notifications.
|
||||
- `webhook`: place it at any stage of the workflow to call back external systems.
|
||||
|
||||
```shell script
|
||||
$ vela cluster detach cluster-prod
|
||||
```
|
||||
## Implement notification
|
||||
|
||||
If there's still any application running in the cluster, the command will be rejected.
|
||||
Use the `notification` step to implement three notification modes: DingTalk, Email, and Slack. Enter the application workflow management page, select an environment workflow and click the `Edit` button to enter the editing state.
|
||||
|
||||
## Deploy Application to multi cluster
|
||||
|
||||
|
||||
KubeVela regards a Kubernetes cluster as an environment, so you can deploy an application into
|
||||
one or more environments.
|
||||
Select the step of `notification` type on the left and drag it into the canvas on the right, the page will automatically pop up the workflow step editing window. In the setting window, you can set three kinds of notifications as needed. In the same step, if you set multiple Notices, it takes effect at the same time.
|
||||
|
||||
Below is an example, deploy to a staging environment first, check the application running well,
|
||||
and finally promote to production environment.
|
||||
|
||||
|
||||
For different environments, the deployment configuration can also have some nuance. In the staging environment, we only need one replica for the webservice and do not need the worker. In the production environment, we setup 3 replicas for the webservice and enable the worker.
|
||||
If you set `Dingding` notification, click the enable button on the right side of the `Dingding` window, and two input boxes will appear on the page, one is the webhook address of the Dingding group notification robot, refer to [Dingding group robot reference document](https:// open.dingtalk.com/document/group/custom-robot-access). The other is the notification content input box, you can customize any notification content that needs to be sent.
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: example-app
|
||||
namespace: default
|
||||
spec:
|
||||
components:
|
||||
- name: hello-world-server
|
||||
type: webservice
|
||||
properties:
|
||||
image: crccheck/hello-world
|
||||
port: 8000
|
||||
traits:
|
||||
- type: scaler
|
||||
properties:
|
||||
replicas: 1
|
||||
- name: data-worker
|
||||
type: worker
|
||||
properties:
|
||||
image: busybox
|
||||
cmd:
|
||||
- sleep
|
||||
- "1000000"
|
||||
policies:
|
||||
- name: example-multi-env-policy
|
||||
type: env-binding
|
||||
properties:
|
||||
envs:
|
||||
- name: staging
|
||||
placement: # selecting the cluster to deploy to
|
||||
clusterSelector:
|
||||
name: cluster-staging
|
||||
selector: # selecting which component to use
|
||||
components:
|
||||
- hello-world-server
|
||||
`Slack` is similar to `Dingding` configuration, please refer to [Get Webhook Address in Slack](https://api.slack.com/messaging/webhooks).
|
||||
|
||||
- name: prod
|
||||
placement:
|
||||
clusterSelector:
|
||||
name: cluster-prod
|
||||
patch: # overlay patch on above components
|
||||
components:
|
||||
- name: hello-world-server
|
||||
type: webservice
|
||||
traits:
|
||||
- type: scaler
|
||||
properties:
|
||||
replicas: 3
|
||||
`Email` has more configuration data. It needs to configure the mail server, mail content and sending destination mail address, etc.
|
||||
|
||||
- name: health-policy-demo
|
||||
type: health
|
||||
properties:
|
||||
probeInterval: 5
|
||||
probeTimeout: 10
|
||||
After the configuration is complete, click `Submit` to save the step configuration. At this time, you need to plan the location of the notification step. By default, it will be added to the end. If you want to place it in the middle step, you need to disconnect the direct connection of the original step, and then notify Steps are placed in the middle of the wire.
|
||||
|
||||
workflow:
|
||||
steps:
|
||||
# deploy to staging env
|
||||
- name: deploy-staging
|
||||
type: deploy2env
|
||||
properties:
|
||||
policy: example-multi-env-policy
|
||||
env: staging
|
||||
|
||||
# manual check
|
||||
- name: manual-approval
|
||||
type: suspend
|
||||
|
||||
# deploy to prod env
|
||||
- name: deploy-prod
|
||||
type: deploy2env
|
||||
properties:
|
||||
policy: example-multi-env-policy
|
||||
env: prod
|
||||
```
|
||||
|
||||
After the application deployed, it will run as the workflow steps.
|
||||
|
||||
> You can refer to [Env Binding](../end-user/policies/envbinding) and [Health Check](../end-user/policies/health) policy user guide for parameter details.
|
||||
|
||||
It will deploy application to staging environment first, you can check the `Application` status by:
|
||||
|
||||
```shell
|
||||
> kubectl get application example-app
|
||||
NAME COMPONENT TYPE PHASE HEALTHY STATUS AGE
|
||||
example-app hello-world-server webservice workflowSuspending true Ready:1/1 10s
|
||||
```
|
||||
|
||||
We can see that the workflow is suspended at `manual-approval`:
|
||||
|
||||
```yaml
|
||||
|
||||
---
|
||||
status:
|
||||
workflow:
|
||||
appRevision: example-app-v1:44a6447e3653bcc2
|
||||
contextBackend:
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
name: workflow-example-app-context
|
||||
uid: 56ddcde6-8a83-4ac3-bf94-d19f8f55eb3d
|
||||
mode: StepByStep
|
||||
steps:
|
||||
- id: wek2b31nai
|
||||
name: deploy-staging
|
||||
phase: succeeded
|
||||
type: deploy2env
|
||||
- id: 7j5eb764mk
|
||||
name: manual-approval
|
||||
phase: succeeded
|
||||
type: suspend
|
||||
suspend: true
|
||||
terminated: false
|
||||
waitCount: 0
|
||||
```
|
||||
|
||||
You can also check the health status in the `status.service` field below.
|
||||
|
||||
```yaml
|
||||
|
||||
---
|
||||
status:
|
||||
services:
|
||||
- env: staging
|
||||
healthy: true
|
||||
message: "Ready:1/1 "
|
||||
name: hello-world-server
|
||||
scopes:
|
||||
- apiVersion: core.oam.dev/v1alpha2
|
||||
kind: HealthScope
|
||||
name: health-policy-demo
|
||||
namespace: test
|
||||
uid: 6e6230a3-93f3-4dba-ba09-dd863b6c4a88
|
||||
traits:
|
||||
- healthy: true
|
||||
type: scaler
|
||||
workloadDefinition:
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
```
|
||||
|
||||
You can use `resume` command after everything verified in statging cluster:
|
||||
|
||||
```shell
|
||||
> vela workflow resume example-app
|
||||
Successfully resume workflow: example-app
|
||||
```
|
||||
|
||||
Recheck the `Application` status:
|
||||
|
||||
```shell
|
||||
> kubectl get application example-app
|
||||
NAME COMPONENT TYPE PHASE HEALTHY STATUS AGE
|
||||
example-app hello-world-server webservice running true Ready:1/1 62s
|
||||
```
|
||||
|
||||
```yaml
|
||||
status:
|
||||
services:
|
||||
- env: staging
|
||||
healthy: true
|
||||
message: "Ready:1/1 "
|
||||
name: hello-world-server
|
||||
scopes:
|
||||
- apiVersion: core.oam.dev/v1alpha2
|
||||
kind: HealthScope
|
||||
name: health-policy-demo
|
||||
namespace: default
|
||||
uid: 9174ac61-d262-444b-bb6c-e5f0caee706a
|
||||
traits:
|
||||
- healthy: true
|
||||
type: scaler
|
||||
workloadDefinition:
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
- env: prod
|
||||
healthy: true
|
||||
message: "Ready:3/3 "
|
||||
name: hello-world-server
|
||||
scopes:
|
||||
- apiVersion: core.oam.dev/v1alpha2
|
||||
kind: HealthScope
|
||||
name: health-policy-demo
|
||||
namespace: default
|
||||
uid: 9174ac61-d262-444b-bb6c-e5f0caee706a
|
||||
traits:
|
||||
- healthy: true
|
||||
type: scaler
|
||||
workloadDefinition:
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
- env: prod
|
||||
healthy: true
|
||||
message: "Ready:1/1 "
|
||||
name: data-worker
|
||||
scopes:
|
||||
- apiVersion: core.oam.dev/v1alpha2
|
||||
kind: HealthScope
|
||||
name: health-policy-demo
|
||||
namespace: default
|
||||
uid: 9174ac61-d262-444b-bb6c-e5f0caee706a
|
||||
workloadDefinition:
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
```
|
||||
|
||||
All the step status in workflow is succeeded:
|
||||
|
||||
```yaml
|
||||
|
||||
---
|
||||
status:
|
||||
workflow:
|
||||
appRevision: example-app-v1:44a6447e3653bcc2
|
||||
contextBackend:
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
name: workflow-example-app-context
|
||||
uid: e1e7bd2d-8743-4239-9de7-55a0dd76e5d3
|
||||
mode: StepByStep
|
||||
steps:
|
||||
- id: q8yx7pr8wb
|
||||
name: deploy-staging
|
||||
phase: succeeded
|
||||
type: deploy2env
|
||||
- id: 6oxrtvki9o
|
||||
name: manual-approval
|
||||
phase: succeeded
|
||||
type: suspend
|
||||
- id: uk287p8c31
|
||||
name: deploy-prod
|
||||
phase: succeeded
|
||||
type: deploy2env
|
||||
suspend: false
|
||||
terminated: false
|
||||
waitCount: 0
|
||||
```
|
||||
|
||||
## More use cases
|
||||
|
||||
KubeVela can provide many strategies to deploy an application to multiple clusters by composing env-binding policy and workflow steps.
|
||||
|
||||
You can have a glimpse of how does it work as below:
|
||||
|
||||
|
||||
|
||||
More use cases about the multi cluster application deployment are coming soon.
|
||||
After the workflow is configured, please click the Save button at the top right of the workflow window to save all changes. After saving, you can click the `Deploy` on the top right of the page or the select button on the right to choose to execute the workflow and verify whether you can receive a message notification.
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: 管理应用工作流
|
||||
description: 本文介绍Kubernetes的工作流工程模式，常用操作和适用的场景。
|
||||
description: 本文介绍 KubeVela 的工作流工程模式，常用操作和适用的场景。
|
||||
---
|
||||
|
||||
本文详细介绍应用工作流的功能和使用场景，带你更全面的了解工作流。
|
||||
|
|
@ -21,17 +21,17 @@ description: 本文介绍Kubernetes的工作流工程模式，常用操作和适
|
|||
|
||||
|
||||
|
||||
对接 CI 系统后，版本可以与 Code Commit 关联，实现版本可追溯。在版本操作中后续会实现版本回退功能，用户可在任何时候选择将某个环境回退到指定版本。
|
||||
对接 CI 系统后，版本可以与 Code Commit 关联，实现版本可追溯。在版本操作中后续会实现版本回退功能，你可在任何时候选择将某个环境回退到指定版本。
|
||||
|
||||
## 内置支持的工作流步骤
|
||||
|
||||
在 [交付 Kubernetes 原生资源](./k8s-object) 文章中，我们使用了人工审核步骤`suspend`。我们再来了解一下其他内置的步骤分别是什么作用：
|
||||
在 [交付 Kubernetes 原生资源](./k8s-object) 文章中，我们使用了人工审核步骤 `suspend`。我们再来了解一下其他内置的步骤分别是什么作用：
|
||||
|
||||
- `deploy2env`: 应用交付到指定 Target。该步骤 Vela 会根据环境中配置的 Target 自动生成。
|
||||
- `deploy-cloud-resource`: 云资源应用交付到指定 Target。该步骤 Vela 会为云资源应用，根据环境中配置的 Target 自动生成，需要注意的是，该类型步骤与 deploy2env 的区别在于控制云资源创建的 CR 资源是部署到管控集群的，服务创建完成生成访问密钥(Secret)后，将 Secret 分发到 Target 指定集群和 Namespace。
|
||||
- `share-cloud-resource`: 分发云服务生成的 Secret 到指定 Target，使用该步骤实现云服务多集群共享，即在多集群应用中只创建一个云服务，将其访问密钥分发到多个集群，实现服务共享。
|
||||
- `notification`: 通知，支持钉钉、邮件、Slack 三种通知模式，用户可将其置于工作流的任何阶段实现消息通知。
|
||||
- `webhook`: Web 钩子，用户可将其置于工作流任何阶段，实现对外部系统的调用。
|
||||
- `notification`: 通知，支持钉钉、邮件、Slack 三种通知模式，你可将其置于工作流的任何阶段实现消息通知。
|
||||
- `webhook`: Web 钩子，你可将其置于工作流任何阶段，实现对外部系统的调用。
|
||||
|
||||
## 实现消息通知
|
||||
|
||||
|
|
@ -51,4 +51,4 @@ description: 本文介绍Kubernetes的工作流工程模式，常用操作和适
|
|||
|
||||
配置完成点击 `Submit` 保存步骤配置，这时需要规划通知步骤的位置，默认它将添加到最后，如果你希望将其放置到中间步骤，需要断开原有步骤直接的连线，然后将通知步骤进行连线放置在中间。
|
||||
|
||||
工作流配置完成后注意点击工作流窗口右上方的 Save 按钮保存所有变更。保存完成后可以点击页面右上方的`Deploy`或右边的选择按钮选择执行该工作流，验证是否可以收到消息通知。
|
||||
工作流配置完成后注意点击工作流窗口右上方的 Save 按钮保存所有变更。保存完成后可以点击页面右上方的 `Deploy` 或右边的选择按钮选择执行该工作流，验证是否可以收到消息通知。
|
||||
|
|
@ -28,8 +28,8 @@ module.exports = {
|
|||
"deliver-app/helm",
|
||||
"deliver-app/k8s-object",
|
||||
"deliver-app/consume-cloud-services",
|
||||
// "deliver-app/scaler",
|
||||
// "deliver-app/workflows",
|
||||
"deliver-app/scaler",
|
||||
"deliver-app/workflows",
|
||||
],
|
||||
},
|
||||
{
|
||||
|
|
|
|||
Loading…
Reference in New Issue