Metallb: Feature Request: Supporting Proxy Protocol v2

[alibo]

Hi everyone!

Problem

It's not possible to preserve source IP (client IP) when service.spec.externalTrafficPolicy is set to Cluster.

Current Workaround

The current workaround is setting service.spec.externalTrafficPolicy to Local. But it has its own limitations:

1. The incoming traffic not balanced (when some pods are running on the same node)
2. IP of all worker nodes should be advertised with BGP and it increases the number of records of the routing table in the routers. Also, some routers have limitations for load-balancing the traffic between nodes more than X (16?) nodes.

Alternative solution: using Proxy Protocol v2 for TCP or UDP traffic:

What is "proxy protocol v2"?

https://developers.cloudflare.com/spectrum/proxy-protocol

Which LB providers have already implemented this feature?

• AWS: https://kubernetes.io/docs/concepts/services-networking/service/#proxy-protocol-support-on-aws (service.beta.kubernetes.io/aws-load-balancer-proxy-protocol)
• IBM: https://www.ibm.com/cloud/blog/know-your-real-clients-use-proxy-protocol-on-ibm-cloud-kubernetes-service (service.kubernetes.io/ibm-load-balancer-cloud-provider-enable-features: "proxy-protocol")
• F5: https://devcentral.f5.com/s/articles/How-to-persist-real-IP-into-Kubernetes
• Digitalocean: https://www.digitalocean.com/blog/load-balancers-now-support-proxy-protocol/
• OVH: https://docs.ovh.com/gb/en/load-balancer/proxyprotocol/

Implementation Ideas

Unfortunately, I'm not familiar with the code base of metallb, but I've investigated a little bit and I guess we can use mmproxy (from cloudflare) or go-mmproxy (from path.net) and deploy it as a sidecar to the speaker pods, but it's just a guess and I don't know the details. Also, there might be other options as well.

• https://blog.cloudflare.com/mmproxy-creative-way-of-preserving-client-ips-in-spectrum/
• https://blog.path.net/introducing-go-mmproxy/

[m-yosefpor]

+1 . That feature would be really nice to have.

[champtar]

Hi @alibo @m-yosefpor

A better way to preserve sourceIP is to use a CNI that support Direct Server Return, see #796.
MetalLB is controlplane only, making it part of the dataplane means we would be responsible for the performance of the system, so more bugs to fight, I personally don't see that happening.
Also Calico will soon be able to annonce LoadBalancers IP via BGP https://github.com/metallb/metallb/issues/114#issuecomment-754839513.