From be92e155e7f9d4ee3e754babd774a6f9e5b05828 Mon Sep 17 00:00:00 2001 From: berg Date: Tue, 19 Dec 2023 11:00:01 +0800 Subject: [PATCH] kruise rollout v0.5.0 (#151) Signed-off-by: liheng.zms --- .../traffic-routing-istio-api.md | 30 +-- .../custom-network-provider.md | 46 ++-- rollouts/installation.md | 8 +- rollouts/user-manuals/api-specifications.md | 219 ++++++++++++++++-- rollouts/user-manuals/basic-usage.md | 50 +++- rollouts/user-manuals/strategy-ab-testing.md | 55 ++++- .../user-manuals/strategy-canary-update.md | 48 +++- .../strategy-multi-batch-update.md | 37 ++- sidebars-rollouts.js | 16 ++ src/css/custom.css | 4 +- 10 files changed, 430 insertions(+), 83 deletions(-) rename rollouts/{user-manuals => best-practices}/traffic-routing-istio-api.md (94%) rename rollouts/{user-manuals => developer-manuals}/custom-network-provider.md (94%) diff --git a/rollouts/user-manuals/traffic-routing-istio-api.md b/rollouts/best-practices/traffic-routing-istio-api.md similarity index 94% rename from rollouts/user-manuals/traffic-routing-istio-api.md rename to rollouts/best-practices/traffic-routing-istio-api.md index f75b18c6e..c6a06c1a7 100644 --- a/rollouts/user-manuals/traffic-routing-istio-api.md +++ b/rollouts/best-practices/traffic-routing-istio-api.md @@ -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. \ No newline at end of file +After that, the release is done and your are ready to use the new-version service. diff --git a/rollouts/user-manuals/custom-network-provider.md b/rollouts/developer-manuals/custom-network-provider.md similarity index 94% rename from rollouts/user-manuals/custom-network-provider.md rename to rollouts/developer-manuals/custom-network-provider.md index 95813f00e..44afbb254 100644 --- a/rollouts/user-manuals/custom-network-provider.md +++ b/rollouts/developer-manuals/custom-network-provider.md @@ -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 : | @@ -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 ... -``` \ No newline at end of file +``` diff --git a/rollouts/installation.md b/rollouts/installation.md index 2419b00f7..5cb13ce8a 100644 --- a/rollouts/installation.md +++ b/rollouts/installation.md @@ -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 diff --git a/rollouts/user-manuals/api-specifications.md b/rollouts/user-manuals/api-specifications.md index dd9341272..039c8f969 100644 --- a/rollouts/user-manuals/api-specifications.md +++ b/rollouts/user-manuals/api-specifications.md @@ -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.** + + + + ```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 +``` + + + + +```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 ``` + + + 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: + + + +```yaml +apiVersion: rollouts.kruise.io/v1beta1 +kind: Rollout +metadata: + namespace: +spec: + workloadRef: + apiVersion: apps/v1 + kind: StatefulSet + name: +``` + + + + ```yaml apiVersion: rollouts.kruise.io/v1alpha1 kind: Rollout @@ -65,6 +137,10 @@ spec: kind: StatefulSet name: ``` + + + + | 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: + + + +```yaml +apiVersion: rollouts.kruise.io/v1beta1 +kind: Rollout +metadata: + namespace: +spec: + trafficRoutings: + - service: + ingress: + classType: # example: nginx | higress, defaults to "nginx" + name: + gateway: # alternative： ingress or gateway-api + httpRouteName: +``` + + + + ```yaml apiVersion: rollouts.kruise.io/v1alpha1 kind: Rollout @@ -96,6 +192,9 @@ spec: httpRouteName: ``` + + + | 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: + + + +```yaml +apiVersion: rollouts.kruise.io/v1beta1 +kind: Rollout +metadata: + namespace: +spec: + strategy: + canary: + steps: + # the first step + - traffic: 5% + replicas: 1 or 10% + pause: + duration: {} + matches: + - headers: + - type: Exact # or "RegularExpression" + name: + value: + # 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. | + + + + ```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: - value: + - headers: + - type: Exact # or "RegularExpression" + name: + value: # 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. | + + + + 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; | + + +``` +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; + + + + +``` +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; + + + ### Special Annotations of Workload (Optional) There are some special annotations in Bounded Workload to enable specific abilities. diff --git a/rollouts/user-manuals/basic-usage.md b/rollouts/user-manuals/basic-usage.md index 0860aaaf9..a8a14e928 100644 --- a/rollouts/user-manuals/basic-usage.md +++ b/rollouts/user-manuals/basic-usage.md @@ -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**. + + + + +```bash +$ kubectl apply -f - < + + ```bash $ kubectl apply -f - < + + + ### 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. \ No newline at end of file +- **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. diff --git a/rollouts/user-manuals/strategy-ab-testing.md b/rollouts/user-manuals/strategy-ab-testing.md index a293fdea5..725f26c88 100644 --- a/rollouts/user-manuals/strategy-ab-testing.md +++ b/rollouts/user-manuals/strategy-ab-testing.md @@ -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**: ![ab](../../static/img/rollouts/ab-testing.jpg) ## 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**: + + + +```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 +``` + + + + ```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 ``` + + + +**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`: diff --git a/rollouts/user-manuals/strategy-canary-update.md b/rollouts/user-manuals/strategy-canary-update.md index 1910615a0..caf79305b 100644 --- a/rollouts/user-manuals/strategy-canary-update.md +++ b/rollouts/user-manuals/strategy-canary-update.md @@ -1,10 +1,43 @@ # Canary Release +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + ## Canary Release Process ![ab](../../static/img/rollouts/canary.jpg) ## Recommended Configuration -**Note: Canary Strategy only works on Deployment.** + +**Note: v1beta1 available from Kruise Rollout v0.5.0.** + + + + +```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 +``` + + + ```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 ``` + + + ### Behavior Explanation When you apply a new revision for `workload-demo`: - The workload `workload-demo` will be paused, and no Pod is updated; diff --git a/rollouts/user-manuals/strategy-multi-batch-update.md b/rollouts/user-manuals/strategy-multi-batch-update.md index a6a3eebc5..d3c0812bb 100644 --- a/rollouts/user-manuals/strategy-multi-batch-update.md +++ b/rollouts/user-manuals/strategy-multi-batch-update.md @@ -1,10 +1,39 @@ # Multi-Batch Release +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + ## Multi-Batch Strategy Process ![ab](../../static/img/rollouts/multi-batch.jpg) ## 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.** + + + + +```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% +``` + + + ```YAML apiVersion: rollouts.kruise.io/v1alpha1 @@ -27,6 +56,12 @@ spec: - replicas: 100% ``` + + + + +**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. diff --git a/sidebars-rollouts.js b/sidebars-rollouts.js index fd7d80dda..08ee29dd3 100644 --- a/sidebars-rollouts.js +++ b/sidebars-rollouts.js @@ -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' + ], + }, ], }; diff --git a/src/css/custom.css b/src/css/custom.css index ba4db7bba..b349416d4 100644 --- a/src/css/custom.css +++ b/src/css/custom.css @@ -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; }