Kruise rollout addon whole story (#723)
* add canary release for kruise rollout Signed-off-by: liheng.zms <liheng.zms@alibaba-inc.com> * update demo Signed-off-by: 楚岳 <wangyike.wyk@alibaba-inc.com> add chinese docs Signed-off-by: 楚岳 <wangyike.wyk@alibaba-inc.com> * update overview Signed-off-by: 楚岳 <wangyike.wyk@alibaba-inc.com> * fix error link Signed-off-by: 楚岳 <wangyike.wyk@alibaba-inc.com> * fix link Signed-off-by: 楚岳 <wangyike.wyk@alibaba-inc.com> * fix link Signed-off-by: 楚岳 <wangyike.wyk@alibaba-inc.com> * fix comments Signed-off-by: 楚岳 <wangyike.wyk@alibaba-inc.com> * add helm trait for every type CD Signed-off-by: 楚岳 <wangyike.wyk@alibaba-inc.com> * fix link Signed-off-by: 楚岳 <wangyike.wyk@alibaba-inc.com> * add notice Signed-off-by: 楚岳 <wangyike.wyk@alibaba-inc.com> * fix commnets Signed-off-by: 楚岳 <wangyike.wyk@alibaba-inc.com> Co-authored-by: liheng.zms <liheng.zms@alibaba-inc.com>
This commit is contained in:
wyike
GitHub
parent
2c355e06d3
commit
088191ed4f
|
|
@ -0,0 +1,265 @@
|
|||
---
|
||||
title: Canary rollout
|
||||
---
|
||||
|
||||
In this section, we will introduce how to canary rollout a container service.
|
||||
|
||||
## Before starting
|
||||
|
||||
1. Enable `kruise-rollout` addon.
|
||||
|
||||
```shell
|
||||
% vela addon enable kruise-rollout
|
||||
Addon: kruise-rollout enabled Successfully.
|
||||
```
|
||||
|
||||
|
||||
2. Please make sure one of the [ingress controllers](https://kubernetes.github.io/ingress-nginx/deploy/) is available in your Kubernetes cluster.
|
||||
If not yet, you can install one in your cluster by enable the [ingress-nginx](../../reference/addons/nginx-ingress-controller) addon:
|
||||
|
||||
```shell
|
||||
vela addon enable ingress-nginx
|
||||
```
|
||||
|
||||
Please refer [this](../../reference/addons/nginx-ingress-controller) to get the gateway's access address.
|
||||
|
||||
3. Please make sure the version of Vela-cli `>=1.5.0-alpha.1`.
|
||||
|
||||
## First Deployment
|
||||
|
||||
When you want to use the canary rollout, you need to add the `kruise-rollout` trait at the first time, this configuration will take effect in the process of next release. Deploy the application with traits like below:
|
||||
|
||||
```shell
|
||||
cat <<EOF | vela up -f -
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: canary-demo
|
||||
annotations:
|
||||
app.oam.dev/publishVersion: v1
|
||||
spec:
|
||||
components:
|
||||
- name: canary-demo
|
||||
type: webservice
|
||||
properties:
|
||||
image: barnett/canarydemo:v1
|
||||
ports:
|
||||
- port: 8090
|
||||
traits:
|
||||
- type: scaler
|
||||
properties:
|
||||
replicas: 5
|
||||
- type: gateway
|
||||
properties:
|
||||
domain: canary-demo.com
|
||||
http:
|
||||
"/version": 8090
|
||||
- type: kruise-rollout
|
||||
properties:
|
||||
canary:
|
||||
steps:
|
||||
# The first batch of Canary releases 20% Pods, and 20% traffic imported to the new version, require manual confirmation before subsequent releases are completed
|
||||
- weight: 20
|
||||
# The second batch of Canary releases 90% Pods, and 90% traffic imported to the new version.
|
||||
- weight: 90
|
||||
trafficRoutings:
|
||||
- type: nginx
|
||||
EOF
|
||||
```
|
||||
|
||||
Then check the status of application will find out the application is running.
|
||||
|
||||
```shell
|
||||
$ vela status canary-demo
|
||||
About:
|
||||
|
||||
Name: canary-demo
|
||||
Namespace: default
|
||||
Created at: 2022-06-09 16:43:10 +0800 CST
|
||||
Status: running
|
||||
|
||||
Workflow:
|
||||
|
||||
mode: DAG
|
||||
finished: true
|
||||
Suspend: false
|
||||
Terminated: false
|
||||
Steps
|
||||
- id:x6rnat7iby
|
||||
name:canary-demo
|
||||
type:apply-component
|
||||
phase:succeeded
|
||||
message:
|
||||
|
||||
Services:
|
||||
|
||||
- Name: canary-demo
|
||||
Cluster: local Namespace: default
|
||||
Type: webservice
|
||||
Healthy Ready:5/5
|
||||
Traits:
|
||||
✅ scaler ✅ gateway: No loadBalancer found, visiting by using 'vela port-forward canary-demo'
|
||||
✅ kruise-rollout: rollout is healthy
|
||||
|
||||
```
|
||||
|
||||
If you have enabled [velaux](../../reference/addons/velaux) addon you can view the application topology graph , then you will see all `v1` pods are ready now.
|
||||
|
||||
|
||||
|
||||
Access the gateway endpoint with the specific host.
|
||||
```shell
|
||||
$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
|
||||
Demo: V1
|
||||
```
|
||||
|
||||
|
||||
## Canary Release
|
||||
Modify the webservice image tag, from v1 to v2, as follows:
|
||||
|
||||
```shell
|
||||
cat <<EOF | vela up -f -
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: canary-demo
|
||||
annotations:
|
||||
app.oam.dev/publishVersion: v2
|
||||
spec:
|
||||
components:
|
||||
- name: canary-demo
|
||||
type: webservice
|
||||
properties:
|
||||
image: barnett/canarydemo:v2
|
||||
ports:
|
||||
- port: 8090
|
||||
traits:
|
||||
- type: scaler
|
||||
properties:
|
||||
replicas: 5
|
||||
- type: gateway
|
||||
properties:
|
||||
domain: canary-demo.com
|
||||
http:
|
||||
"/version": 8090
|
||||
- type: kruise-rollout
|
||||
properties:
|
||||
canary:
|
||||
# The first batch of Canary releases 20% Pods, and 20% traffic imported to the new version, require manual confirmation before subsequent releases are completed
|
||||
steps:
|
||||
- weight: 20
|
||||
- weight: 90
|
||||
trafficRoutings:
|
||||
- type: nginx
|
||||
EOF
|
||||
```
|
||||
|
||||
The configuration strategy of kruise-rollout trait means: The first batch of Canary releases 20% Pods, and 20% traffic imported to the new version, require manual confirmation before subsequent releases are completed.
|
||||
|
||||
Check the status of applciation:
|
||||
```shell
|
||||
$ vela status canary-demo
|
||||
About:
|
||||
|
||||
Name: canary-demo
|
||||
Namespace: default
|
||||
Created at: 2022-06-09 16:43:10 +0800 CST
|
||||
Status: runningWorkflow
|
||||
|
||||
Workflow:
|
||||
|
||||
mode: DAG
|
||||
finished: false
|
||||
Suspend: false
|
||||
Terminated: false
|
||||
Steps
|
||||
- id:8adxa11wku
|
||||
name:canary-demo
|
||||
type:apply-component
|
||||
phase:running
|
||||
message:wait healthy
|
||||
|
||||
Services:
|
||||
|
||||
- Name: canary-demo
|
||||
Cluster: local Namespace: default
|
||||
Type: webservice
|
||||
Unhealthy Ready:5/5
|
||||
Traits:
|
||||
✅ scaler ✅ gateway: No loadBalancer found, visiting by using 'vela port-forward canary-demo'
|
||||
❌ kruise-rollout: Rollout is in step(1/1), and you need manually confirm to enter the next step
|
||||
|
||||
```
|
||||
|
||||
The application's status is `runningWorkflow` that means the application's rollout process has not finished yet.
|
||||
|
||||
View topology graph again, you will see `kruise-rollout` trait created a `v2` pod, and this pod will serve the canary traffic. Meanwhile, the pods of `v1` are still running and server non-canary traffic.
|
||||
|
||||
|
||||
|
||||
Access the gateway endpoint again. You will find out there is about 20% chance to meet `Demo: v2` result.
|
||||
|
||||
```shell
|
||||
$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
|
||||
Demo: V2
|
||||
```
|
||||
|
||||
## Continue rollout process
|
||||
|
||||
After verify the success of the canary version through business-related metrics, such as logs, metrics, and other means, you can resume the workflow to continue the process of rollout.
|
||||
|
||||
```shell
|
||||
vela workflow resume canary-demo
|
||||
```
|
||||
|
||||
Access the gateway endpoint again multi times. You will find out the chance to meet result `Demo: v2` is highly increased, almost 90%.
|
||||
|
||||
```shell
|
||||
$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
|
||||
Demo: V2
|
||||
```
|
||||
|
||||
## Canary validation successful, full release
|
||||
|
||||
In the end, you can resume again to finish the rollout process.
|
||||
|
||||
```shell
|
||||
vela workflow resume canary-demo
|
||||
```
|
||||
|
||||
Access the gateway endpoint again multi times. You will find out the result always is `Demo: v2`.
|
||||
|
||||
```shell
|
||||
$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
|
||||
Demo: V2
|
||||
```
|
||||
|
||||
## Canary verification failed, rollback
|
||||
|
||||
If you want to cancel the rollout process and rollback the application to the latest version, after manually check. You can rollback the rollout workflow:
|
||||
|
||||
You should suspend the workflow before rollback:
|
||||
```shell
|
||||
$ vela workflow suspend canary-demo
|
||||
Rollout default/canary-demo in cluster suspended.
|
||||
Successfully suspend workflow: canary-demo
|
||||
```
|
||||
|
||||
Then rollback:
|
||||
```shell
|
||||
$ vela workflow rollback canary-demo
|
||||
Application spec rollback successfully.
|
||||
Application status rollback successfully.
|
||||
Rollout default/canary-demo in cluster rollback.
|
||||
Successfully rollback rolloutApplication outdated revision cleaned up.
|
||||
```
|
||||
|
||||
Access the gateway endpoint again. You can see the result always is `Demo: V1`.
|
||||
```shell
|
||||
$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
|
||||
Demo: V1
|
||||
```
|
||||
|
||||
Please notice: rollback operation in middle of a runningWorkflow will rollback to latest succeed revision which is `v1` in this case.
|
||||
Image a scenario, you deploy a successful `v1` and canary rollout to `v2`, but you find some error in this version, then you continue to rollout to `v3` directly. Error still exists, application is unhealthy then you decide to rollback.
|
||||
When you execute rollback workload will let application rollback to version `v1`.
|
||||
|
|
@ -0,0 +1,103 @@
|
|||
---
|
||||
title: kruise-rollout
|
||||
---
|
||||
|
||||
Kruise Rollout addon provides canary release capabilities for Kubernetes Deployment, Statefulset and OpenKruise CloneSet.
|
||||
For more details, please refer to: [Kruise Rollout](https://github.com/openkruise/rollouts/blob/master/docs/getting_started/introduction.md).
|
||||
|
||||
|
||||
## Installation
|
||||
|
||||
```shell
|
||||
$ vela addon enable kruise-rollout
|
||||
Addon: kruise-rollout enabled Successfully.
|
||||
```
|
||||
|
||||
## Uninstallation
|
||||
|
||||
```shell
|
||||
$ vela addon disable kruise-rollout
|
||||
```
|
||||
|
||||
## Usage
|
||||
|
||||
Kurise rollout addon help to canary rollout your workload no matter defined with [webservice](../../end-user/components/cue/webservice) or contained in a [helm](../../tutorials/helm).
|
||||
|
||||
If your workload is in a helm chart please refer to [doc](../../tutorials/helm-rollout) for more usage info, otherwise please refer to usage of webservice [component](../../end-user/traits/rollout).
|
||||
|
||||
### Properties
|
||||
|
||||
Name | Description | Type | Required | Default
|
||||
------------ | ------------- | ------------- | ------------- | -------------
|
||||
canary| Configuration for canary rollout strategy| [Canary](#Canary)| true|
|
||||
workloadType| Specify the target worklaod type| [WorkloadType](#WorkloadType)|false
|
||||
|
||||
#### Canary
|
||||
|
||||
Name | Description | Type | Required | Default
|
||||
------------ | ------------- | ------------- | ------------- | -------------
|
||||
steps| Defines the entire rollout process in steps | [CanaryStep](#CanaryStep)|true
|
||||
trafficRoutings| Define traffic routing related service, ingress information | [[]TrafficRouting](#TrafficRouting)| true
|
||||
|
||||
|
||||
##### CanaryStep
|
||||
|
||||
Name | Description | Type | Required | Default
|
||||
------------ | ------------- | ------------- | ------------- | -------------
|
||||
weight| Define the percentage of traffic routing to the new version in each step, e.g., 20%, 40%...| int|false
|
||||
replicas| Define the replicas of release to the new version in each step, e.g., 5, 10...| int| false
|
||||
duration| Define the behavior after release each step, if not filled, the default requires manual determination. If filled, it indicates the time to wait in seconds, e.g., 60| int|false
|
||||
|
||||
##### TrafficRouting
|
||||
|
||||
Name | Description | Type | Required | Default
|
||||
------------ | ------------- | ------------- | ------------- | -------------
|
||||
service| Define service name | stirng | false | context.name
|
||||
ingressName| Define ingress name | string | false | context.name
|
||||
|
||||
##### WorkloadType
|
||||
|
||||
Name | Description | Type | Required | Default
|
||||
------------ | ------------- | ------------- | ------------- | -------------
|
||||
apiVersion| Target workload's apiVersion| string| true
|
||||
kind| Target workload's kind | string | true
|
||||
|
||||
## Example
|
||||
|
||||
```yaml
|
||||
cat <<EOF | vela up -f -
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: canary-demo
|
||||
annotations:
|
||||
app.oam.dev/publishVersion: v1
|
||||
spec:
|
||||
components:
|
||||
- name: canary-demo
|
||||
type: webservice
|
||||
properties:
|
||||
image: barnett/canarydemo:v1
|
||||
ports:
|
||||
- port: 8090
|
||||
traits:
|
||||
- type: scaler
|
||||
properties:
|
||||
replicas: 5
|
||||
- type: gateway
|
||||
properties:
|
||||
domain: canary-demo.com
|
||||
http:
|
||||
"/version": 8090
|
||||
- type: kruise-rollout
|
||||
properties:
|
||||
canary:
|
||||
steps:
|
||||
# The first batch of Canary releases 20% Pods, and 20% traffic imported to the new version, require manual confirmation before subsequent releases are completed
|
||||
- weight: 20
|
||||
# The second batch of Canary releases 90% Pods, and 90% traffic imported to the new version.
|
||||
- weight: 90
|
||||
trafficRoutings:
|
||||
- type: nginx
|
||||
EOF
|
||||
```
|
||||
|
|
@ -0,0 +1,82 @@
|
|||
---
|
||||
title: Nginx Ingress Controller
|
||||
---
|
||||
|
||||
|
||||
[Nginx Ingress controller](https://kubernetes.github.io/ingress-nginx/) is an Ingress controller for Kubernetes using NGINX as a reverse proxy and load balancer.
|
||||
|
||||
**Notice: If your cluster is already have any kinds of [ingress controller](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/), you don't need to enable this addon.**
|
||||
|
||||
## Install
|
||||
|
||||
```shell
|
||||
vela addon enable ingrss-controller
|
||||
```
|
||||
|
||||
## Setup with Specified Service Type
|
||||
|
||||
There are three service types for this addon which aligned with Kubernetes service, they're `ClusterIP`, `NodePort` and `LoadBalancer`.
|
||||
By default, the service type is ClusterIP for security.
|
||||
|
||||
- `LoadBalancer` type requires your cluster has cloud LoadBalancer available.
|
||||
```shell script
|
||||
vela addon enable ingrss-controller serviceType=LoadBalancer
|
||||
```
|
||||
- `NodePort` type requires you can access the Kubernetes Node IP/Port.
|
||||
```shell script
|
||||
vela addon enable ingrss-controller serviceType=NodePort
|
||||
```
|
||||
|
||||
## Get access address
|
||||
|
||||
After specify the service type to `LoadBalancer` or `NodePort`, you can obtain the access address through `vela status`:
|
||||
|
||||
```shell
|
||||
vela status addon-ingrss-controller -n vela-system --endpoint
|
||||
```
|
||||
|
||||
If the service type is `ClusterIP`, you use `vela port-forward` map the ingrss-controller's port to local
|
||||
|
||||
```shell
|
||||
vela port-forward -n vela-system addon-ingress-controller 9080:80
|
||||
```
|
||||
|
||||
## Uninstall
|
||||
|
||||
```shell
|
||||
vela addon disable ingrss-controller
|
||||
```
|
||||
|
||||
## Example
|
||||
|
||||
Use this addon by deploy an application:
|
||||
|
||||
```yaml
|
||||
cat <<EOF | vela up -f -
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: demo
|
||||
spec:
|
||||
components:
|
||||
- name: demo
|
||||
type: webservice
|
||||
properties:
|
||||
image: barnett/canarydemo:v1
|
||||
ports:
|
||||
- port: 8090
|
||||
traits:
|
||||
- type: gateway
|
||||
properties:
|
||||
domain: canary-demo.com
|
||||
http:
|
||||
"/version": 8090
|
||||
EOF
|
||||
```
|
||||
|
||||
Then access the gateway's endpoint will see:
|
||||
|
||||
```shell
|
||||
$ curl -H "Host: canary-demo.com" <ingress-controller-endpoint>/version
|
||||
Demo: V1
|
||||
```
|
||||
|
|
@ -20,5 +20,7 @@ There's an community addon registry (https://addons.kubevela.net) maintained by
|
|||
* [KubeVela doc](./kubevela-io) Help you to read the KubeVela document in your cluster which can be air-gaped environment.
|
||||
* [Flink kubernetes operator](./flink-kubernetes-operator) A Kubernetes operator for Apache Flink(https://github.com/apache/flink-kubernetes-operator).
|
||||
* [dex](./dex) Provide [dex](https://github.com/dexidp/dex) login for VelaUX.
|
||||
* [Kruise Rollout](./kruise-rollout): [OpenKruise rollout](https://github.com/openkruise/rollouts) supports canary rollout for native deployment, stateful-set and OpenKruise [cloneset](https://openkruise.io/docs/user-manuals/cloneset/).
|
||||
* [ingress-nginx](./nginx-ingress-controller): An Ingress controller for Kubernetes using NGINX as a reverse proxy and load balancer.
|
||||
|
||||
**If you want to make your own addon please refer to [doc](../../platform-engineers/addon/intro.md).**
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 83 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 103 KiB |
|
|
@ -0,0 +1,184 @@
|
|||
---
|
||||
title: Canary Rollout Helm chart
|
||||
---
|
||||
|
||||
## Before starting
|
||||
|
||||
1. Please make sure you have read the doc of about [deploying helm chart](./helm).
|
||||
|
||||
2. Make sure you have already enableld the kruise-rollout addon.
|
||||
```shell
|
||||
% vela addon enable kruise-rollout
|
||||
Addon: kruise-rollout enabled Successfully.
|
||||
```
|
||||
|
||||
3. Please make sure one of the [ingress controllers](https://kubernetes.github.io/ingress-nginx/deploy/) is available in your Kubernetes cluster.
|
||||
If not, you can install one in your cluster by enable the [ingress-nginx](../reference/addons/nginx-ingress-controller) addon:
|
||||
|
||||
```shell
|
||||
vela addon enable ingress-nginx
|
||||
```
|
||||
|
||||
Please refer [this](../reference/addons/nginx-ingress-controller) to get the gateway's access address.
|
||||
|
||||
**You also can choose to install [traefik](../reference/addons/traefik) addon.**
|
||||
|
||||
4. Please make sure the version of Vela CLI tool `>=1.5.0-alpha.1`, some commands such as rollback rely on the new version.
|
||||
|
||||
### First deployment
|
||||
|
||||
When you want to use the canary rollout, you need to add the `kruise-rollout` trait at the first time, this configuration will take effect at next release process. Deploy the application with traits like below:
|
||||
|
||||
```shell
|
||||
cat <<EOF | vela up -f -
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: canary-demo
|
||||
annotations:
|
||||
app.oam.dev/publishVersion: v1
|
||||
spec:
|
||||
components:
|
||||
- name: canary-demo
|
||||
type: helm
|
||||
properties:
|
||||
repoType: "helm"
|
||||
url: "https://wangyikewxgm.github.io/my-charts/"
|
||||
chart: "canary-demo"
|
||||
version: "1.0.0"
|
||||
traits:
|
||||
- type: kruise-rollout
|
||||
properties:
|
||||
canary:
|
||||
# The first batch of Canary releases 20% Pods, and 20% traffic imported to the new version, require manual confirmation before subsequent releases are completed
|
||||
steps:
|
||||
- weight: 20
|
||||
# The second batch of Canary releases 90% Pods, and 90% traffic imported to the new version.
|
||||
- weight: 90
|
||||
trafficRoutings:
|
||||
- type: nginx
|
||||
EOF
|
||||
```
|
||||
|
||||
This is a general helm chart created by `helm create` command, which contains a deployment whose image is `barnett/canarydemo:v1`, a service and an ingress. You can check the source of chart in [repo](https://github.com/wangyikewxgm/my-charts/tree/main/canary-demo).
|
||||
|
||||
Access the gateway endpoint. You can see the result always is `Demo: V1`
|
||||
```shell
|
||||
$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
|
||||
Demo: V1
|
||||
```
|
||||
|
||||
### Canary Rollout
|
||||
|
||||
Update the target version of helm chart from `1.0.0` to `2.0.0`:
|
||||
|
||||
```shell
|
||||
cat <<EOF | vela up -f -
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: canary-demo
|
||||
annotations:
|
||||
app.oam.dev/publishVersion: v2
|
||||
spec:
|
||||
components:
|
||||
- name: canary-demo
|
||||
type: helm
|
||||
properties:
|
||||
repoType: "helm"
|
||||
url: "https://wangyikewxgm.github.io/my-charts/"
|
||||
chart: "canary-demo"
|
||||
# Upgade to version 2.0.0
|
||||
version: "2.0.0"
|
||||
traits:
|
||||
- type: kruise-rollout
|
||||
properties:
|
||||
canary:
|
||||
# The first batch of Canary releases 20% Pods, and 20% traffic imported to the new version, require manual confirmation before subsequent releases are completed
|
||||
steps:
|
||||
- weight: 20
|
||||
# The second batch of Canary releases 90% Pods, and 90% traffic imported to the new version.
|
||||
- weight: 90
|
||||
trafficRoutings:
|
||||
- type: nginx
|
||||
EOF
|
||||
```
|
||||
|
||||
The only difference between two versions is image tag. Version `2.0.0` uses `barnett/canarydemo:v2`.
|
||||
|
||||
Access the gateway endpoint again. You will find out there is about 20% chance to meet `Demo: v2` result.
|
||||
|
||||
```shell
|
||||
$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
|
||||
Demo: V2
|
||||
```
|
||||
|
||||
The other operations such as `continue rollout/rollback` are totally same with the operation for webservice component.
|
||||
|
||||
|
||||
### Continue rollout process
|
||||
|
||||
After verify the success of the canary version through business-related metrics, such as logs, metrics, and other means, you can resume the workflow to continue the process of rollout.
|
||||
|
||||
```shell
|
||||
vela workflow resume canary-demo
|
||||
```
|
||||
|
||||
Access the gateway endpoint again multi times. You will find out the chance to meet result `Demo: v2` is highly increased, almost 90%.
|
||||
|
||||
```shell
|
||||
$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
|
||||
Demo: V2
|
||||
```
|
||||
|
||||
### Canary validation successful, full release
|
||||
|
||||
In the end, you can resume again to finish the rollout process.
|
||||
|
||||
```shell
|
||||
vela workflow resume canary-demo
|
||||
```
|
||||
|
||||
Access the gateway endpoint again multi times. You will find out the result always is `Demo: v2`.
|
||||
|
||||
```shell
|
||||
$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
|
||||
Demo: V2
|
||||
```
|
||||
|
||||
### Canary verification failed, rollback
|
||||
|
||||
If you want to cancel the rollout process and rollback the application to the latest version, after manually check. You can rollback the rollout workflow:
|
||||
|
||||
You should suspend the workflow before rollback:
|
||||
```shell
|
||||
$ vela workflow suspend canary-demo
|
||||
Rollout default/canary-demo in cluster suspended.
|
||||
Successfully suspend workflow: canary-demo
|
||||
```
|
||||
|
||||
Then rollback:
|
||||
```shell
|
||||
$ vela workflow rollback canary-demo
|
||||
Application spec rollback successfully.
|
||||
Application status rollback successfully.
|
||||
Rollout default/canary-demo in cluster rollback.
|
||||
Successfully rollback rolloutApplication outdated revision cleaned up.
|
||||
```
|
||||
|
||||
Access the gateway endpoint again. You can see the result always is `Demo: V1`.
|
||||
```shell
|
||||
$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
|
||||
Demo: V1
|
||||
```
|
||||
|
||||
Please notice: rollback operation in middle of a runningWorkflow will rollback to latest succeed revision which is `v1` in this case.
|
||||
Image a scenario, you deploy a successful `v1` and canary rollout to `v2`, but you find some error in this version, then you continue to rollout to `v3` directly. Error still exists, application is unhealthy then you decide to rollback.
|
||||
When you execute rollback workload will let application rollback to version `v1`.
|
||||
|
||||
##Limitation
|
||||
|
||||
1. As you can see, the helm chart used in this tutorial contains a service point to workload, an ingress route to the service.
|
||||
If your helm chart doesn't have service or ingress that need not exposure the service, you cannot reproduce the canary rollout with this chart.
|
||||
|
||||
2. Currently, canary rollout has supported several types of workloads such as deployment, statefulset, and [open-kruise cloneset](https://openkruise.io/docs/user-manuals/cloneset/). That means the workload in your helm chart must be one of this three types.
|
||||
|
|
@ -0,0 +1,310 @@
|
|||
---
|
||||
title: Canary Rollout Kubernetes Objects
|
||||
---
|
||||
|
||||
## Before starting
|
||||
|
||||
1. Please make sure you have read the doc of about [deploying helm chart](./helm).
|
||||
|
||||
2. Make sure you have already enableld the kruise-rollout addon.
|
||||
```shell
|
||||
% vela addon enable kruise-rollout
|
||||
Addon: kruise-rollout enabled Successfully.
|
||||
```
|
||||
|
||||
3. Please make sure one of the [ingress controllers](https://kubernetes.github.io/ingress-nginx/deploy/) is available in your Kubernetes cluster.
|
||||
If not, you can install one in your cluster by enable the [ingress-nginx](../reference/addons/nginx-ingress-controller) addon:
|
||||
|
||||
```shell
|
||||
vela addon enable ingress-nginx
|
||||
```
|
||||
|
||||
Please refer [this](../reference/addons/nginx-ingress-controller) to get the gateway's access address.
|
||||
|
||||
**You also can choose to install [traefik](../reference/addons/traefik) addon.**
|
||||
|
||||
4. Please make sure the version of Vela CLI tool `>=1.5.0-alpha.1`, some commands such as rollback rely on the new version.
|
||||
|
||||
### First deployment
|
||||
|
||||
```shell
|
||||
cat <<EOF | vela up -f -
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: canary-demo
|
||||
namespace: default
|
||||
annotations:
|
||||
app.oam.dev/publishVersion: v1
|
||||
spec:
|
||||
components:
|
||||
- name: canary-demo
|
||||
properties:
|
||||
objects:
|
||||
- apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: canary-demo
|
||||
spec:
|
||||
replicas: 5
|
||||
selector:
|
||||
matchLabels:
|
||||
app: demo
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: demo
|
||||
spec:
|
||||
containers:
|
||||
- image: barnett/canarydemo:v1
|
||||
name: demo
|
||||
ports:
|
||||
- containerPort: 8090
|
||||
- apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
labels:
|
||||
app: demo
|
||||
name: canary-demo
|
||||
namespace: default
|
||||
spec:
|
||||
ports:
|
||||
- name: http
|
||||
port: 8090
|
||||
protocol: TCP
|
||||
targetPort: 8090
|
||||
selector:
|
||||
app: demo
|
||||
- apiVersion: networking.k8s.io/v1
|
||||
kind: Ingress
|
||||
metadata:
|
||||
labels:
|
||||
app: demo
|
||||
name: canary-demo
|
||||
namespace: default
|
||||
spec:
|
||||
ingressClassName: nginx
|
||||
rules:
|
||||
- host: canary-demo.com
|
||||
http:
|
||||
paths:
|
||||
- backend:
|
||||
service:
|
||||
name: canary-demo
|
||||
port:
|
||||
number: 8090
|
||||
path: /version
|
||||
pathType: ImplementationSpecific
|
||||
type: k8s-objects
|
||||
traits:
|
||||
- type: kruise-rollout
|
||||
properties:
|
||||
canary:
|
||||
steps:
|
||||
# The first batch of Canary releases 20% Pods, and 20% traffic imported to the new version, require manual confirmation before subsequent releases are completed
|
||||
- weight: 20
|
||||
# The second batch of Canary releases 90% Pods, and 90% traffic imported to the new version.
|
||||
- weight: 90
|
||||
trafficRoutings:
|
||||
- type: nginx
|
||||
EOF
|
||||
```
|
||||
|
||||
Access the gateway endpoint with the specific host.
|
||||
```shell
|
||||
$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
|
||||
Demo: V1
|
||||
```
|
||||
|
||||
|
||||
## Canary Release
|
||||
Modify the image tag, from v1 to v2, as follows:
|
||||
|
||||
```shell
|
||||
cat <<EOF | vela up -f -
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: canary-demo
|
||||
namespace: default
|
||||
annotations:
|
||||
app.oam.dev/publishVersion: v2
|
||||
spec:
|
||||
components:
|
||||
- name: canary-demo
|
||||
properties:
|
||||
objects:
|
||||
- apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: canary-demo
|
||||
spec:
|
||||
replicas: 5
|
||||
selector:
|
||||
matchLabels:
|
||||
app: demo
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: demo
|
||||
spec:
|
||||
containers:
|
||||
- image: barnett/canarydemo:v2
|
||||
name: demo
|
||||
ports:
|
||||
- containerPort: 8090
|
||||
- apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
labels:
|
||||
app: demo
|
||||
name: canary-demo
|
||||
namespace: default
|
||||
spec:
|
||||
ports:
|
||||
- name: http
|
||||
port: 8090
|
||||
protocol: TCP
|
||||
targetPort: 8090
|
||||
selector:
|
||||
app: demo
|
||||
- apiVersion: networking.k8s.io/v1
|
||||
kind: Ingress
|
||||
metadata:
|
||||
labels:
|
||||
app: demo
|
||||
name: canary-demo
|
||||
namespace: default
|
||||
spec:
|
||||
ingressClassName: nginx
|
||||
rules:
|
||||
- host: canary-demo.com
|
||||
http:
|
||||
paths:
|
||||
- backend:
|
||||
service:
|
||||
name: canary-demo
|
||||
port:
|
||||
number: 8090
|
||||
path: /version
|
||||
pathType: ImplementationSpecific
|
||||
type: k8s-objects
|
||||
traits:
|
||||
- type: kruise-rollout
|
||||
properties:
|
||||
canary:
|
||||
steps:
|
||||
# The first batch of Canary releases 20% Pods, and 20% traffic imported to the new version, require manual confirmation before subsequent releases are completed
|
||||
- weight: 20
|
||||
# The second batch of Canary releases 90% Pods, and 90% traffic imported to the new version.
|
||||
- weight: 90
|
||||
trafficRoutings:
|
||||
- type: nginx
|
||||
EOF
|
||||
```
|
||||
|
||||
The configuration strategy of kruise-rollout trait means: The first batch of Canary releases 20% Pods, and 20% traffic imported to the new version, require manual confirmation before subsequent releases are completed.
|
||||
|
||||
Check the status of applciation:
|
||||
```shell
|
||||
$ vela status canary-demo
|
||||
About:
|
||||
|
||||
Name: canary-demo
|
||||
Namespace: default
|
||||
Created at: 2022-06-09 16:43:10 +0800 CST
|
||||
Status: runningWorkflow
|
||||
|
||||
Workflow:
|
||||
|
||||
mode: DAG
|
||||
finished: false
|
||||
Suspend: false
|
||||
Terminated: false
|
||||
Steps
|
||||
- id:8adxa11wku
|
||||
name:canary-demo
|
||||
type:apply-component
|
||||
phase:running
|
||||
message:wait healthy
|
||||
|
||||
Services:
|
||||
|
||||
- Name: canary-demo
|
||||
Cluster: local Namespace: default
|
||||
Type: webservice
|
||||
Unhealthy Ready:5/5
|
||||
Traits:
|
||||
✅ scaler ✅ gateway: No loadBalancer found, visiting by using 'vela port-forward canary-demo'
|
||||
❌ kruise-rollout: Rollout is in step(1/1), and you need manually confirm to enter the next step
|
||||
|
||||
```
|
||||
|
||||
The application's status is `runningWorkflow` that means the application's rollout process has not finished yet.
|
||||
|
||||
Access the gateway endpoint again. You will find out there is about 20% chance to meet `Demo: v2` result.
|
||||
|
||||
```shell
|
||||
$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
|
||||
Demo: V2
|
||||
```
|
||||
|
||||
## Continue rollout process
|
||||
|
||||
After verify the success of the canary version through business-related metrics, such as logs, metrics, and other means, you can resume the workflow to continue the process of rollout.
|
||||
|
||||
```shell
|
||||
vela workflow resume canary-demo
|
||||
```
|
||||
|
||||
Access the gateway endpoint again multi times. You will find out the chance to meet result `Demo: v2` is highly increased, almost 90%.
|
||||
|
||||
```shell
|
||||
$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
|
||||
Demo: V2
|
||||
```
|
||||
|
||||
## Canary validation successful, full release
|
||||
|
||||
In the end, you can resume again to finish the rollout process.
|
||||
|
||||
```shell
|
||||
vela workflow resume canary-demo
|
||||
```
|
||||
|
||||
Access the gateway endpoint again multi times. You will find out the result always is `Demo: v2`.
|
||||
|
||||
```shell
|
||||
$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
|
||||
Demo: V2
|
||||
```
|
||||
|
||||
## Canary verification failed, rollback
|
||||
|
||||
If you want to cancel the rollout process and rollback the application to the latest version, after manually check. You can rollback the rollout workflow:
|
||||
|
||||
You should suspend the workflow before rollback:
|
||||
```shell
|
||||
$ vela workflow suspend canary-demo
|
||||
Rollout default/canary-demo in cluster suspended.
|
||||
Successfully suspend workflow: canary-demo
|
||||
```
|
||||
|
||||
Then rollback:
|
||||
```shell
|
||||
$ vela workflow rollback canary-demo
|
||||
Application spec rollback successfully.
|
||||
Application status rollback successfully.
|
||||
Rollout default/canary-demo in cluster rollback.
|
||||
Successfully rollback rolloutApplication outdated revision cleaned up.
|
||||
```
|
||||
|
||||
Access the gateway endpoint again. You can see the result always is `Demo: V1`.
|
||||
```shell
|
||||
$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
|
||||
Demo: V1
|
||||
```
|
||||
|
||||
**Please notice**: rollback operation in middle of a runningWorkflow will rollback to latest succeed revision which is `v1` in this case.
|
||||
Image a scenario, you deploy a successful `v1` and canary rollout to `v2`, but you find some error in this version, then you continue to rollout to `v3` directly. Error still exists, application is unhealthy then you decide to rollback.
|
||||
When you execute rollback workload will let application rollback to version `v1`.
|
||||
|
|
@ -0,0 +1,310 @@
|
|||
---
|
||||
title: Kruise-rollout
|
||||
---
|
||||
|
||||
Kruise Rollout对原生Deployment、Kruise CloneSet提供渐进式交付的能力，例如：金丝雀发布、蓝绿发布、A/B Testing等，更多详情请参考：[Kruise Rollout](https://github.com/openkruise/rollouts/blob/master/docs/getting_started/introduction.md)。
|
||||
|
||||
本文主要介绍如何使用Kruise Rollout实现金丝雀发布。
|
||||
|
||||
## 准备工作
|
||||
|
||||
1. 安装Kruise Rollout
|
||||
```shell
|
||||
% vela addon enable kruise-rollout
|
||||
enable addon by local dir: addons/kruise-rollout
|
||||
Addon: kruise-rollout enabled Successfully.
|
||||
```
|
||||
|
||||
2. 请保证你的集群有一种 [ingress controllers](https://kubernetes.github.io/ingress-nginx/deploy/) 正在运行。
|
||||
如果没有你可以通过启用 [nginx-ingress-controller](./nginx-ingress-controller) 安装一个。
|
||||
|
||||
```shell
|
||||
vela addon enable ingress-controller
|
||||
```
|
||||
|
||||
请参考[文档](./nginx-ingress-controller) 获取网关的访问地址。
|
||||
|
||||
## 首次部署
|
||||
|
||||
部署应用:
|
||||
|
||||
```shell
|
||||
cat <<EOF | vela up -f -
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: canary-demo
|
||||
annotations:
|
||||
app.oam.dev/publishVersion: v1
|
||||
spec:
|
||||
components:
|
||||
- name: canary-demo
|
||||
type: webservice
|
||||
properties:
|
||||
image: barnett/canarydemo:v1
|
||||
ports:
|
||||
- port: 8090
|
||||
traits:
|
||||
- type: scaler
|
||||
properties:
|
||||
replicas: 5
|
||||
- type: gateway
|
||||
properties:
|
||||
domain: canary-demo.com
|
||||
http:
|
||||
"/version": 8090
|
||||
- type: kruise-rollout
|
||||
properties:
|
||||
canary:
|
||||
# The first batch of Canary releases 20% Pods, and 20% traffic imported to the new version, require manual confirmation before subsequent releases are completed
|
||||
steps:
|
||||
- weight: 20
|
||||
trafficRoutings:
|
||||
- type: nginx
|
||||
EOF
|
||||
```
|
||||
|
||||
检查应用状态，发现应用已经出于 `Running` 状态。
|
||||
|
||||
|
||||
```shell
|
||||
$ vela status canary-demo
|
||||
About:
|
||||
|
||||
Name: canary-demo
|
||||
Namespace: default
|
||||
Created at: 2022-06-09 16:43:10 +0800 CST
|
||||
Status: running
|
||||
|
||||
Workflow:
|
||||
|
||||
mode: DAG
|
||||
finished: true
|
||||
Suspend: false
|
||||
Terminated: false
|
||||
Steps
|
||||
- id:x6rnat7iby
|
||||
name:canary-demo
|
||||
type:apply-component
|
||||
phase:succeeded
|
||||
message:
|
||||
|
||||
Services:
|
||||
|
||||
- Name: canary-demo
|
||||
Cluster: local Namespace: default
|
||||
Type: webservice
|
||||
Healthy Ready:5/5
|
||||
Traits:
|
||||
✅ scaler ✅ gateway: No loadBalancer found, visiting by using 'vela port-forward canary-demo'
|
||||
✅ kruise-rollout: rollout is healthy
|
||||
|
||||
```
|
||||
|
||||
用上面定义的路径和 Host 访问网关:
|
||||
|
||||
```shell
|
||||
$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
|
||||
Demo: V1
|
||||
```
|
||||
|
||||
## 金丝雀发布
|
||||
修改镜像标签 v1 -> v2：
|
||||
|
||||
```shell
|
||||
cat <<EOF | vela up -f -
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: canary-demo
|
||||
annotations:
|
||||
app.oam.dev/publishVersion: v2
|
||||
spec:
|
||||
components:
|
||||
- name: canary-demo
|
||||
type: webservice
|
||||
properties:
|
||||
image: barnett/canarydemo:v2
|
||||
ports:
|
||||
- port: 8090
|
||||
traits:
|
||||
- type: scaler
|
||||
properties:
|
||||
replicas: 5
|
||||
- type: gateway
|
||||
properties:
|
||||
domain: canary-demo.com
|
||||
http:
|
||||
"/version": 8090
|
||||
- type: kruise-rollout
|
||||
properties:
|
||||
canary:
|
||||
# The first batch of Canary releases 20% Pods, and 20% traffic imported to the new version, require manual confirmation before subsequent releases are completed
|
||||
steps:
|
||||
- weight: 20
|
||||
trafficRoutings:
|
||||
- type: nginx
|
||||
EOF
|
||||
```
|
||||
|
||||
请注意这里的 kurise-rollout 运维特征里升级策略的配置，这里的含义是先金丝雀发布一批，该批次包含了20%的实例个数，并将20%的流量导入到新版本实例中。
|
||||
检查 app 的状态：
|
||||
```shell
|
||||
$ vela status canary-demo
|
||||
About:
|
||||
|
||||
Name: canary-demo
|
||||
Namespace: default
|
||||
Created at: 2022-06-09 16:43:10 +0800 CST
|
||||
Status: runningWorkflow
|
||||
|
||||
Workflow:
|
||||
|
||||
mode: DAG
|
||||
finished: false
|
||||
Suspend: false
|
||||
Terminated: false
|
||||
Steps
|
||||
- id:8adxa11wku
|
||||
name:canary-demo
|
||||
type:apply-component
|
||||
phase:running
|
||||
message:wait healthy
|
||||
|
||||
Services:
|
||||
|
||||
- Name: canary-demo
|
||||
Cluster: local Namespace: default
|
||||
Type: webservice
|
||||
Unhealthy Ready:5/5
|
||||
Traits:
|
||||
✅ scaler ✅ gateway: No loadBalancer found, visiting by using 'vela port-forward canary-demo'
|
||||
❌ kruise-rollout: Rollout is in step(1/1), and you need manually confirm to enter the next step
|
||||
|
||||
```
|
||||
|
||||
application 的状态处于 `runningWorkflow` 意味着发布尚未完成。
|
||||
再次访问网关，你会发现有20%的机率看到新版本的结果 `Demo: v2`:
|
||||
|
||||
```shell
|
||||
$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
|
||||
Demo: V2
|
||||
```
|
||||
|
||||
## 金丝雀验证OK，全量发布
|
||||
|
||||
用户通过业务的相关指标，如：日志、Metrics等其它手段，验证金丝雀版本OK之后，继续执行工作流发布继续发布。
|
||||
|
||||
|
||||
```shell
|
||||
vela workflow resume canary-demo
|
||||
```
|
||||
|
||||
## 金丝雀验证失败，回滚
|
||||
|
||||
如果经过验证发现新版本有问题，你想中断发布，将应用回滚至上一个版本。可以如下操作：
|
||||
|
||||
```shell
|
||||
vela workflow rollback canary-demo
|
||||
```
|
||||
|
||||
回滚完成之后，访问网关，你会发现结果一直都是 `Demo: V1`：
|
||||
|
||||
```shell
|
||||
$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
|
||||
Demo: V1
|
||||
```
|
||||
|
||||
## Helm 应用的金丝雀发布
|
||||
|
||||
### 首次部署：
|
||||
|
||||
|
||||
```shell
|
||||
cat <<EOF | vela up -f -
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: canary-demo
|
||||
annotations:
|
||||
app.oam.dev/publishVersion: v1
|
||||
spec:
|
||||
components:
|
||||
- name: canary-demo
|
||||
type: helm
|
||||
properties:
|
||||
repoType: "helm"
|
||||
url: "https://wangyikewxgm.github.io/my-charts/"
|
||||
chart: "canary-demo"
|
||||
version: "1.0.0"
|
||||
traits:
|
||||
- type: kruise-rollout
|
||||
properties:
|
||||
workloadType:
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
canary:
|
||||
# The first batch of Canary releases 20% Pods, and 20% traffic imported to the new version, require manual confirmation before subsequent releases are completed
|
||||
steps:
|
||||
- weight: 20
|
||||
trafficRoutings:
|
||||
- type: nginx
|
||||
EOF
|
||||
```
|
||||
|
||||
应用所使用的 chart 中包含了一个使用了 `barnett/canarydemo:v1` 镜像的 Deployment。
|
||||
|
||||
另外，请注意你需要天蝎 kruise-rollout trait 中 `workloadType` 的字段，因为一个 chart 中可能包含各种资源，你需要指出发布资源的类型。
|
||||
|
||||
部署成功之后，访问网关：
|
||||
```shell
|
||||
$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
|
||||
Demo: V1
|
||||
```
|
||||
|
||||
### 金丝雀发布
|
||||
|
||||
通过下面的步骤将 chart 的版本从 `1.0.0` 更新到 `2.0.0`：
|
||||
|
||||
|
||||
```shell
|
||||
cat <<EOF | vela up -f -
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: canary-demo
|
||||
annotations:
|
||||
app.oam.dev/publishVersion: v2
|
||||
spec:
|
||||
components:
|
||||
- name: canary-demo
|
||||
type: helm
|
||||
properties:
|
||||
repoType: "helm"
|
||||
url: "https://wangyikewxgm.github.io/my-charts/"
|
||||
chart: "canary-demo"
|
||||
# Upgade to version 2.0.0
|
||||
version: "2.0.0"
|
||||
traits:
|
||||
- type: kruise-rollout
|
||||
properties:
|
||||
workloadType:
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
canary:
|
||||
# The first batch of Canary releases 20% Pods, and 20% traffic imported to the new version, require manual confirmation before subsequent releases are completed
|
||||
steps:
|
||||
- weight: 20
|
||||
trafficRoutings:
|
||||
- type: nginx
|
||||
EOF
|
||||
```
|
||||
|
||||
这两个版本直接的唯一差别是，新版本的镜像使用的是 v2 版本的 `barnett/canarydemo:v2`，再次访问网关，你会发现有20%的机率看到新版本的结果 `Demo: v2`:
|
||||
|
||||
```shell
|
||||
$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
|
||||
Demo: V2
|
||||
```
|
||||
|
||||
其他 `继续发布/回滚` 等操作和上面的 webservice 的类型组件完全一致。
|
||||
|
|
@ -0,0 +1,81 @@
|
|||
---
|
||||
title: Nginx Ingress Controller
|
||||
---
|
||||
|
||||
[Nginx Ingress controller](https://kubernetes.github.io/ingress-nginx/) 通过借助 nginx 实现了 Ingress controller 的功能为集群提供代理和负载均衡的功能。
|
||||
|
||||
## 安装
|
||||
|
||||
```shell
|
||||
vela addon enable ingrss-controller
|
||||
```
|
||||
|
||||
## 指定 Service Type
|
||||
|
||||
可以选择三种服务类型，出于安全考虑默认是 `ClusterIP`，还可以指定为`NodePort` 和 `LoadBalancer`。
|
||||
|
||||
- `LoadBalancer` 需要你的集群运行在某个公有云上，并有一种支持的 cloud LoadBalancer。
|
||||
```shell script
|
||||
vela addon enable ingrss-controller serviceType=LoadBalancer
|
||||
```
|
||||
|
||||
- `NodePort` 类型需要你能够访问集群节点的 IP和端口
|
||||
```shell script
|
||||
vela addon enable ingrss-controller serviceType=NodePort
|
||||
```
|
||||
|
||||
## 获取网关地址
|
||||
|
||||
如果指定了服务类型是 `NodePort` 和 `LoadBalancer`，你可以通过下面的命令，获取到网关的地址：
|
||||
|
||||
```shell
|
||||
vela status addon-ingrss-controller -n vela-system --endpoint
|
||||
```
|
||||
|
||||
如果是 `ClusterIP` 类型，又可以通过 `vela port-forward` 命令将网关的端口映射到本地：
|
||||
|
||||
```shell
|
||||
vela port-forward -n vela-system addon-ingress-controller 9080:80
|
||||
```
|
||||
|
||||
## 卸载
|
||||
|
||||
```shell
|
||||
vela addon disable ingrss-controller
|
||||
```
|
||||
|
||||
## 例子
|
||||
|
||||
部署下面的应用：
|
||||
```yaml
|
||||
cat <<EOF | vela up -f -
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: demo
|
||||
spec:
|
||||
components:
|
||||
- name: demo
|
||||
type: webservice
|
||||
properties:
|
||||
image: barnett/canarydemo:v1
|
||||
ports:
|
||||
- port: 8090
|
||||
traits:
|
||||
- type: gateway
|
||||
properties:
|
||||
domain: canary-demo.com
|
||||
http:
|
||||
"/version": 8090
|
||||
EOF
|
||||
```
|
||||
|
||||
访问网关地址：
|
||||
|
||||
```shell
|
||||
$ curl -H "Host: canary-demo.com" <ingress-controller-endpoint>/version
|
||||
Demo: V1
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,294 @@
|
|||
---
|
||||
title: Kruise-rollout
|
||||
---
|
||||
|
||||
Kruise Rollout对原生Deployment、Kruise CloneSet提供渐进式交付的能力，例如：金丝雀发布、蓝绿发布、A/B Testing等，更多详情请参考：[Kruise Rollout](https://github.com/openkruise/rollouts/blob/master/docs/getting_started/introduction.md)。
|
||||
|
||||
本文主要介绍如何使用Kruise Rollout实现金丝雀发布。
|
||||
|
||||
## 准备工作
|
||||
|
||||
1. 安装Kruise Rollout
|
||||
```shell
|
||||
% vela addon enable kruise-rollout
|
||||
enable addon by local dir: addons/kruise-rollout
|
||||
Addon: kruise-rollout enabled Successfully.
|
||||
```
|
||||
|
||||
2. 请保证你的集群有一种 [ingress controllers](https://kubernetes.github.io/ingress-nginx/deploy/) 正在运行。
|
||||
如果没有你可以通过启用 [nginx-ingress-controller](./nginx-ingress-controller) 安装一个。
|
||||
|
||||
```shell
|
||||
vela addon enable ingress-controller
|
||||
```
|
||||
|
||||
请参考[文档](./nginx-ingress-controller) 获取网关的访问地址。
|
||||
|
||||
## 首次部署
|
||||
|
||||
部署应用:
|
||||
|
||||
```shell
|
||||
cat <<EOF | vela up -f -
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: canary-demo
|
||||
spec:
|
||||
components:
|
||||
- name: canary-demo
|
||||
type: webservice
|
||||
properties:
|
||||
image: barnett/canarydemo:v1
|
||||
ports:
|
||||
- port: 8090
|
||||
traits:
|
||||
- type: scaler
|
||||
properties:
|
||||
replicas: 5
|
||||
- type: gateway
|
||||
properties:
|
||||
domain: canary-demo.com
|
||||
http:
|
||||
"/version": 8090
|
||||
- type: kruise-rollout
|
||||
properties:
|
||||
canary:
|
||||
# The first batch of Canary releases 20% Pods, and 20% traffic imported to the new version, require manual confirmation before subsequent releases are completed
|
||||
steps:
|
||||
- weight: 20
|
||||
EOF
|
||||
```
|
||||
|
||||
检查应用状态，发现应用已经出于 `Running` 状态。
|
||||
|
||||
|
||||
```shell
|
||||
$ vela status canary-demo
|
||||
About:
|
||||
|
||||
Name: canary-demo
|
||||
Namespace: default
|
||||
Created at: 2022-06-09 16:43:10 +0800 CST
|
||||
Status: running
|
||||
|
||||
Workflow:
|
||||
|
||||
mode: DAG
|
||||
finished: true
|
||||
Suspend: false
|
||||
Terminated: false
|
||||
Steps
|
||||
- id:x6rnat7iby
|
||||
name:canary-demo
|
||||
type:apply-component
|
||||
phase:succeeded
|
||||
message:
|
||||
|
||||
Services:
|
||||
|
||||
- Name: canary-demo
|
||||
Cluster: local Namespace: default
|
||||
Type: webservice
|
||||
Healthy Ready:5/5
|
||||
Traits:
|
||||
✅ scaler ✅ gateway: No loadBalancer found, visiting by using 'vela port-forward canary-demo'
|
||||
✅ kruise-rollout: rollout is healthy
|
||||
|
||||
```
|
||||
|
||||
用上面定义的路径和 Host 访问网关:
|
||||
|
||||
```shell
|
||||
$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
|
||||
Demo: V1
|
||||
```
|
||||
|
||||
## 金丝雀发布
|
||||
修改镜像标签 v1 -> v2：
|
||||
|
||||
```shell
|
||||
cat <<EOF | vela up -f -
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: canary-demo
|
||||
spec:
|
||||
components:
|
||||
- name: canary-demo
|
||||
type: webservice
|
||||
properties:
|
||||
image: barnett/canarydemo:v2
|
||||
ports:
|
||||
- port: 8090
|
||||
traits:
|
||||
- type: scaler
|
||||
properties:
|
||||
replicas: 5
|
||||
- type: gateway
|
||||
properties:
|
||||
domain: canary-demo.com
|
||||
http:
|
||||
"/version": 8090
|
||||
- type: kruise-rollout
|
||||
properties:
|
||||
canary:
|
||||
# The first batch of Canary releases 20% Pods, and 20% traffic imported to the new version, require manual confirmation before subsequent releases are completed
|
||||
steps:
|
||||
- weight: 20
|
||||
EOF
|
||||
```
|
||||
|
||||
请注意这里的 kurise-rollout 运维特征里升级策略的配置，这里的含义是先金丝雀发布一批，该批次包含了20%的实例个数，并将20%的流量导入到新版本实例中。
|
||||
检查 app 的状态：
|
||||
```shell
|
||||
$ vela status canary-demo
|
||||
About:
|
||||
|
||||
Name: canary-demo
|
||||
Namespace: default
|
||||
Created at: 2022-06-09 16:43:10 +0800 CST
|
||||
Status: runningWorkflow
|
||||
|
||||
Workflow:
|
||||
|
||||
mode: DAG
|
||||
finished: false
|
||||
Suspend: false
|
||||
Terminated: false
|
||||
Steps
|
||||
- id:8adxa11wku
|
||||
name:canary-demo
|
||||
type:apply-component
|
||||
phase:running
|
||||
message:wait healthy
|
||||
|
||||
Services:
|
||||
|
||||
- Name: canary-demo
|
||||
Cluster: local Namespace: default
|
||||
Type: webservice
|
||||
Unhealthy Ready:5/5
|
||||
Traits:
|
||||
✅ scaler ✅ gateway: No loadBalancer found, visiting by using 'vela port-forward canary-demo'
|
||||
❌ kruise-rollout: Rollout is in step(1/1), and you need manually confirm to enter the next step
|
||||
|
||||
```
|
||||
|
||||
application 的状态处于 `runningWorkflow` 意味着发布尚未完成。
|
||||
再次访问网关，你会发现有20%的机率看到新版本的结果 `Demo: v2`:
|
||||
|
||||
```shell
|
||||
$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
|
||||
Demo: V2
|
||||
```
|
||||
|
||||
## 金丝雀验证OK，全量发布
|
||||
|
||||
用户通过业务的相关指标，如：日志、Metrics等其它手段，验证金丝雀版本OK之后，继续执行工作流发布继续发布。
|
||||
|
||||
|
||||
```shell
|
||||
vela workflow resume canary-demo
|
||||
```
|
||||
|
||||
## 金丝雀验证失败，回滚
|
||||
|
||||
如果经过验证发现新版本有问题，你想中断发布，将应用回滚至上一个版本。可以如下操作：
|
||||
|
||||
```shell
|
||||
vela workflow rollback canary-demo
|
||||
```
|
||||
|
||||
回滚完成之后，访问网关，你会发现结果一直都是 `Demo: V1`：
|
||||
|
||||
```shell
|
||||
$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
|
||||
Demo: V1
|
||||
```
|
||||
|
||||
## Helm 应用的金丝雀发布
|
||||
|
||||
### 首次部署：
|
||||
|
||||
|
||||
```shell
|
||||
cat <<EOF | vela up -f -
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: canary-demo
|
||||
spec:
|
||||
components:
|
||||
- name: canary-demo
|
||||
type: helm
|
||||
properties:
|
||||
repoType: "helm"
|
||||
url: "https://wangyikewxgm.github.io/my-charts/"
|
||||
chart: "canary-demo"
|
||||
version: "1.0.0"
|
||||
traits:
|
||||
- type: kruise-rollout
|
||||
properties:
|
||||
workloadType:
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
canary:
|
||||
# The first batch of Canary releases 20% Pods, and 20% traffic imported to the new version, require manual confirmation before subsequent releases are completed
|
||||
steps:
|
||||
- weight: 20
|
||||
EOF
|
||||
```
|
||||
|
||||
应用所使用的 chart 中包含了一个使用了 `barnett/canarydemo:v1` 镜像的 Deployment。
|
||||
|
||||
另外，请注意你需要天蝎 kruise-rollout trait 中 `workloadType` 的字段，因为一个 chart 中可能包含各种资源，你需要指出发布资源的类型。
|
||||
|
||||
部署成功之后，访问网关：
|
||||
```shell
|
||||
$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
|
||||
Demo: V1
|
||||
```
|
||||
|
||||
### 金丝雀发布
|
||||
|
||||
通过下面的步骤将 chart 的版本从 `1.0.0` 更新到 `2.0.0`：
|
||||
|
||||
|
||||
```shell
|
||||
cat <<EOF | vela up -f -
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: canary-demo
|
||||
spec:
|
||||
components:
|
||||
- name: canary-demo
|
||||
type: helm
|
||||
properties:
|
||||
repoType: "helm"
|
||||
url: "https://wangyikewxgm.github.io/my-charts/"
|
||||
chart: "canary-demo"
|
||||
# Upgade to version 2.0.0
|
||||
version: "2.0.0"
|
||||
traits:
|
||||
- type: kruise-rollout
|
||||
properties:
|
||||
workloadType:
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
canary:
|
||||
# The first batch of Canary releases 20% Pods, and 20% traffic imported to the new version, require manual confirmation before subsequent releases are completed
|
||||
steps:
|
||||
- weight: 20
|
||||
EOF
|
||||
```
|
||||
|
||||
这两个版本直接的唯一差别是，新版本的镜像使用的是 v2 版本的 `barnett/canarydemo:v2`，再次访问网关，你会发现有20%的机率看到新版本的结果 `Demo: v2`:
|
||||
|
||||
```shell
|
||||
$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
|
||||
Demo: V2
|
||||
```
|
||||
|
||||
其他 `继续发布/回滚` 等操作和上面的 webservice 的类型组件完全一致。
|
||||
|
|
@ -0,0 +1,81 @@
|
|||
---
|
||||
title: Nginx Ingress Controller
|
||||
---
|
||||
|
||||
[Nginx Ingress controller](https://kubernetes.github.io/ingress-nginx/) 通过借助 nginx 实现了 Ingress controller 的功能为集群提供代理和负载均衡的功能。
|
||||
|
||||
## 安装
|
||||
|
||||
```shell
|
||||
vela addon enable ingrss-controller
|
||||
```
|
||||
|
||||
## 指定 Service Type
|
||||
|
||||
可以选择三种服务类型，出于安全考虑默认是 `ClusterIP`，还可以指定为`NodePort` 和 `LoadBalancer`。
|
||||
|
||||
- `LoadBalancer` 需要你的集群运行在某个公有云上，并有一种支持的 cloud LoadBalancer。
|
||||
```shell script
|
||||
vela addon enable ingrss-controller serviceType=LoadBalancer
|
||||
```
|
||||
|
||||
- `NodePort` 类型需要你能够访问集群节点的 IP和端口
|
||||
```shell script
|
||||
vela addon enable ingrss-controller serviceType=NodePort
|
||||
```
|
||||
|
||||
## 获取网关地址
|
||||
|
||||
如果指定了服务类型是 `NodePort` 和 `LoadBalancer`，你可以通过下面的命令，获取到网关的地址：
|
||||
|
||||
```shell
|
||||
vela status addon-ingrss-controller -n vela-system --endpoint
|
||||
```
|
||||
|
||||
如果是 `ClusterIP` 类型，又可以通过 `vela port-forward` 命令将网关的端口映射到本地：
|
||||
|
||||
```shell
|
||||
vela port-forward -n vela-system addon-ingress-controller 9080:80
|
||||
```
|
||||
|
||||
## 卸载
|
||||
|
||||
```shell
|
||||
vela addon disable ingrss-controller
|
||||
```
|
||||
|
||||
## 例子
|
||||
|
||||
部署下面的应用：
|
||||
```yaml
|
||||
cat <<EOF | vela up -f -
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: demo
|
||||
spec:
|
||||
components:
|
||||
- name: demo
|
||||
type: webservice
|
||||
properties:
|
||||
image: barnett/canarydemo:v1
|
||||
ports:
|
||||
- port: 8090
|
||||
traits:
|
||||
- type: gateway
|
||||
properties:
|
||||
domain: canary-demo.com
|
||||
http:
|
||||
"/version": 8090
|
||||
EOF
|
||||
```
|
||||
|
||||
访问网关地址：
|
||||
|
||||
```shell
|
||||
$ curl -H "Host: canary-demo.com" <ingress-controller-endpoint>/version
|
||||
Demo: V1
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
|
@ -32,13 +32,14 @@ module.exports = {
|
|||
'case-studies/multi-cluster',
|
||||
'tutorials/access-application',
|
||||
'end-user/traits/sidecar',
|
||||
'end-user/traits/rollout',
|
||||
],
|
||||
},
|
||||
{
|
||||
type: 'category',
|
||||
label: 'Helm Chart CD',
|
||||
collapsed: true,
|
||||
items: ['tutorials/helm', 'tutorials/helm-multi-cluster'],
|
||||
items: ['tutorials/helm', 'tutorials/helm-multi-cluster', 'tutorials/helm-rollout'],
|
||||
},
|
||||
{
|
||||
type: 'category',
|
||||
|
|
@ -60,7 +61,7 @@ module.exports = {
|
|||
type: 'category',
|
||||
label: 'Kubernetes Manifest CD',
|
||||
collapsed: true,
|
||||
items: ['tutorials/k8s-object', 'end-user/components/ref-objects'],
|
||||
items: ['tutorials/k8s-object', 'end-user/components/ref-objects', "tutorials/k8s-object-rollout"],
|
||||
},
|
||||
{
|
||||
type: 'category',
|
||||
|
|
|
|||
|
|
@ -0,0 +1,298 @@
|
|||
---
|
||||
title: kruise-rollout
|
||||
---
|
||||
|
||||
Kruise Rollout addon provides incremental delivery capabilities for Native Deployment, Kruise CloneSet, e.g. Canary Release, Blue-green Release, A/B Testing, etc.
|
||||
For more details, please refer to: [Kruise Rollout](https://github.com/openkruise/rollouts/blob/master/docs/getting_started/introduction.md).
|
||||
|
||||
This article focuses on how to implement Canary Release using Kruise Rollout addon.
|
||||
|
||||
## Requirements
|
||||
|
||||
1. Install Kruise Rollout
|
||||
```shell
|
||||
% vela addon enable kruise-rollout
|
||||
enable addon by local dir: addons/kruise-rollout
|
||||
Addon: kruise-rollout enabled Successfully.
|
||||
```
|
||||
|
||||
2. Please make sure one of the [ingress controllers](https://kubernetes.github.io/ingress-nginx/deploy/) is available in your Kubernetes cluster.
|
||||
If not yet, you can install one in your cluster by enable the [nginx-ingress-controller](./nginx-ingress-controller) addon:
|
||||
|
||||
```shell
|
||||
vela addon enable ingress-controller
|
||||
```
|
||||
|
||||
Please refer [this](./nginx-ingress-controller) to get the gateway's access address.
|
||||
|
||||
|
||||
## First Deployment
|
||||
|
||||
Deploy the application:
|
||||
|
||||
```shell
|
||||
cat <<EOF | vela up -f -
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: canary-demo
|
||||
spec:
|
||||
components:
|
||||
- name: canary-demo
|
||||
type: webservice
|
||||
properties:
|
||||
image: barnett/canarydemo:v1
|
||||
ports:
|
||||
- port: 8090
|
||||
traits:
|
||||
- type: scaler
|
||||
properties:
|
||||
replicas: 5
|
||||
- type: gateway
|
||||
properties:
|
||||
domain: canary-demo.com
|
||||
http:
|
||||
"/version": 8090
|
||||
- type: kruise-rollout
|
||||
properties:
|
||||
canary:
|
||||
# The first batch of Canary releases 20% Pods, and 20% traffic imported to the new version, require manual confirmation before subsequent releases are completed
|
||||
steps:
|
||||
- weight: 20
|
||||
EOF
|
||||
```
|
||||
|
||||
Then check the status of application will find out the application is running.
|
||||
|
||||
```shell
|
||||
$ vela status canary-demo
|
||||
About:
|
||||
|
||||
Name: canary-demo
|
||||
Namespace: default
|
||||
Created at: 2022-06-09 16:43:10 +0800 CST
|
||||
Status: running
|
||||
|
||||
Workflow:
|
||||
|
||||
mode: DAG
|
||||
finished: true
|
||||
Suspend: false
|
||||
Terminated: false
|
||||
Steps
|
||||
- id:x6rnat7iby
|
||||
name:canary-demo
|
||||
type:apply-component
|
||||
phase:succeeded
|
||||
message:
|
||||
|
||||
Services:
|
||||
|
||||
- Name: canary-demo
|
||||
Cluster: local Namespace: default
|
||||
Type: webservice
|
||||
Healthy Ready:5/5
|
||||
Traits:
|
||||
✅ scaler ✅ gateway: No loadBalancer found, visiting by using 'vela port-forward canary-demo'
|
||||
✅ kruise-rollout: rollout is healthy
|
||||
|
||||
```
|
||||
|
||||
Access the gateway endpoint with the specific host.
|
||||
```shell
|
||||
$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
|
||||
Demo: V1
|
||||
```
|
||||
|
||||
|
||||
## Canary Release
|
||||
Modify the webservice image tag, from v1 to v2, as follows:
|
||||
|
||||
```shell
|
||||
cat <<EOF | vela up -f -
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: canary-demo
|
||||
spec:
|
||||
components:
|
||||
- name: canary-demo
|
||||
type: webservice
|
||||
properties:
|
||||
image: barnett/canarydemo:v2
|
||||
ports:
|
||||
- port: 8090
|
||||
traits:
|
||||
- type: scaler
|
||||
properties:
|
||||
replicas: 5
|
||||
- type: gateway
|
||||
properties:
|
||||
domain: canary-demo.com
|
||||
http:
|
||||
"/version": 8090
|
||||
- type: kruise-rollout
|
||||
properties:
|
||||
canary:
|
||||
# The first batch of Canary releases 20% Pods, and 20% traffic imported to the new version, require manual confirmation before subsequent releases are completed
|
||||
steps:
|
||||
- weight: 20
|
||||
EOF
|
||||
```
|
||||
|
||||
The configuration strategy of kruise-rollout trait means: The first batch of Canary releases 20% Pods, and 20% traffic imported to the new version, require manual confirmation before subsequent releases are completed.
|
||||
|
||||
Check the status of applciation:
|
||||
```shell
|
||||
$ vela status canary-demo
|
||||
About:
|
||||
|
||||
Name: canary-demo
|
||||
Namespace: default
|
||||
Created at: 2022-06-09 16:43:10 +0800 CST
|
||||
Status: runningWorkflow
|
||||
|
||||
Workflow:
|
||||
|
||||
mode: DAG
|
||||
finished: false
|
||||
Suspend: false
|
||||
Terminated: false
|
||||
Steps
|
||||
- id:8adxa11wku
|
||||
name:canary-demo
|
||||
type:apply-component
|
||||
phase:running
|
||||
message:wait healthy
|
||||
|
||||
Services:
|
||||
|
||||
- Name: canary-demo
|
||||
Cluster: local Namespace: default
|
||||
Type: webservice
|
||||
Unhealthy Ready:5/5
|
||||
Traits:
|
||||
✅ scaler ✅ gateway: No loadBalancer found, visiting by using 'vela port-forward canary-demo'
|
||||
❌ kruise-rollout: Rollout is in step(1/1), and you need manually confirm to enter the next step
|
||||
|
||||
```
|
||||
|
||||
The application's status is `runningWorkflow` that means the application's rollout process has not finished yet.
|
||||
|
||||
Access the gateway endpoint again. You will find out there is about 20% chance to meet `Demo: v2` result.
|
||||
|
||||
```shell
|
||||
$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
|
||||
Demo: V2
|
||||
```
|
||||
|
||||
## Canary validation successful, full release
|
||||
|
||||
After user verifies the success of the canary version through business-related metrics, such as logs, metrics, and other means, you can resume the workflow to continue the process of rollout.
|
||||
|
||||
```shell
|
||||
vela workflow resume canary-demo
|
||||
```
|
||||
|
||||
## Canary verification failed, rollback
|
||||
|
||||
If you want to cancel the rollout process and rollback the application to the latest version, after manually check. You can use this command:
|
||||
```shell
|
||||
vela workflow rollback canary-demo
|
||||
```
|
||||
|
||||
Access the gateway endpoint again. You can see the result always is `Demo: V1`
|
||||
```shell
|
||||
$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
|
||||
Demo: V1
|
||||
```
|
||||
|
||||
## Rollout for helm component
|
||||
|
||||
This capability of rollout also can be used for helm component.
|
||||
|
||||
### First deployment
|
||||
|
||||
```shell
|
||||
cat <<EOF | vela up -f -
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: canary-demo
|
||||
spec:
|
||||
components:
|
||||
- name: canary-demo
|
||||
type: helm
|
||||
properties:
|
||||
repoType: "helm"
|
||||
url: "https://wangyikewxgm.github.io/my-charts/"
|
||||
chart: "canary-demo"
|
||||
version: "1.0.0"
|
||||
traits:
|
||||
- type: kruise-rollout
|
||||
properties:
|
||||
workloadType:
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
canary:
|
||||
# The first batch of Canary releases 20% Pods, and 20% traffic imported to the new version, require manual confirmation before subsequent releases are completed
|
||||
steps:
|
||||
- weight: 20
|
||||
EOF
|
||||
```
|
||||
|
||||
This helm chart contain a deployment whose image is `barnett/canarydemo:v1`.
|
||||
|
||||
Please notice the `workloadType` configuration of kruise-rollout trait. You must tell the trait witch kind of resource in the helm chart want to roll out.
|
||||
|
||||
Access the gateway endpoint. You can see the result always is `Demo: V1`
|
||||
```shell
|
||||
$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
|
||||
Demo: V1
|
||||
```
|
||||
|
||||
### Canary Rollout
|
||||
|
||||
Update the target version of helm chart from `1.0.0` to `2.0.0`:
|
||||
|
||||
```shell
|
||||
cat <<EOF | vela up -f -
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: canary-demo
|
||||
spec:
|
||||
components:
|
||||
- name: canary-demo
|
||||
type: helm
|
||||
properties:
|
||||
repoType: "helm"
|
||||
url: "https://wangyikewxgm.github.io/my-charts/"
|
||||
chart: "canary-demo"
|
||||
# Upgade to version 2.0.0
|
||||
version: "2.0.0"
|
||||
traits:
|
||||
- type: kruise-rollout
|
||||
properties:
|
||||
workloadType:
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
canary:
|
||||
# The first batch of Canary releases 20% Pods, and 20% traffic imported to the new version, require manual confirmation before subsequent releases are completed
|
||||
steps:
|
||||
- weight: 20
|
||||
EOF
|
||||
```
|
||||
|
||||
The only difference between two versions is image tag. Version `2.0.0` uses `barnett/canarydemo:v2`.
|
||||
|
||||
Access the gateway endpoint again. You will find out there is about 20% chance to meet `Demo: v2` result.
|
||||
|
||||
```shell
|
||||
$ curl -H "Host: canary-demo.com" <ingress-controller-address>/version
|
||||
Demo: V2
|
||||
```
|
||||
|
||||
The other operations such as `continue rollout/rollback` are totally same with the operation for webservice component.
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,80 @@
|
|||
---
|
||||
title: Nginx Ingress Controller
|
||||
---
|
||||
|
||||
|
||||
[Nginx Ingress controller](https://kubernetes.github.io/ingress-nginx/) is an Ingress controller for Kubernetes using NGINX as a reverse proxy and load balancer.
|
||||
|
||||
## Install
|
||||
|
||||
```shell
|
||||
vela addon enable ingrss-controller
|
||||
```
|
||||
|
||||
## Setup with Specified Service Type
|
||||
|
||||
There are three service types for this addon which aligned with Kubernetes service, they're `ClusterIP`, `NodePort` and `LoadBalancer`.
|
||||
By default the service type is ClusterIP for security.
|
||||
|
||||
- `LoadBalancer` type requires your cluster has cloud LoadBalancer available.
|
||||
```shell script
|
||||
vela addon enable ingrss-controller serviceType=LoadBalancer
|
||||
```
|
||||
- `NodePort` type requires you can access the Kubernetes Node IP/Port.
|
||||
```shell script
|
||||
vela addon enable ingrss-controller serviceType=NodePort
|
||||
```
|
||||
|
||||
## Get access address
|
||||
|
||||
After specify the service type to `LoadBalancer` or `NodePort`, you can obtain the access address through `vela status`:
|
||||
|
||||
```shell
|
||||
vela status addon-ingrss-controller -n vela-system --endpoint
|
||||
```
|
||||
|
||||
If the service type is `ClusterIP`, you use `vela port-forward` map the ingrss-controller's port to local
|
||||
|
||||
```shell
|
||||
vela port-forward -n vela-system addon-ingress-controller 9080:80
|
||||
```
|
||||
|
||||
## Uninstall
|
||||
|
||||
```shell
|
||||
vela addon disable ingrss-controller
|
||||
```
|
||||
|
||||
## Example
|
||||
|
||||
Use this addon by deploy an application:
|
||||
|
||||
```yaml
|
||||
cat <<EOF | vela up -f -
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
kind: Application
|
||||
metadata:
|
||||
name: demo
|
||||
spec:
|
||||
components:
|
||||
- name: demo
|
||||
type: webservice
|
||||
properties:
|
||||
image: barnett/canarydemo:v1
|
||||
ports:
|
||||
- port: 8090
|
||||
traits:
|
||||
- type: gateway
|
||||
properties:
|
||||
domain: canary-demo.com
|
||||
http:
|
||||
"/version": 8090
|
||||
EOF
|
||||
```
|
||||
|
||||
Then access the gateway's endpoint will see:
|
||||
|
||||
```shell
|
||||
$ curl -H "Host: canary-demo.com" <ingress-controller-endpoint>/version
|
||||
Demo: V1
|
||||
```
|
||||
|
|
@ -20,5 +20,7 @@ There's an community addon registry (https://addons.kubevela.net) maintained by
|
|||
* [KubeVela doc](./kubevela-io) Help you to read the KubeVela document in your cluster which can be air-gaped environment.
|
||||
* [Flink kubernetes operator](./flink-kubernetes-operator) A Kubernetes operator for Apache Flink(https://github.com/apache/flink-kubernetes-operator).
|
||||
* [dex](./dex) Provide [dex](https://github.com/dexidp/dex) login for VelaUX.
|
||||
* [Rollout](./kruise-rollout): Base on KubeVela Rollout implementation canary rollout and other types of rollout.
|
||||
* [nginx-ingress-controller](./nginx-ingress-controller): An Ingress controller for Kubernetes using NGINX as a reverse proxy and load balancer.
|
||||
|
||||
**If you want to make your own addon please refer to [doc](../../platform-engineers/addon/intro.md).**
|
||||
Loading…
Reference in New Issue