kruise rollout v0.5.0 (#151)
Signed-off-by: liheng.zms <liheng.zms@alibaba-inc.com>
This commit is contained in:
berg
GitHub
parent
1db757bfd6
commit
be92e155e7
|
|
@ -1,5 +1,8 @@
|
|||
# Traffic Routing with Istio
|
||||
This page is a demo to show how to utilize Kruise Rollout to do traffic routing with Istio.
|
||||
|
||||
**FEATURE STATE:** Kruise Rollout v0.5.0
|
||||
|
||||
This page is a demo to show how to utilize Kruise Rollout to do traffic routing with Istio.
|
||||
|
||||
## A Complete Release Process
|
||||
### Deploy deployment `workload-demo` and service `service-demo`
|
||||
|
|
@ -58,18 +61,15 @@ spec:
|
|||
```
|
||||
### Deploy Rollout `rollouts-demo`
|
||||
```yaml
|
||||
apiVersion: rollouts.kruise.io/v1alpha1
|
||||
apiVersion: rollouts.kruise.io/v1beta1
|
||||
kind: Rollout
|
||||
metadata:
|
||||
name: rollouts-demo
|
||||
annotations:
|
||||
rollouts.kruise.io/rolling-style: canary
|
||||
spec:
|
||||
objectRef:
|
||||
workloadRef:
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
name: workload-demo
|
||||
workloadRef:
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
name: workload-demo
|
||||
strategy:
|
||||
canary:
|
||||
steps:
|
||||
|
|
@ -79,10 +79,12 @@ spec:
|
|||
- type: Exact
|
||||
name: version
|
||||
value: canary
|
||||
- weight: 50
|
||||
- weight: 80
|
||||
- traffic: 50%
|
||||
replicas: 50%
|
||||
- traffic: 80%
|
||||
replicas: 80%
|
||||
trafficRoutings:
|
||||
- service: mocka
|
||||
- service: mocka
|
||||
customNetworkRefs:
|
||||
- apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
|
|
@ -122,7 +124,7 @@ spec:
|
|||
- '*'
|
||||
http:
|
||||
# route traffic with header version=canary to new-version pods
|
||||
- match:
|
||||
- match:
|
||||
- headers:
|
||||
version:
|
||||
exact: canary
|
||||
|
|
@ -186,4 +188,4 @@ Run `kubectl-kruise rollout approve rollout/rollouts-demo -n default` to complet
|
|||
- Resume the base Deployment.
|
||||
- Restore the VirtualService `vs-demo`.
|
||||
|
||||
After that, the release is done and your are ready to use the new-version service.
|
||||
After that, the release is done and your are ready to use the new-version service.
|
||||
|
|
@ -1,5 +1,7 @@
|
|||
# Extensible Traffic Routing Based on Lua Script
|
||||
|
||||
**FEATURE STATE:** Kruise Rollout v0.5.0
|
||||
|
||||
Kruise Rollout utilizes a Lua-script-based customization approach for **API Gateway resources (Istio VirtualService, Apisix ApisixRoute, Kuma TrafficRoute and etc.)**. Kruise Rollout involves invoking Lua scripts to retrieve and update the desired configurations of resources based on **release strategies and the original configurations of API Gateway resources (including spec, labels, and annotations)**. It enables users to easily adapt and integrate various types of API Gateway resources without modifying existing code and configurations.
|
||||
|
||||
**By using Kruise Rollout, users can:**
|
||||
|
|
@ -23,7 +25,7 @@ The entire process of can be described as follows:
|
|||
Custom traffic routing can be configured in Rollout as below:
|
||||
|
||||
```yaml
|
||||
apiVersion: rollouts.kruise.io/v1alpha1
|
||||
apiVersion: rollouts.kruise.io/v1beta1
|
||||
kind: Rollout
|
||||
...
|
||||
spec:
|
||||
|
|
@ -51,7 +53,7 @@ There are two ways to define and use your custom traffic routing Lua script to h
|
|||
|
||||
### Way1: Contribute a Custom Traffic Routing
|
||||
|
||||
You can contribute Lua scripts for custom resources and the scripts can be bundled into Kruise Rollout after passing the tests. These Lua scripts can then be directly invoked within the Rollout.
|
||||
You can contribute Lua scripts for custom resources and the scripts can be bundled into Kruise Rollout after passing the tests. These Lua scripts can then be directly invoked within the Rollout.
|
||||
|
||||
Kruise Rollout by default invoke Lua scripts in the `rollouts/lua_configuration` directory. The bundled Lua scripts should follow the following directory structure:
|
||||
|
||||
|
|
@ -85,22 +87,19 @@ expected:
|
|||
**Custom traffic routing Lua script must pass the tests to prove it can work as expected**. The following example demonstrates a custom traffic routing test for `networking.istio.io/VirtualService`.
|
||||
|
||||
```yaml
|
||||
rollout:
|
||||
apiVersion: rollouts.kruise.io/v1alpha1
|
||||
rollout:
|
||||
apiVersion: rollouts.kruise.io/v1beta1
|
||||
kind: Rollout
|
||||
metadata:
|
||||
name: rollouts-demo
|
||||
annotations:
|
||||
rollouts.kruise.io/rolling-style: canary
|
||||
spec:
|
||||
disabled: false
|
||||
objectRef:
|
||||
workloadRef:
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
name: deploy-demo
|
||||
workloadRef:
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
name: deploy-demo
|
||||
strategy:
|
||||
canary:
|
||||
enableExtraWorkloadForCanary: true
|
||||
steps:
|
||||
- matches:
|
||||
- headers:
|
||||
|
|
@ -119,7 +118,8 @@ rollout:
|
|||
- type: RegularExpression
|
||||
name: name
|
||||
value: ".*demo"
|
||||
- weight: 50
|
||||
- traffic: 50%
|
||||
replicas: 50%
|
||||
trafficRoutings:
|
||||
- service: svc-demo
|
||||
customNetworkRefs:
|
||||
|
|
@ -254,14 +254,14 @@ When designing test cases, at least the release strategies listed below are supp
|
|||
|
||||
```yaml
|
||||
# spec.strategy.canary.steps:
|
||||
- weight: 20
|
||||
- traffic: 20%
|
||||
```
|
||||
|
||||
- **Special Note:** By default, traffic routing strategies defined in Rollout will create a new canary for new pods, while TrafficRouting will not.
|
||||
|
||||
### Way2: Define in ConfigMap
|
||||
|
||||
When the expected traffic routing Lua scripts are not bundled in Kruise Rollout, users could utilize ConfigMap to define and use Lua script to handle API Gateway resources. Custom traffic routing lua script can be defined in
|
||||
When the expected traffic routing Lua scripts are not bundled in Kruise Rollout, users could utilize ConfigMap to define and use Lua script to handle API Gateway resources. Custom traffic routing lua script can be defined in
|
||||
|
||||
```yaml
|
||||
<lua.traffic.routing.Kind.CRDGroup>: |
|
||||
|
|
@ -270,7 +270,7 @@ When the expected traffic routing Lua scripts are not bundled in Kruise Rollout,
|
|||
|
||||
field of ConfigMap `kruise-rollout/kruise-rollout-configuration`.
|
||||
|
||||
The following example demonstrates a traffic routing for `networking.istio.io/DestinationRule`, you can also define your own Lua script for API Gateway resources of other groups for example Apisix and Kuma in the ConfigMap.
|
||||
The following example demonstrates a traffic routing for `networking.istio.io/DestinationRule`, you can also define your own Lua script for API Gateway resources of other groups for example Apisix and Kuma in the ConfigMap.
|
||||
|
||||
```yaml
|
||||
data:
|
||||
|
|
@ -323,13 +323,13 @@ Access elements using dot notation: `myTable.key`
|
|||
|
||||
- **Iterating over a table:**
|
||||
|
||||
Iterate over all key-value pairs using the `pairs()` function:
|
||||
Iterate over all key-value pairs using the `pairs()` function:
|
||||
|
||||
```lua
|
||||
for key, value in pairs(myTable) do ... end
|
||||
```
|
||||
|
||||
Iterate over the array part of the table using the `ipairs()` function:
|
||||
Iterate over the array part of the table using the `ipairs()` function:
|
||||
|
||||
```lua
|
||||
for index, value in ipairs(myTable) do ... end
|
||||
|
|
@ -371,17 +371,17 @@ type Data struct {
|
|||
You should handle `obj` in Lua script and **must retrun an object contains expected spec, labels and annotations** of the API Gateway resource, a simple way is to return `obj.data`.
|
||||
|
||||
```lua
|
||||
-- Lua variables are assigned by reference,
|
||||
-- Lua variables are assigned by reference,
|
||||
-- so updates to 'spec' can be synchronized to 'obj.data.spec'.
|
||||
spec = obj.data.spec -- get resource 'spec'
|
||||
hosts = spec.hosts
|
||||
canaryService = obj.canaryService
|
||||
-- traverse header 'matches' defined in Rollout strategy
|
||||
for _, match in ipairs(obj.matches) do
|
||||
for _, match in ipairs(obj.matches) do
|
||||
... -- define how to handle matches
|
||||
end
|
||||
-- return 'obj.data' and Kruise Rollout will update the resource
|
||||
return obj.data
|
||||
return obj.data
|
||||
```
|
||||
|
||||
Or you can define your own variable as return value as long as it **contains expected spec, labels and annotations**, an example is:
|
||||
|
|
@ -411,7 +411,7 @@ An example of `test_case_obj.lua` is shown as below:
|
|||
|
||||
```lua
|
||||
steps = {
|
||||
-- obj of release step_0
|
||||
-- obj of release step_0
|
||||
step_0 = { canaryWeight = -1, stableWeight = 101,
|
||||
matches = { { headers = { { value = "demo", type = "Exact", name = "destination", }, }, }, },
|
||||
canaryService = "mocka", stableService = "mocka",
|
||||
|
|
@ -459,4 +459,4 @@ rules:
|
|||
- update
|
||||
- watch
|
||||
...
|
||||
```
|
||||
```
|
||||
|
|
@ -17,7 +17,7 @@ $ helm repo add openkruise https://openkruise.github.io/charts/
|
|||
$ helm repo update
|
||||
|
||||
# Install the latest version.
|
||||
$ helm install kruise-rollout openkruise/kruise-rollout --version 0.3.0
|
||||
$ helm install kruise-rollout openkruise/kruise-rollout --version 0.5.0
|
||||
```
|
||||
**Note:** [Changelog](https://github.com/openkruise/kruise/blob/master/CHANGELOG.md).
|
||||
## Upgrade with helm
|
||||
|
|
@ -30,7 +30,7 @@ $ helm repo add openkruise https://openkruise.github.io/charts/
|
|||
$ helm repo update
|
||||
|
||||
# Upgrade to the latest version.
|
||||
$ helm upgrade kruise-rollout openkruise/kruise-rollout --version 0.3.0 [--force]
|
||||
$ helm upgrade kruise-rollout openkruise/kruise-rollout --version 0.5.0 [--force]
|
||||
```
|
||||
|
||||
Note that:
|
||||
|
|
@ -67,9 +67,9 @@ The following table lists the configurable parameters of the kruise chart and th
|
|||
| `replicaCount` | Replicas of kruise-rollout deployment | `2` |
|
||||
| `service.port` | Port of webhook served by kruise-rollout webhook service | `443` |
|
||||
|
||||
Specify each parameter using the `--set key=value[,key=value]` argument to `helm install`. For example,
|
||||
Specify each parameter using the `--set key=value[,key=value]` argument to `helm install`. For example,
|
||||
```bash
|
||||
$ helm install kruise-rollout openkruise/kruise-rollout --version 0.3.0 --set resources.limits.memory=2Gi
|
||||
$ helm install kruise-rollout openkruise/kruise-rollout --version 0.5.0 --set resources.limits.memory=2Gi
|
||||
```
|
||||
|
||||
#### Optional: the local image for China
|
||||
|
|
|
|||
|
|
@ -1,14 +1,65 @@
|
|||
# API Specifications
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
A basic example for Kruise Rollouts resource YAML:
|
||||
|
||||
**Note: v1beta1 available from Kruise Rollout v0.5.0.**
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="v1beta1" label="v1beta1" default>
|
||||
|
||||
```yaml
|
||||
apiVersion: rollouts.kruise.io/v1alpha1
|
||||
kind: Rollout
|
||||
metadata:
|
||||
name: rollouts-demo
|
||||
# The rollout resource needs to be in the same namespace as the corresponding workload
|
||||
namespace: defaults
|
||||
namespace: default
|
||||
spec:
|
||||
# rollout of published workloads, currently only supports Deployment, CloneSet, StatefulSet, Advanced StatefulSet
|
||||
workloadRef:
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
name: echoserver
|
||||
strategy:
|
||||
canary:
|
||||
steps:
|
||||
### the 1-st batch ###
|
||||
# routing 5% traffics to the new version
|
||||
- traffic: 5%
|
||||
# Need Manual confirmation before enter to next batch
|
||||
pause: {}
|
||||
# optional, The first step of released replicas. If not set, the default is to use 'weight', as shown above is 5%.
|
||||
replicas: 1
|
||||
### the 2-nd batch ###
|
||||
- traffic: 50%
|
||||
replicas: 50%
|
||||
# Automatically enter the next batch after waiting 2 hours
|
||||
pause:
|
||||
duration: 7200
|
||||
### the 3-rd batch ###
|
||||
- traffic: 100%
|
||||
replicas: 100%
|
||||
trafficRoutings:
|
||||
# service name that is related with the workload
|
||||
- service: echoserver
|
||||
# ingress name that is related with the service
|
||||
ingress:
|
||||
name: echoserver
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="v1alpha1" label="v1alpha1">
|
||||
|
||||
```yaml
|
||||
apiVersion: rollouts.kruise.io/v1alpha1
|
||||
kind: Rollout
|
||||
metadata:
|
||||
name: rollouts-demo
|
||||
# The rollout resource needs to be in the same namespace as the corresponding workload
|
||||
namespace: default
|
||||
# This annotation can help us upgrade the Deployment using partition, just like StatefulSet/CloneSet.
|
||||
annotations:
|
||||
rollouts.kruise.io/rolling-style: partition
|
||||
|
|
@ -25,13 +76,13 @@ spec:
|
|||
### the 1-st batch ###
|
||||
# routing 5% traffics to the new version
|
||||
- weight: 5
|
||||
# Need Manual confirmation before enter to next batch
|
||||
# Need Manual confirmation before enter to next batch
|
||||
pause: {}
|
||||
# optional, The first step of released replicas. If not set, the default is to use 'weight', as shown above is 5%.
|
||||
# optional, The first step of released replicas. If not set, the default is to use 'weight', as shown above is 5%.
|
||||
replicas: 1
|
||||
### the 2-nd batch ###
|
||||
- replicas: 50%
|
||||
# Automatically enter the next batch after waiting 2 hours
|
||||
# Automatically enter the next batch after waiting 2 hours
|
||||
pause:
|
||||
duration: 7200
|
||||
### the 3-rd batch ###
|
||||
|
|
@ -39,11 +90,14 @@ spec:
|
|||
trafficRoutings:
|
||||
# service name that is related with the workload
|
||||
- service: echoserver
|
||||
# ingress name that is related with the service
|
||||
# ingress name that is related with the service
|
||||
ingress:
|
||||
name: echoserver
|
||||
name: echoserver
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
There are 3 major parts of api specifications you should pay attention to:
|
||||
- Binding your workload: Tell Rollout which workload it should work on;
|
||||
- Binding your traffic configuration: Tell Rollout which traffic configuration it should focus on.
|
||||
|
|
@ -53,6 +107,24 @@ There are 3 major parts of api specifications you should pay attention to:
|
|||
### Workload Binding API (Mandatory)
|
||||
Tell Kruise Rollout which workload should be bounded:
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="v1beta1" label="v1beta1" default>
|
||||
|
||||
```yaml
|
||||
apiVersion: rollouts.kruise.io/v1beta1
|
||||
kind: Rollout
|
||||
metadata:
|
||||
namespace: <your-workload-ns>
|
||||
spec:
|
||||
workloadRef:
|
||||
apiVersion: apps/v1
|
||||
kind: StatefulSet
|
||||
name: <your-workload-name>
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="v1alpha1" label="v1alpha1">
|
||||
|
||||
```yaml
|
||||
apiVersion: rollouts.kruise.io/v1alpha1
|
||||
kind: Rollout
|
||||
|
|
@ -65,6 +137,10 @@ spec:
|
|||
kind: StatefulSet
|
||||
name: <your-workload-name>
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
| Fields | Type | Defaults | Explanation |
|
||||
|--------------|--------|----------|---------------------|
|
||||
| `apiVersion` | string | "" | Workload APIVersion |
|
||||
|
|
@ -73,14 +149,34 @@ spec:
|
|||
|
||||
Currently, Kruise Rollout supports Deployment, CloneSet, StatefulSet, and Advanced StatefulSet.
|
||||
|
||||
Note:
|
||||
- The workload should be at the same namespace as the Rollout.
|
||||
**Note: The workload should be at the same namespace as the Rollout.**
|
||||
|
||||
### Traffic Binding API (Optional)
|
||||
Different from "Workload Binding", Traffic Binding is not necessary. If you do not set the following specifications, the traffic configuration will keep their native behavior, for example, keeping load balance for all versioned Pods.
|
||||
|
||||
If you need do something special for traffic routings, just tell Kruise Rollout which traffic configurations should be bound:
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="v1beta1" label="v1beta1" default>
|
||||
|
||||
```yaml
|
||||
apiVersion: rollouts.kruise.io/v1beta1
|
||||
kind: Rollout
|
||||
metadata:
|
||||
namespace: <your-workload-ns>
|
||||
spec:
|
||||
trafficRoutings:
|
||||
- service: <service-name-that-is-related-your-workload>
|
||||
ingress:
|
||||
classType: <traffic-type> # example: nginx | higress, defaults to "nginx"
|
||||
name: <ingress-name-that-is-related-the-service>
|
||||
gateway: # alternative： ingress or gateway-api
|
||||
httpRouteName: <gateway-api-httpRoute-name>
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="v1alpha1" label="v1alpha1">
|
||||
|
||||
```yaml
|
||||
apiVersion: rollouts.kruise.io/v1alpha1
|
||||
kind: Rollout
|
||||
|
|
@ -96,6 +192,9 @@ spec:
|
|||
httpRouteName: <gateway-api-httpRoute-name>
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
| Fields | Type | Defaults | Explanation |
|
||||
|-------------------------|--------|----------|---------------------------------------------------------------------------------------------------------------|
|
||||
| `service` | string | "" | Name of service that select the pods of bounded workload |
|
||||
|
|
@ -104,12 +203,53 @@ spec:
|
|||
| `ingress.classType` | string | "nginx" | Ingress type, such as "nginx", "higress", or others |
|
||||
| `ingress.name` | string | "" | Name of ingress resource that bounded the service |
|
||||
| `gateway.httpRouteName` | string | "" | Name of [HTTPRoute](https://gateway-api.sigs.k8s.io/concepts/api-overview/#httproute) resource of Gateway API |
|
||||
Note:
|
||||
- `ingress` and `gateway` can not be nil at the same time if you decide to use `trafficRoutings`.
|
||||
|
||||
**Note: `ingress` and `gateway` can not be nil at the same time if you decide to use `trafficRoutings`.**
|
||||
|
||||
### Strategy API (Mandatory)
|
||||
Describe your strategy of rollout:
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="v1beta1" label="v1beta1" default>
|
||||
|
||||
```yaml
|
||||
apiVersion: rollouts.kruise.io/v1beta1
|
||||
kind: Rollout
|
||||
metadata:
|
||||
namespace: <your-workload-ns>
|
||||
spec:
|
||||
strategy:
|
||||
canary:
|
||||
steps:
|
||||
# the first step
|
||||
- traffic: 5%
|
||||
replicas: 1 or 10%
|
||||
pause:
|
||||
duration: {}
|
||||
matches:
|
||||
- headers:
|
||||
- type: Exact # or "RegularExpression"
|
||||
name: <matched-header-name>
|
||||
value: <matched-header-value, or reg-expression>
|
||||
# the second step
|
||||
- traffic: 10%
|
||||
... ....
|
||||
```
|
||||
|
||||
| Fields | Type | Defaults | Explanation |
|
||||
|---------------------------|---------------------|-----------|----------------------------------------------------------------------------------------------------------------|
|
||||
| `steps[x].traffic` | *string | nil | (optional) Percent weight of canary traffic for new-version Pods. |
|
||||
| `steps[x].replicas` | *integer or *string | nil | Absolute number or Percent of new-version Pods. |
|
||||
| `steps[x].pause` | object | {} | (optional) Manual confirmation or auto confirmation before enter the next step. |
|
||||
| `steps[x].pause.duration` | *integer | nil | (optional) Duration time before auto confirmation. if nil, means need manual confirmation. |
|
||||
| `steps[x].matches` | []object | [] | (optional) The HTTP header match rules you want to traffic to new-version Pods. |
|
||||
| `headers[x].type` | string | "Exact" | "Exact" or "RegularExpression" rule to match key and value |
|
||||
| `headers[x].name` | string | "" | Matched HTTP header name. (And-Relationship between headers[i] and headers[j]) |
|
||||
| `headers[x].value` | string | "" | Matched HTTP header value. |
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="v1alpha1" label="v1alpha1">
|
||||
|
||||
```yaml
|
||||
apiVersion: rollouts.kruise.io/v1alpha1
|
||||
kind: Rollout
|
||||
|
|
@ -121,18 +261,19 @@ spec:
|
|||
steps:
|
||||
# the first step
|
||||
- weight: 5
|
||||
replicas:
|
||||
replicas: 1 or 10%
|
||||
pause:
|
||||
duration: 1000
|
||||
duration: {}
|
||||
matches:
|
||||
- headers:
|
||||
- type: Exact # or "RegularExpression"
|
||||
name: <matched-header-name>
|
||||
value: <matched-header-value, or reg-expression>
|
||||
- headers:
|
||||
- type: Exact # or "RegularExpression"
|
||||
name: <matched-header-name>
|
||||
value: <matched-header-value, or reg-expression>
|
||||
# the second step
|
||||
- weight: 10
|
||||
... ....
|
||||
```
|
||||
|
||||
| Fields | Type | Defaults | Explanation |
|
||||
|---------------------------|---------------------|-----------|----------------------------------------------------------------------------------------------------------------|
|
||||
| `steps[x].weight` | *integer | nil | (optional) Percent weight of canary traffic for new-version Pods. |
|
||||
|
|
@ -143,18 +284,50 @@ spec:
|
|||
| `headers[x].type` | string | "Exact" | "Exact" or "RegularExpression" rule to match key and value |
|
||||
| `headers[x].name` | string | "" | Matched HTTP header name. (And-Relationship between headers[i] and headers[j]) |
|
||||
| `headers[x].value` | string | "" | Matched HTTP header value. |
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
Note:
|
||||
- `steps[x].weight` and `steps[x].replicas` can not be nil at the same time.
|
||||
- `steps[x].matches[i] and steps[x].matches[j]` have **Or**-relationship;
|
||||
- `steps[x].matches[y].headers[i] and steps[x].matches[y].header[j]` have **And**-relationship;
|
||||
- `steps[x].replicas` can not be nil.
|
||||
- `steps[x].matches[i] and steps[x].matches[j]` have **Or**-relationship.
|
||||
- `steps[x].matches[y].headers[i] and steps[x].matches[y].header[j]` have **And**-relationship.
|
||||
|
||||
### Special Annotations of Rollout (Optional)
|
||||
There are some special annotations in Rollout to enable specific abilities.
|
||||
|
||||
| Annotations | Value | Defaults | Explanation |
|
||||
|-----------------------------------|-------------------------|----------|---------------------------------------------------------------------------------------------------------------------------------|
|
||||
| `rollouts.kruise.io/rolling-type` | "canary" or "partition" | "canary" | "canary" means using canary update strategy for Deployment; "partition" means using multi-batch update strategy for Deployment; |
|
||||
<Tabs>
|
||||
<TabItem value="v1beta1" label="v1beta1" default>
|
||||
|
||||
```
|
||||
apiVersion: rollouts.kruise.io/v1beta1
|
||||
kind: Rollout
|
||||
spec:
|
||||
strategy:
|
||||
canary:
|
||||
// Default is false.
|
||||
enableExtraWorkloadForCanary: true
|
||||
steps:
|
||||
...
|
||||
```
|
||||
|
||||
**Note:** "true" means using canary update strategy for Deployment; "false" means using multi-batch update strategy for Deployment;
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="v1alpha1" label="v1alpha1">
|
||||
|
||||
```
|
||||
apiVersion: rollouts.kruise.io/v1alpha1
|
||||
kind: Rollout
|
||||
metadata:
|
||||
annotations:
|
||||
# Default is "canary"
|
||||
rollouts.kruise.io/rolling-type: "canary" or "partition"
|
||||
```
|
||||
|
||||
**Note:** "canary" means using canary update strategy for Deployment; "partition" means using multi-batch update strategy for Deployment;
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### Special Annotations of Workload (Optional)
|
||||
There are some special annotations in Bounded Workload to enable specific abilities.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,12 @@
|
|||
# Basic Usage Guide
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
This docs focuses on how to make Kruise Rollout effective and how to make a complete release, and answer some questions about usages.
|
||||
|
||||
**Note: v1beta1 available from Kruise Rollout v0.5.0.**
|
||||
|
||||
## A Complete Release Process
|
||||
|
||||
### Step 0: Requirements
|
||||
|
|
@ -38,6 +43,34 @@ Assume that you want to use multi-batch update strategy to upgrade your Deployme
|
|||
- In the 1-st batch: **Only 1** Pod should be upgraded;
|
||||
- In the 2-nd batch: **50%** Pods should be upgraded, i.e., **5 updated Pods**;
|
||||
- In the 3-rd batch: **100%** Pods should be upgradedm i.e., **10 updated Pods**.
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="v1beta1" label="v1beta1" default>
|
||||
|
||||
```bash
|
||||
$ kubectl apply -f - <<EOF
|
||||
apiVersion: rollouts.kruise.io/v1beta1
|
||||
kind: Rollout
|
||||
metadata:
|
||||
name: rollouts-demo
|
||||
namespace: default
|
||||
spec:
|
||||
workloadRef:
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
name: workload-demo
|
||||
strategy:
|
||||
canary:
|
||||
steps:
|
||||
- replicas: 1
|
||||
- replicas: 50%
|
||||
- replicas: 100%
|
||||
EOF
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="v1alpha1" label="v1alpha1">
|
||||
|
||||
```bash
|
||||
$ kubectl apply -f - <<EOF
|
||||
apiVersion: rollouts.kruise.io/v1alpha1
|
||||
|
|
@ -62,6 +95,10 @@ spec:
|
|||
EOF
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
### Step 2: Upgrade Deployment to "version-2" and release the 1-st batch
|
||||
```bash
|
||||
$ kubectl patch deployment workload-demo -p \
|
||||
|
|
@ -100,8 +137,8 @@ spec:
|
|||
canary:
|
||||
steps:
|
||||
- replicas: 1
|
||||
pause:
|
||||
duration: 0
|
||||
pause:
|
||||
duration: 0
|
||||
- ... ...
|
||||
```
|
||||
|
||||
|
|
@ -129,7 +166,7 @@ func IsRolloutCurrentStepReady(rollout *rolloutsv1alpha1.Rollout, stepIndex int3
|
|||
}
|
||||
```
|
||||
|
||||
But in some automatic scenes(e.g. PaaS platform), before judging whether current step is ready, we should know whether the `canaryStatus` is corresponding to the current rollout processes (Maybe it corresponds to the last rollout process).
|
||||
But in some automatic scenes(e.g. PaaS platform), before judging whether current step is ready, we should know whether the `canaryStatus` is corresponding to the current rollout processes (Maybe it corresponds to the last rollout process).
|
||||
We can use `rollout-id` mechanism to solve this problem.
|
||||
```go
|
||||
func IsRolloutCurrentStepReady(workload appsv1.Deployment, rollout *rolloutsv1alpha1.Rollout, stepIndex int32) bool {
|
||||
|
|
@ -154,7 +191,12 @@ func IsRolloutCurrentStepReady(workload appsv1.Deployment, rollout *rolloutsv1al
|
|||
|
||||
In fact, Kruise Rollout **DOES NOT** provide the ability to rollback directly. **Kruise Rollout prefers that users can rollback workload spec directly to rollback their application.** When users need to rollback from “version-2” to ”version-1“, Kruise Rollout will use the native rolling upgrade strategy to quickly rollback, instead of following the multi-batch checkpoint strategy.
|
||||
|
||||
### 1. Apply your old version yaml to kubernetes
|
||||
You can refer the [step 6 of document](https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/use-kruise-rollout-to-perform-canary-releases-and-a-b-testing?spm=a2c4g.11186623.0.0.60f56abdcxjXXM#section-maw-6wb-cql).
|
||||
|
||||
### 2. Gitops sync old revision
|
||||
You can ref the [step 4 of document](https://help.aliyun.com/zh/ack/distributed-cloud-container-platform-for-kubernetes/use-cases/using-kruise-rollout-to-implement-canary-release-based-on-ack-one-gitops?spm=a2c4g.11186623.0.0.5ed9474b2PNGPz).
|
||||
|
||||
## Other Statements
|
||||
- **Continuous Release**: Assume that Rollout is progressing from "version-1" to "version-2"(uncompleted). Now, workload is modified to "version-3", Rollout will start to progress from beginning step (1-st step).
|
||||
- **HPA compatible**: Assume that you config HPA to your workload and use multi-batch update strategy, we suggest to use "Percent" to specify "steps[x].replicas". If replicas is scaled up/down during rollout progressing, the old and new version replicas will be scaled according the "Percent" configuration.
|
||||
- **HPA compatible**: Assume that you config HPA to your workload and use multi-batch update strategy, we suggest to use "Percent" to specify "steps[x].replicas". If replicas is scaled up/down during rollout progressing, the old and new version replicas will be scaled according the "Percent" configuration.
|
||||
|
|
|
|||
|
|
@ -1,17 +1,55 @@
|
|||
# A/B Testing
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
## A/B Testing Process
|
||||
A process of A/B Tesing combing with **canary release**:
|
||||
|
||||
|
||||
|
||||
## Configuration Example
|
||||
**Note: Currently, A/B Testing strategy can work on CloneSet, StatefulSet, Advanced StatefulSet, and Deployment.**
|
||||
|
||||
**Note: v1beta1 available from Kruise Rollout v0.5.0.**
|
||||
|
||||
In fact, A/B Testing need to combine with canary or multi-batch release strategy, as shown in picture above.
|
||||
|
||||
Next we will give an example about **A/B Testing with multi-batch release strategy**:
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="v1beta1" label="v1beta1" default>
|
||||
|
||||
```YAML
|
||||
apiVersion: rollouts.kruise.io/v1beta1
|
||||
kind: Rollout
|
||||
metadata:
|
||||
name: rollouts-demo
|
||||
spec:
|
||||
workloadRef:
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
name: workload-demo
|
||||
strategy:
|
||||
canary:
|
||||
steps:
|
||||
- replicas: 1
|
||||
matches:
|
||||
- headers:
|
||||
- name: user-agent
|
||||
type: Exact
|
||||
value: pc
|
||||
- replicas: 50%
|
||||
- replicas: 100%
|
||||
trafficRoutings:
|
||||
- service: service-demo
|
||||
ingress:
|
||||
classType: nginx
|
||||
name: ingress-demo
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="v1alpha1" label="v1alpha1">
|
||||
|
||||
```YAML
|
||||
apiVersion: rollouts.kruise.io/v1alpha1
|
||||
kind: Rollout
|
||||
|
|
@ -36,13 +74,18 @@ spec:
|
|||
value: pc
|
||||
- replicas: 50%
|
||||
- replicas: 100%
|
||||
trafficRoutings:
|
||||
- service: service-demo
|
||||
ingress:
|
||||
classType: nginx
|
||||
name: ingress-demo
|
||||
trafficRoutings:
|
||||
- service: service-demo
|
||||
ingress:
|
||||
classType: nginx
|
||||
name: ingress-demo
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
**Note: Currently, A/B Testing strategy can work on CloneSet, StatefulSet, Advanced StatefulSet, and Deployment.**
|
||||
|
||||
### Behavior Explanation
|
||||
|
||||
When you apply a new revision for `workload-demo`:
|
||||
|
|
|
|||
|
|
@ -1,10 +1,43 @@
|
|||
# Canary Release
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
## Canary Release Process
|
||||
|
||||
|
||||
## Recommended Configuration
|
||||
**Note: Canary Strategy only works on Deployment.**
|
||||
|
||||
**Note: v1beta1 available from Kruise Rollout v0.5.0.**
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="v1beta1" label="v1beta1" default>
|
||||
|
||||
```YAML
|
||||
apiVersion: rollouts.kruise.io/v1beta1
|
||||
kind: Rollout
|
||||
metadata:
|
||||
name: rollouts-demo
|
||||
spec:
|
||||
workloadRef:
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
name: workload-demo
|
||||
strategy:
|
||||
canary:
|
||||
enableExtraWorkloadForCanary: true
|
||||
steps:
|
||||
- traffic: 20%
|
||||
replicas: 20%
|
||||
trafficRoutings:
|
||||
- service: service-demo
|
||||
ingress:
|
||||
classType: nginx
|
||||
name: ingress-demo
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="v1alpha1" label="v1alpha1">
|
||||
|
||||
```YAML
|
||||
apiVersion: rollouts.kruise.io/v1alpha1
|
||||
|
|
@ -23,13 +56,16 @@ spec:
|
|||
canary:
|
||||
steps:
|
||||
- weight: 20
|
||||
trafficRoutings:
|
||||
- service: service-demo
|
||||
ingress:
|
||||
classType: nginx
|
||||
name: ingress-demo
|
||||
trafficRoutings:
|
||||
- service: service-demo
|
||||
ingress:
|
||||
classType: nginx
|
||||
name: ingress-demo
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
### Behavior Explanation
|
||||
When you apply a new revision for `workload-demo`:
|
||||
- The workload `workload-demo` will be paused, and no Pod is updated;
|
||||
|
|
|
|||
|
|
@ -1,10 +1,39 @@
|
|||
# Multi-Batch Release
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
## Multi-Batch Strategy Process
|
||||
|
||||
|
||||
## Recommended Configuration
|
||||
**Note: Currently, multi-batch strategy can work on CloneSet, StatefulSet, Advanced StatefulSet, and Deployment.**
|
||||
|
||||
**Note: v1beta1 available from Kruise Rollout v0.5.0.**
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="v1beta1" label="v1beta1" default>
|
||||
|
||||
```YAML
|
||||
apiVersion: rollouts.kruise.io/v1beta1
|
||||
kind: Rollout
|
||||
metadata:
|
||||
name: rollouts-demo
|
||||
spec:
|
||||
workloadRef:
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
name: workload-demo
|
||||
strategy:
|
||||
canary:
|
||||
enableExtraWorkloadForCanary: false
|
||||
steps:
|
||||
- replicas: 1
|
||||
- replicas: 50%
|
||||
- replicas: 100%
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="v1alpha1" label="v1alpha1">
|
||||
|
||||
```YAML
|
||||
apiVersion: rollouts.kruise.io/v1alpha1
|
||||
|
|
@ -27,6 +56,12 @@ spec:
|
|||
- replicas: 100%
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
|
||||
**Note: Currently, multi-batch strategy can work on CloneSet, StatefulSet, Advanced StatefulSet, and Deployment.**
|
||||
|
||||
### Behavior Explanation
|
||||
When you apply a new revision for `workload-demo`:
|
||||
- `1` Pods will be updated and `replicas-1` Pods is still at stable revision in the 1-st batch, need manual confirmation to next batch.
|
||||
|
|
|
|||
|
|
@ -36,5 +36,21 @@ module.exports = {
|
|||
}
|
||||
],
|
||||
},
|
||||
{
|
||||
type: 'category',
|
||||
label: 'Developer manuals',
|
||||
collapsed: false,
|
||||
items: [
|
||||
'developer-manuals/custom-network-provider'
|
||||
],
|
||||
},
|
||||
{
|
||||
type: 'category',
|
||||
label: 'Best Practices',
|
||||
collapsed: false,
|
||||
items: [
|
||||
'best-practices/traffic-routing-istio-api'
|
||||
],
|
||||
},
|
||||
],
|
||||
};
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@
|
|||
--ifm-color-primary-light: rgb(70, 203, 174);
|
||||
--ifm-color-primary-lighter: rgb(102, 212, 189);
|
||||
--ifm-color-primary-lightest: rgb(146, 224, 208);
|
||||
--ifm-code-font-size: 70%;
|
||||
--ifm-code-font-size: 90%;
|
||||
|
||||
--hero-border-color: rgba(0, 0, 0, 0.1);
|
||||
}
|
||||
|
|
@ -55,7 +55,7 @@ table th {
|
|||
}
|
||||
|
||||
table td {
|
||||
--ifm-code-font-size: 70%;
|
||||
--ifm-code-font-size: 95%;
|
||||
font-size: 0.8rem;
|
||||
}
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue