You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: applications/deployments/route-based-deployment-strategies.adoc
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -21,7 +21,7 @@ for more on the basic strategy types.
21
21
22
22
The most common route-based strategy is to use a _blue-green deployment_. The new version (the green version) is brought up for testing and evaluation, while the users still use the stable version (the blue version). When ready, the users are switched to the green version. If a problem arises, you can switch back to the blue version.
23
23
24
-
A common alternative strategy is to use _A/B versions_that are both active at the same time and some users use one version, and some users use the other version. This can be used for experimenting with user interface changes and other features to get user feedback. It can also be used to verify proper operation in a production context where problems impact a limited number of users.
24
+
Alternatively, you can use an _A/B versions_strategy in which both versions are active at the same time. With this strategy, some users can use _version A_, and other users can use _version B_. You can use this strategy to experiment with user interface changes or other features in order to get user feedback. You can also use it to verify proper operation in a production context where problems impact a limited number of users.
25
25
26
26
A canary deployment tests the new version but when a problem is detected it quickly falls back to the previous version. This can be done with both of the above strategies.
Copy file name to clipboardExpand all lines: modules/deployments-ab-testing-lb.adoc
+16-3Lines changed: 16 additions & 3 deletions
Original file line number
Diff line number
Diff line change
@@ -10,7 +10,7 @@ The user sets up a route with multiple services. Each service handles a version
10
10
11
11
Each service is assigned a `weight` and the portion of requests to each service is the `service_weight` divided by the `sum_of_weights`. The `weight` for each service is distributed to the service's endpoints so that the sum of the endpoint `weights` is the service `weight`.
12
12
13
-
The route can have up to four services. The `weight` for the service can be between `0` and `256`. When the `weight` is `0`, the service does not participate in load-balancing but continues to serve existing persistent connections. When the service `weight` is not `0`, each endpoint has a minimum `weight` of `1`. Because of this, a service with a lot of endpoints can end up with higher `weight` than intended. In this case, reduce the number of pods to get the expected load balance `weight`.
13
+
The route can have up to four services. The `weight` for the service can be between `0` and `256`. When the `weight` is `0`, the service does not participate in loadbalancing but continues to serve existing persistent connections. When the service `weight` is not `0`, each endpoint has a minimum `weight` of `1`. Because of this, a service with a lot of endpoints can end up with higher `weight` than intended. In this case, reduce the number of pods to get the expected load balance `weight`.
14
14
15
15
////
16
16
See the
@@ -56,10 +56,10 @@ Browse to the application at `ab-example-a.<project>.<router_domain>` to verify
56
56
+
57
57
[NOTE]
58
58
====
59
-
When using `alternateBackends`, also use the `roundrobin` load-balancing strategy to ensure requests are distributed as expected to the services based on weight. `roundrobin` can be set for a route by using a link:https://docs.openshift.com/container-platform/4.13/networking/routes/route-configuration.html#nw-route-specific-annotations_route-configuration[route annotation].
59
+
When using `alternateBackends`, also use the `roundrobin` loadbalancing strategy to ensure requests are distributed as expected to the services based on weight. `roundrobin` can be set for a route by using a link:https://docs.openshift.com/container-platform/4.13/networking/routes/route-configuration.html#nw-route-specific-annotations_route-configuration[route annotation].
60
60
====
61
61
+
62
-
Setting the `oc set route-backend` to `0` means the service does not participate in load-balancing, but continues to serve existing persistent connections.
62
+
Setting the `oc set route-backend` to `0` means the service does not participate in loadbalancing, but continues to serve existing persistent connections.
63
63
+
64
64
[NOTE]
65
65
====
@@ -168,6 +168,19 @@ routes/ab-example Service ab-example-a 198 (99%)
168
168
routes/ab-example Service ab-example-b 2 (1%)
169
169
----
170
170
171
+
. To override the default values for the load balancing algorithm, adjust the annotation on the route by setting the algorithm to `roundrobin`. For a route on {product-title}, the default load balancing algorithm is set to `random` or `source` values.
172
+
173
+
+
174
+
To set the algorithm to `roundrobin`, run the command:
For Transport Layer Security (TLS) passthrough routes, the default value is `source`. For all other routes, the default is `random`.
182
+
183
+
171
184
. To alter the weight of an individual service relative to itself or to the primary service, use the `--adjust` flag. Specifying a percentage adjusts the service relative to either the primary or the first alternate (if you specify the primary). If there are other backends, their weights are kept proportional to the changed.
172
185
+
173
186
The following example alters the weight of `ab-example-a` and `ab-example-b` services:
0 commit comments