-
Notifications
You must be signed in to change notification settings - Fork 131
add proposal for Locality LoadBalance #574
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Welcome @derekwin! It looks like this is your first PR to kmesh-net/kmesh 🎉 |
Would you like to share your issue at Thursday's community meeting? |
|
||
### Motivation | ||
|
||
Currently, kmesh does not support locality topology-aware load balancing. Locality Load Balancing optimizes performance and reliability in distributed systems by directing traffic to the nearest service instances. This reduces latency, enhances availability, and lowers costs associated with cross-region data transfers. It also helps ensure compliance with data sovereignty regulations and improves overall user experience by providing faster and more reliable service responses. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently, kmesh does not support locality topology-aware load balancing. Locality Load Balancing optimizes performance and reliability in distributed systems by directing traffic to the nearest service instances. This reduces latency, enhances availability, and lowers costs associated with cross-region data transfers. It also helps ensure compliance with data sovereignty regulations and improves overall user experience by providing faster and more reliable service responses. | |
Currently, Kmesh does not support locality topology-aware load balancing. Locality Load Balancing optimizes performance and reliability in distributed systems by directing traffic to the nearest service instances. This reduces latency, enhances availability, and lowers costs associated with cross-region data transfers. It also helps ensure compliance with data sovereignty regulations and improves overall user experience by providing faster and more reliable service responses. |
Unified capitalisation of initial letters in Kmesh
|
||
#### case 1. locality failover | ||
1. Destination Rule | ||
Same as Istion. Parse rules specify configuration for Locality load balancing. (todo: outlier detection settings to detect and evict unhealthy hosts from the load balancing pool.) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what is istion? Istio?
/ok-to-test |
Codecov ReportAll modified and coverable lines are covered by tests ✅
see 29 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
|
|
||
Currently, kmesh does not support locality topology-aware load balancing. Locality Load Balancing optimizes performance and reliability in distributed systems by directing traffic to the nearest service instances. This reduces latency, enhances availability, and lowers costs associated with cross-region data transfers. It also helps ensure compliance with data sovereignty regulations and improves overall user experience by providing faster and more reliable service responses. | ||
|
||
#### Goals |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#### Goals | |
### Goals |
|
||
1. prioritize add locality load balancing capabilities in the workload mode. | ||
|
||
2. two types of locality load balancing : locality failover, locality weighted distribution. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure how locality weighted distribution can be implemented in workload mode. The workload api does not support weight actually
#### case 1. locality failover | ||
1. Destination Rule | ||
Same as Istion. Parse rules specify configuration for Locality load balancing. (todo: outlier detection settings to detect and evict unhealthy hosts from the load balancing pool.) | ||
- Outlier detection should occur before load balancing. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This does not suite worklaod mode as workload api does not include outlier setting. It do LB based on where the endpoint resides.
yes |
I have updated the proposal. |
Propose a new implementation for a location matching algorithm that avoids circular computations while also reducing the amount of data needed to be stored in BPF maps. detail: https://github.com/derekwin/treemap/tree/master |
if no conflict, there is no need to merge main branch.
then fix some conflicts, and then
the DCO github action failed, because it asks you to commit with your signature, which can be attached with
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wish to see more api design instead of function implement in the proposal
How do you express the priority level, and how do you match the client locality with the endpoints
|
||
1. prioritize add locality load balancing capabilities in the workload mode. | ||
|
||
2. locality load balancing mode: locality failover. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how about strict mode
``` | ||
https://pkg.go.dev/istio.io/istio/pkg/workloadapi#LoadBalancing_Scope | ||
|
||
2. calculate locality match rank |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
group endpoints with prority
|
||
3. choose endpoint | ||
|
||
Randomly select one endpoint from the group with the highest rank as the service backend. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Randomly select one endpoint from the group with the highest rank as the service backend. | |
Randomly select one endpoint from the group with the highest priority |
And add more comments what we do if all the endpoints of high priority is unhealthy
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And for the strict mode, how would you select the endpoint, i would like to see that
|
||
4. maybe more? Panic threshold | ||
|
||
When the proportion of healthy endpoints in the high-rank group falls below the panic threshold, select endpoints from the next rank group. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I donot care about this at first. First respect workload healthy status
__u32 waypoint_addr; | ||
__u32 waypoint_port; | ||
// 增加健康状态 healthStatus | ||
// 增加locality信息 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please supplement what does this field look like.
ok. |
I have updated the content of this proposal, and the documentation in the website repo will be updated soon. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
almost lgtm
7. For the random policy, all endpoints are marked with a priority of 0. For failover or strict policy, the priority is set to 0 for the endpoint with the highest match according to the `routingPreference`. | ||
|
||
#### control flow | ||
 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please center the image
/lgtm |
Signed-off-by: seclee <[email protected]> Signed-off-by: derekwin <[email protected]>
Signed-off-by: seclee <[email protected]> Signed-off-by: derekwin <[email protected]>
Signed-off-by: derekwin <[email protected]>
Signed-off-by: derekwin <[email protected]>
Signed-off-by: derekwin <[email protected]>
Signed-off-by: derekwin <[email protected]>
Signed-off-by: derekwin <[email protected]>
Co-authored-by: lizhencheng <[email protected]> Signed-off-by: derekwin <[email protected]>
Signed-off-by: derekwin <[email protected]>
/lgtm |
@hzxuzhonghu Can this PR be merged? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: hzxuzhonghu The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
What type of PR is this?
/kind enhancement
What this PR does / why we need it:
add proposal for Locality LB