diff --git a/applications/deployments/route-based-deployment-strategies.adoc b/applications/deployments/route-based-deployment-strategies.adoc index cc1e6b5a57..5b5a5adf89 100644 --- a/applications/deployments/route-based-deployment-strategies.adoc +++ b/applications/deployments/route-based-deployment-strategies.adoc @@ -21,7 +21,7 @@ for more on the basic strategy types. 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. -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. +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. 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. diff --git a/modules/deployments-ab-testing-lb.adoc b/modules/deployments-ab-testing-lb.adoc index b5b3dd4d3f..f3b0780e0b 100644 --- a/modules/deployments-ab-testing-lb.adoc +++ b/modules/deployments-ab-testing-lb.adoc @@ -10,7 +10,7 @@ The user sets up a route with multiple services. Each service handles a version 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`. -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`. +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`. //// See the @@ -56,10 +56,10 @@ Browse to the application at `ab-example-a..` to verify + [NOTE] ==== -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]. +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]. ==== + -Setting the `oc set route-backend` to `0` means the service does not participate in load-balancing, but continues to serve existing persistent connections. +Setting the `oc set route-backend` to `0` means the service does not participate in load balancing, but continues to serve existing persistent connections. + [NOTE] ==== @@ -168,6 +168,19 @@ routes/ab-example Service ab-example-a 198 (99%) routes/ab-example Service ab-example-b 2 (1%) ---- +. 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. + ++ +To set the algorithm to `roundrobin`, run the command: ++ +[source,terminal] +---- +$ oc annotate routes/ haproxy.router.openshift.io/balance=roundrobin +---- ++ +For Transport Layer Security (TLS) passthrough routes, the default value is `source`. For all other routes, the default is `random`. + + . 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. + The following example alters the weight of `ab-example-a` and `ab-example-b` services: