search

cbeneke / hcloud-fip-controller

Kubernetes controller to (re-)assign floating IPs on hetzner cloud instances
Apache License 2.0
123 stars 14 forks source link

Label node with active floating ip #43

Closed niklaskorz closed 4 years ago

niklaskorz commented 4 years ago

To be able to receive the client's source ip, I'd like to schedule the ingress controller on the node that currently has the floating ip assigned. I couldn't find a way to select nodes by their external ip address, but if there is, that'd make this even easier. What I had in mind was that the floating ip controller could just add a label to the node it is currently running on, therefore allowing the ingress controller to select the same node for deployment.

cbeneke commented 4 years ago

Hey,

this is a pretty specific use-case and afair labelling nodes requires PATCH or PUT rights on the node object. If this is the case I'm in heavy favor of not doing so (this is a pretty extensive right for a use-case which can probably be solved better).

I guess the most reliable way would be to check the holderIdentity of the lease from the floating IP controller and use the node which that pod is running on.

niklaskorz commented 4 years ago

Thanks for the insight! If I remember correctly, you mentioned wanting to directly handle LoadBalancer services in the controller in the future. In that case, a better alternative might be to (optionally) support the PROXY protocol, which is supported by many ingress controllers. In that case, the floating ip controller would have to act as a TCP load balancer and send the required PROXY packets along forwarded traffic.

niklaskorz commented 4 years ago

The protocol is specified here: http://www.haproxy.org/download/1.8/doc/proxy-protocol.txt

cbeneke commented 4 years ago

Hey, sorry for the long delay. The Idea was to implement the kubernetes LoadBalancer announcement in the cluster, not implementing a full loadbalancer. That would mean the functionality in terms of what the controller actually does (assigning hcloud floating IPs to nodes) would not be touched, it would just make the extra step of metalLB in the cluster obsolete.

Anyhow, the pod is running in the cluster and traffic goes through kube-proxy beforehand, that means even if the fip controller would be built in a way to handle and balance the traffic, it would still have no access to the client IP, since the traffic has to pass kube-proxy beforehand.

I'm closing here, since this is out of scope for what the controller is intended, if you have furhter questions and/or suggestions feel free to re-open :)