[lfx-mentorship-2026-Mar-May] Optimize long connection load balance and support more load balance algorithm

[LiZhenCheng9527]

• Description: Kmesh employs eBPF for load balancing. However, at present it only supports short-lived connections and offers a limited range of load balancing algorithms. Consequently, we aim to support a broader range of load balancing capabilities.
• Expected Outcome:
  • 1. Load balancing with load-dependent connections via eBPF.
  • 2. Support as many load balancing algorithms as possible
    • 2.1 Sticky Round Robin
    • 2.2 Weighted Round Robin
    • 2.3 ...
  • 3. Userguide and Proposal
  • 4. Unit Test and E2E test
• Recommended Skills: go, docker , kind, service mesh
• Mentor(s):
  • xin liu(@bitcoffeeiux, liuxin350@huawei.com),
  • mingyi zhang(@lec-bit, zhangmingyi5@huawei.com)

[NandaniThakur]

Hello,

I’ve set up kmesh locally and analyzed the current eBPF-based load balancing behavior in the context of this issue.

From my analysis, kmesh currently relies on Maglev-based consistent hashing (pkg/consistenthash/maglev) to build a static lookup table that maps flows to backends. While this works well for short-lived connections, backend selection lacks runtime load feedback and therefore cannot make load-dependent decisions once connections are established.

When connections persist, backend load changes dynamically while the Maglev-based selection remains fixed. In this sense, the current behavior does not fully satisfy “load balancing with load-dependent connections via eBPF”, since connection load is not tracked or used during backend selection.

My understanding of the expected outcome is to make backend selection connection-aware and load-dependent, while also enabling support for additional load balancing algorithms (e.g. Sticky RR, WRR).

To address this, I believe an incremental approach would be most effective:

• keep Maglev as the default,
• introduce a pluggable load balancer abstraction,
• add a connection-aware algorithm (e.g. Least-Connections),
• leverage eBPF to track per-backend connection load,
• and split the work into small, reviewable PRs.

I plan to start with a design proposal PR to align on this approach before moving into implementation.
I’d really appreciate feedback on whether this direction aligns with your expectations.
Thanks!