Adding Canary Release EN (#267)

* Adding Canary Release EN

* updates

* Update docs/case-studies/canary-blue-green.md

Co-authored-by: Hongchao Deng <hongchaodeng1@gmail.com>

* Update docs/case-studies/canary-blue-green.md

Co-authored-by: Hongchao Deng <hongchaodeng1@gmail.com>

* Update docs/case-studies/canary-blue-green.md

Co-authored-by: Hongchao Deng <hongchaodeng1@gmail.com>

* Update docs/case-studies/canary-blue-green.md

Co-authored-by: Hongchao Deng <hongchaodeng1@gmail.com>

* Update docs/case-studies/canary-blue-green.md

Co-authored-by: Hongchao Deng <hongchaodeng1@gmail.com>

* Update docs/case-studies/canary-blue-green.md

Co-authored-by: Hongchao Deng <hongchaodeng1@gmail.com>

* Update docs/case-studies/canary-blue-green.md

Co-authored-by: Hongchao Deng <hongchaodeng1@gmail.com>

* Update docs/case-studies/canary-blue-green.md

Co-authored-by: Hongchao Deng <hongchaodeng1@gmail.com>

* Update docs/case-studies/canary-blue-green.md

Co-authored-by: Hongchao Deng <hongchaodeng1@gmail.com>

* fix

Co-authored-by: 段少 <duanwei.duan@alibaba-inc.com>
Co-authored-by: Hongchao Deng <hongchaodeng1@gmail.com>
This commit is contained in:
Wei (段少) 2021-09-14 16:47:55 +08:00 committed by GitHub
parent 2a48f3a9fb
commit c410210500
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
19 changed files with 235 additions and 160 deletions

View File

@ -0,0 +1,219 @@
---
title: Canary Release
---
This article introduces how KubeVela integrates [Istio](https://istio.io/latest/) to do a canary release.
## Praparation
Install the Istio cluster plugin.
```shell
vela addon enable istio
```
The default namespace needs to be labeled so that Istio will auto-inject sidecar.
```shell
kubectl label namespace default istio-injection=enabled
```
## Initial deployment
Deploy the Application of `bookinfo`:
```shell
kubectl apply -f https://github.com/oam-dev/kubevela/blob/master/docs/examples/canary-rollout-use-case/first-deploy.yaml
```
The component architecture and relationship of the application are as follows:
![book-info-struct](../resources/book-info-struct.jpg)
This Application has four Components, each configured with an`expose` Trait to expose cluster-level service.
The `productpage` component is also configured with an `istio-gateway` Trait, allowing the Component to receive traffic coming from outside the cluster. The example below show that it sets `gateway:ingressgateway` to use Istio's default gateway, and `hosts: "*"` to specify that any request can enter the gateway.
```shell
...
- name: productpage
type: webservice
properties:
image: docker.io/istio/examples-bookinfo-productpage-v1:1.16.2
port: 9080
traits:
- type: expose
properties:
port:
- 9080
- type: istio-gateway
properties:
hosts:
- "*"
gateway: ingressgateway
match:
- exact: /productpage
- prefix: /static
- exact: /login
- prefix: /api/v1/products
port: 9080
...
```
You can port-forward to the gateway as follows:
```shell
kubectl port-forward service/istio-ingressgateway -n istio-system 19082:80
```
Visit `127.0.0.1:19082` through the browser and you will see the following page.
![pic-v2](../resources/canary-pic-v2.jpg)
## Canary Release
Next, we take the `reviews` Component as an example to simulate the complete process of a canary release, and first upgrade a part of the component instances, and adjust the traffic at the same time, so as to achieve the purpose of progressive canary release.
Execute the following command to update the application.
```shell
kubectl apply -f https://github.com/oam-dev/kubevela/blob/master/docs/examples/canary-rollout-use-case/rollout-v2.yaml
```
This operation updates the mirror of the `reviews` Component from the previous v2 to v3. At the same time, the Rollout Trait of the `reviews` Component specifies that the number of target instances to be upgraded is two, which are upgraded in two batches, with one instance in each batch.
In addition, a canary-traffic Trait has been added to the Component.
```shell
...
- name: reviews
type: webservice
properties:
image: docker.io/istio/examples-bookinfo-reviews-v3:1.16.2
port: 9080
volumes:
- name: wlp-output
type: emptyDir
mountPath: /opt/ibm/wlp/output
- name: tmp
type: emptyDir
mountPath: /tmp
traits:
- type: expose
properties:
port:
- 9080
- type: rollout
properties:
targetSize: 2
rolloutBatches:
- replicas: 1
- replicas: 1
- type: canary-traffic
properties:
port: 9080
...
```
This update also adds an upgraded execution Workflow to the Application, which contains three steps.
The first step is to upgrade only the first batch of instances by specifying `batchPartition` equal to 0. And use `traffic.weightedTargets` to switch 10% of the traffic to the new version of the instance.
After completing the first step, the execution of the second step of the Workflow will enter a pause state, waiting for the user to verify the service status.
The third step of the Workflow is to complete the upgrade of the remaining instances and switch all traffic to the new component version.
```shell
...
workflow:
steps:
- name: rollout-1st-batch
type: canary-rollout
properties:
# just upgrade first batch of component
batchPartition: 0
traffic:
weightedTargets:
- revision: reviews-v1
weight: 90 # 90% shift to new version
- revision: reviews-v2
weight: 10 # 10% shift to new version
# give user time to verify part of traffic shifting to newRevision
- name: manual-approval
type: suspend
- name: rollout-rest
type: canary-rollout
properties:
# upgrade all batches of component
batchPartition: 1
traffic:
weightedTargets:
- revision: reviews-v2
weight: 100 # 100% shift to new version
...
```
After the update is complete, visit the previous URL multiple times in the browser. There is about 10% probability that you will see the new page below,
![pic-v3](../resources/canary-pic-v3.jpg)
It can be seen that the new version of the page has changed from the previous black five-pointed star to a red five-pointed star.
### Continue with Full Release
If the service is found to meet expectations during manual verification, the Workflow needs to be continued to complete the full release. You can do that by executing the following command.
```shell
vela workflow reumse book-info
```
If you continue to verify the webpage several times on the browser, you will find that the five-pointed star will always be red.
### Terminate the publishing Workflow and Roll Back
If during manual verification, it is found that the service does not meet expectations, you need to terminate the pre-defined release workflow and switch the traffic and instances back to the previous version.
```shell
kubectl apply -f https://github.com/oam-dev/kubevela/blob/master/docs/examples/canary-rollout-use-case/revert-in-middle.yaml
```
This update deletes the previously defined workflow to terminate the execution of the workflow.
And by modifying the `targetRevision` of the Rollout Trait to point to the previous component version `reviews-v1`. In addition, this update also removes the canary-traffic Trait of the Component, and puts all traffic on the same component version `reviews-v1`.
```shell
...
- name: reviews
type: webservice
properties:
image: docker.io/istio/examples-bookinfo-reviews-v3:1.16.2
port: 9080
volumes:
- name: wlp-output
type: emptyDir
mountPath: /opt/ibm/wlp/output
- name: tmp
type: emptyDir
mountPath: /tmp
traits:
- type: expose
properties:
port:
- 9080
- type: rollout
properties:
targetRevision: reviews-v1
batchPartition: 1
targetSize: 2
# This means to rollout two more replicas in two batches.
rolloutBatches:
- replicas: 2
...
```
Continue to visit the website on the browser, you will find that the five-pointed star has changed back to black.

View File

@ -1,5 +0,0 @@
---
title: 金丝雀发布、蓝绿发布、多泳道发布
---
WIP

View File

@ -1,133 +0,0 @@
---
title: Integrated Cloud Services # Deprecated
---
Cloud-oriented development is now becoming the norm, there is an urgent need to integrate cloud resources from different sources and types. Whether it is the most basic object storage, cloud database, or load balancing, it is all faced with the challenges of hybrid cloud, multi-cloud and other complex environments, and KubeVela is perfect for the needs.
KubeVela efficiently and securely integrates different types of cloud resources through resource binding capabilities in cloud resource Components and Traits. At present, you can directly use the default components of AliCloud Kubernetes(ACK), AliCloud Object Storage Service (OSS) and AliCloud Relational Database Service (RDS). At the same time, more new cloud resources will gradually become the default option under the support of the community in the future, so that you can use cloud resources of various manufacturers in a standardized and unified way.
## Check the cloud resources in KubeVela
We can use [KubeVela CLI](../install#3-Get-KubeVela-CLI) to check the available cloud resources in the current cluster:
```shell
$ vela components
NAME NAMESPACE WORKLOAD DESCRIPTION
alibaba-ack vela-system configurations.terraform.core.oam.dev Terraform configuration for Alibaba Cloud ACK cluster
alibaba-oss vela-system configurations.terraform.core.oam.dev Terraform configuration for Alibaba Cloud OSS object
alibaba-rds vela-system configurations.terraform.core.oam.dev Terraform configuration for Alibaba Cloud RDS object
```
The integration process of cloud resources in KubeVela is as follows:
- Get required secret or token from cloud service providers.
- Save the authentication information to the global configuration of Terraform and verify it.
- KubeVela will authenticate with the Terraform controller and automatically pull up cloud resources.
## Activate cloud resources
Prepare the token of the cloud resources and use `vela addon enable` to configure the authentication:
```shell
vela addon enable terraform/provider-alicloud --ALICLOUD_ACCESS_KEY_ID=<your key ID> -ALICLOUD_SECRET_ACCESS_KEY=<your key secret>
```
Take the example of AliCloud relational database (RDS) as an example to explain.
### Apply cloud resource
Apply the `Application`:
```shell
cat <<EOF | kubectl apply -f -
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: webapp
spec:
components:
- name: rds-server
type: webservice
properties:
image: zzxwill/flask-web-application:v0.3.1-crossplane
ports: 80
- name: sample-db
type: alibaba-rds
properties:
instance_name: sample-db
account_name: oamtest
password: U34rfwefwefffaked
writeConnectionSecretToRef:
name: db-conn
EOF
```
We use a `webservice` component as the server for RDS, while the `alibaba-rds` component named `sample-db` takes responsibility for pulling cloud resources, and the database information is written to `db-conn`.
Generally, it takes a lot of time to pull up cloud resources. For example, RDS here takes about 15 minutes. We can see its whole process from rendering, health check to running:
```
$ vela ls
APP COMPONENT TYPE TRAITS PHASE HEALTHY STATUS CREATED-TIME
webapp rds-server webservice service-binding rendering 2021-08-30 20:04:03 +0800 CST
└─ sample-db alibaba-rds rendering 2021-08-30 20:04:03 +0800 CST
webapp rds-server webservice service-binding healthChecking healthy 2021-08-30 20:04:03 +0800 CST
└─ sample-db alibaba-rds healthChecking unhealthy Cloud resources are being provisioned. 2021-08-30 20:04:03 +0800 CST
webapp rds-server webservice service-binding running healthy 2021-08-30 20:04:03 +0800 CST
└─ sample-db alibaba-rds running healthy Cloud resources are deployed and ready to use. 2021-08-30 20:04:03 +0800 CST
```
### Bind cloud resources to components
Use Traits `service-binding` and update the YAML file, the `db-conn` will send secret and token to the `rds-server` component:
```shell
cat <<EOF | kubectl apply -f -
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: webapp
spec:
components:
- name: rds-server
type: webservice
properties:
image: zzxwill/flask-web-application:v0.3.1-crossplane
ports: 80
traits:
- type: service-binding
properties:
envMappings:
# 环境变量与 db-conn 密钥形成映射
DB_PASSWORD:
secret: db-conn
endpoint:
secret: db-conn
key: DB_HOST
username:
secret: db-conn
key: DB_USER
- name: sample-db
type: alibaba-rds
properties:
instance_name: sample-db
account_name: oamtest
password: U34rfwefwefffaked
writeConnectionSecretToRef:
name: db-conn
EOF
```
For more cloud resources usages, please check built-in cloud resources in platform-engineers doc.
## Custom cloud resources
If the out-of-the-box cloud resources don't cover your needs, you can still use the flexible [Terraform component](../platform-engineers/components/component-terraform) to build your own cloud resources.
## Next
- [Component Observability](./component-observability)
- [Data Pass Between Components ](./component-dependency-parameter)
- [Multi-Cluster and Environment](../case-studies/multi-app-env-cluster)

View File

@ -150,5 +150,5 @@ Handling connection for 80
## Next
- [Component Observability](../../component-observability)
- [Data Pass Between Components ](../../component-dependency-parameter)
- [Data Pass Between Components ](../../workflow/component-dependency-parameter)
- [Multi-Cluster and Environment](../../../case-studies/multi-app-env-cluster)

View File

@ -2,7 +2,9 @@
title: Multi Environments
---
If we have multiple clusters, we want to apply our application in the test cluster first, and then apply it to the production cluster after the application in test cluster is running. KubeVela provides the `multi-env` workflow step to manage multi environments.
If we have multiple clusters, we want to apply our application in the test cluster first, and then apply it to the production cluster after the application in test cluster is running. KubeVela provides the `multi-env` workflow step to manage multi environments. You can have a glimpse of how does it work as below:
![alt](../../resources/workflow-multi-env.png)
In this guide, you will learn how to manage multi environments via `multi-env` in `Workflow`.

View File

@ -439,7 +439,7 @@ The out-of-the-box capabilities provided by KubeVela, including components, trai
Get to know about how to customize:
* [Component](../components/custom-component)
* [Trait](../traits/customize-trait)
* [Policy](../policy/custom-policy)
<!-- * [Policy](../policy/custom-policy) -->
* [Workflow](../workflow/workflow)
[1]: ../oam/oam-model

Binary file not shown.

After

Width:  |  Height:  |  Size: 57 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 78 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 82 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 756 KiB

View File

@ -1,23 +1,16 @@
---
title: 金丝雀发布
---
本文将会介绍 KubeVela 基于 [Istio](https://istio.io/latest/) 实现经典微服务场景 [bookinfo](https://istio.io/latest/docs/examples/bookinfo/?ie=utf-8&hl=en&docs-search=Canary) 的金丝雀发布功能。
## 准备工作
开启 istio 集群插件
开启 Istio 集群插件
```shell
vela addon enable istio
```
等待一段时间,确认集群插件状态为 `success` 说明已经就绪。
```shell
kubectl get initializer -n istio-system istio
NAME PHASE AGE
istio success 4h47m
```
因为后面的例子运行在 default namespace需要为 default namespace 打上 Istio 自动注入 sidecar 的标签。
```shell
@ -83,7 +76,7 @@ kubectl port-forward service/istio-ingressgateway -n istio-system 19082:80
```shell
kubectl apply -f https://github.com/oam-dev/kubevela/blob/master/docs/examples/canary-rollout-use-case/rollout-v2.yaml
```
这次操作更新了 reviews 组件的镜像,从之前的 v2 升级到了 v3。同时 reviews 组件的灰度发布 (Rollout) 运维特征指定了升级的目标实例个数为2个分两个批次升级每批升级1个实例。
这次操作更新了 reviews 组件的镜像,从之前的 v2 升级到了 v3。同时 reviews 组件的灰度发布 (Rollout) 运维特征指定了,升级的目标实例个数为 2 个,分两个批次升级,每批升级 1 个实例。
此外还为该组件新增加了一个金丝雀流量发布 (canary-traffic) 运维特征。
```shell
@ -123,7 +116,7 @@ kubectl apply -f https://github.com/oam-dev/kubevela/blob/master/docs/examples/c
这次更新还为应用新增了一个升级的执行工作流,该工作流包含三个步骤。
第一步通过指定 `batchPartition` 等于0设置只升级第一批次的实例。并通过 `traffic.weightedTargets` 将10%的流量切换到新版本的实例上面。
第一步通过指定 `batchPartition` 等于 0 设置只升级第一批次的实例。并通过 `traffic.weightedTargets` 10% 的流量切换到新版本的实例上面。
完成第一步之后,执行第二步工作流会进入暂停状态,等待用户校验服务状态。

View File

@ -158,6 +158,6 @@ EOF
## 下一步
- [组件可观测性](../../component-observability)
- [应用组件间的依赖和参数传递](../../component-dependency-parameter)
- [应用组件间的依赖和参数传递](../../workflow/component-dependency-parameter)
- [多应用、多环境、多集群编排](../../../case-studies/multi-app-env-cluster)

View File

@ -1,5 +0,0 @@
---
title: 管理交付环境
---
TBD

View File

@ -4,7 +4,9 @@ title: 多环境交付
本节将介绍如何在工作流中使用多环境功能。
在多集群的情况下我们首先需要在测试集群部署应用等到测试集群的应用一切正常后再部署到生产集群。KubeVela 提供了一个 `multi-env` 类型的工作流步骤,可以帮助用户方便的管理多环境配置。
在多集群的情况下我们首先需要在测试集群部署应用等到测试集群的应用一切正常后再部署到生产集群。KubeVela 提供了一个 `multi-env` 类型的工作流步骤,可以帮助用户方便的管理多环境配置。你可以大致了解它的工作原理,如下所示:
![alt](../../resources/workflow-multi-env.png)
本节将介绍如何在工作流使用 `multi-env` 来管理多环境。

View File

@ -438,7 +438,7 @@ KubeVela 背后提供的开箱即用的能力,包括组件、运维功能、
* 了解更多[自定义组件](../components/custom-component)的功能。
* 了解更多[自定义运维能力](../traits/customize-trait)的功能。
* 了解[自定义策略](../policy/custom-policy)背后的功能。
<!-- * 了解[自定义策略](../policy/custom-policy)背后的功能。 -->
* 了解[自定义工作流](../workflow/workflow)背后的功能。
[1]: ../oam/oam-model

Binary file not shown.

After

Width:  |  Height:  |  Size: 805 KiB

View File

@ -28,6 +28,7 @@ module.exports = {
items: [
'case-studies/jenkins-cicd',
'case-studies/gitops',
'case-studies/canary-blue-green',
// 'case-studies/multi-app-env-cluster',
],
},
@ -85,6 +86,7 @@ module.exports = {
'Workflow': [
'end-user/workflow/multi-env',
'end-user/workflow/webhook-notification',
'end-user/workflow/component-dependency-parameter',
]
},
{