Skip to content

Commit e1f4c6a

Browse files
author
Brendan Daly
committed
OCPBUGS-19072:updating text
1 parent ad1d72b commit e1f4c6a

File tree

2 files changed

+17
-4
lines changed

2 files changed

+17
-4
lines changed

applications/deployments/route-based-deployment-strategies.adoc

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -21,7 +21,7 @@ for more on the basic strategy types.
2121

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

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

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

modules/deployments-ab-testing-lb.adoc

Lines changed: 16 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -10,7 +10,7 @@ The user sets up a route with multiple services. Each service handles a version
1010

1111
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`.
1212

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

1515
////
1616
See the
@@ -56,10 +56,10 @@ Browse to the application at `ab-example-a.<project>.<router_domain>` to verify
5656
+
5757
[NOTE]
5858
====
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` 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].
6060
====
6161
+
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 load balancing, but continues to serve existing persistent connections.
6363
+
6464
[NOTE]
6565
====
@@ -168,6 +168,19 @@ routes/ab-example Service ab-example-a 198 (99%)
168168
routes/ab-example Service ab-example-b 2 (1%)
169169
----
170170

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:
175+
+
176+
[source,terminal]
177+
----
178+
$ oc annotate routes/<route-name> haproxy.router.openshift.io/balance=roundrobin
179+
----
180+
+
181+
For Transport Layer Security (TLS) passthrough routes, the default value is `source`. For all other routes, the default is `random`.
182+
183+
171184
. 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.
172185
+
173186
The following example alters the weight of `ab-example-a` and `ab-example-b` services:

0 commit comments

Comments
 (0)