Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

#

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

[WRR] extending documentation #958

Merged
merged 1 commit into from
Sep 23, 2022
+4 −0
Merged

[WRR] extending documentation #958

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions docs/index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -148,6 +148,7 @@ If the Pods in cluster **Y** were to once again become healthy (liveness and rea

The following load balancing strategies, as it relates to resolving Ingress node IPs, should be provided as part of the initial implementation:
* **roundRobin**
* **weightRoundRobin**
* **failover**
* **geoip**

Expand Down
3 changes: 3 additions & 0 deletions docs/strategy.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,9 @@
## roundRobin
Returns both cluster endpoints in round-robin manner.

## weight roundRobin
While roundRobin is fair for all regions, with WeightRoundRobin we can set explicitly how the regions should be loaded with traffic. For example, we can set one region to handle 80% of the traffic, another 20% and a third 0%, so that the last region is practically disabled.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: s/a third/the third/g
otherwise lgtm!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

actually it's ok


## failover
Pinned to a specified primary cluster until workload on that cluster has no available Pods, upon which the next available cluster's Ingress node IPs will be resolved. When Pods are again available on the primary cluster, the primary cluster will once again be the only eligible cluster for which cluster Ingress node IPs will be resolved

Expand Down