compumike
Add to README that Kubernetes now has native support for this since v1.32
I've been using hairpin-proxy since 2021. Thanks a lot for this project - it has saved me a lot of headaches on multiple projects already.
Since KEP 1860, Kubernetes now has support for LoadBalancer Services for which the external load balancers are not idempotent. For example, load balancers that perform TLS termination or prepend the PROXY protocol bytes. KEP 1860 is beta in k8s v1.30, and GA in v1.32.
For this, it is necessary that the cloud provider specific CCM sets the status.loadBalancer.ingress[*].ipMode to Proxy instead of the default VIP. If the CNI overrides kube-proxy, it must also support ipMode – this is the case for Cilium v1.17.0+ and v1.18.1+. In these cases, Kubernetes doesn't perform path optimisation and always sends the traffic to the external load balancer instead of to the internal destination.
In other words: as long as the CCM sets the ipMode properly and the cluster is running k8s v1.30+ and a supporting CNI, hairpin-proxy is no longer necessary. This is the "proper fix" for this issue, and if the ipMode is not set properly, engineers should first contact their cloud provider. hairpin-proxy is still a great workaround for if that fix is not possible or not imminent.
I'm not sure how this is with other cloud CCMs but the Scaleway CCM implements this since version 0.33.0.
