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:
parent
2a48f3a9fb
commit
c410210500
|
|
@ -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:
|
||||
|
||||

|
||||
|
||||
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.
|
||||
|
||||

|
||||
|
||||
## 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,
|
||||
|
||||

|
||||
|
||||
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.
|
||||
|
||||
|
|
@ -1,5 +0,0 @@
|
|||
---
|
||||
title: 金丝雀发布、蓝绿发布、多泳道发布
|
||||
---
|
||||
|
||||
WIP
|
||||
|
|
@ -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)
|
||||
|
|
@ -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)
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
||||

|
||||
|
||||
In this guide, you will learn how to manage multi environments via `multi-env` in `Workflow`.
|
||||
|
||||
|
|
|
|||
|
|
@ -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 |
|
|
@ -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% 的流量切换到新版本的实例上面。
|
||||
|
||||
完成第一步之后,执行第二步工作流会进入暂停状态,等待用户校验服务状态。
|
||||
|
||||
|
|
@ -158,6 +158,6 @@ EOF
|
|||
## 下一步
|
||||
|
||||
- [组件可观测性](../../component-observability)
|
||||
- [应用组件间的依赖和参数传递](../../component-dependency-parameter)
|
||||
- [应用组件间的依赖和参数传递](../../workflow/component-dependency-parameter)
|
||||
- [多应用、多环境、多集群编排](../../../case-studies/multi-app-env-cluster)
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +0,0 @@
|
|||
---
|
||||
title: 管理交付环境
|
||||
---
|
||||
|
||||
TBD
|
||||
|
|
@ -4,7 +4,9 @@ title: 多环境交付
|
|||
|
||||
本节将介绍如何在工作流中使用多环境功能。
|
||||
|
||||
在多集群的情况下,我们首先需要在测试集群部署应用,等到测试集群的应用一切正常后,再部署到生产集群。KubeVela 提供了一个 `multi-env` 类型的工作流步骤,可以帮助用户方便的管理多环境配置。
|
||||
在多集群的情况下,我们首先需要在测试集群部署应用,等到测试集群的应用一切正常后,再部署到生产集群。KubeVela 提供了一个 `multi-env` 类型的工作流步骤,可以帮助用户方便的管理多环境配置。你可以大致了解它的工作原理,如下所示:
|
||||
|
||||

|
||||
|
||||
本节将介绍如何在工作流使用 `multi-env` 来管理多环境。
|
||||
|
||||
|
|
|
|||
|
|
@ -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 |
|
|
@ -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',
|
||||
]
|
||||
},
|
||||
{
|
||||
|
|
|
|||
Loading…
Reference in New Issue