Follow metallb's node election

[mstarostik]

metallb has its own ARP handling, so assigning floating IPs to nodes manually should not be needed. If hcloud-fip-controller simply assigned each floating IP to the node metallb has elected for this service, this tandem would Just Work (TM) without any static IP config on the nodes.

See also https://github.com/hetznercloud/hcloud-cloud-controller-manager/issues/6#issuecomment-619083068

[cbeneke]

Hey, thanks for raising the issue! One of the long-term goals was to acutally build the FIP controller in a metalLB independent way (as in to handle floating IP <-> Loadbalancer service mapping inside of the controller instead of relying on metalLB to do so).

I have to evaluate which way this project should go, because following the metalLB election (if easily possible) has some implication on the controller and multi-IP* support @phiphi282 is currently working on.

*Edit: Multi-IP as in schedule multiple IPs on multiple nodes

[yousafsyed-bg]

@cbeneke Another problem that I am facing is to limit the fip-controller to bind floating_IPs to a specific set of nodes based on labels, I know that I can do this by the name of a node but I was wondering if I there is a solution to allow binding on a group of nodes and not all nodes.

Edit: Just to clarify, I don't want floating IPs to be attached to some node-pools because they don't have access to the public network. Does Floating IP gets attached to the nodes where there is a fip-controller pod? If that's the case then maybe I can use anti-affinity for the deployment

[cbeneke]

@yousafsyed-bg Yes, the current implementation only assignes the IPs to the node where the leading fip-controller is scheduled (or to be specific: To the node which is invoked via the NODE_NAME env variable, which should be a reference to the current scheduled node (compare https://github.com/cbeneke/hcloud-fip-controller/blob/master/deploy/deployment.yaml#L26-L29)).

Also compare https://github.com/cbeneke/hcloud-fip-controller/issues/31 :)

[yousafsyed-bg]

@cbeneke Thanks for replying, this is saving my live love the answer. thanks

[mstarostik]

One of the long-term goals was to acutally build the FIP controller in a metalLB independent way (as in to handle floating IP <-> Loadbalancer service mapping inside of the controller instead of relying on metalLB to do so).

Sounds great! While looking further I came across this project now: https://github.com/costela/hcloud-ip-floater which does it the other way round by simply applying the floating IPs to the nodes the LB expects them on. Has a few glitches still though. Guess I'll keep experimenting with both ways.

To put things into context, I'm trying to avoid manual configuration of floating IPs on each node's interface because it simply adds another location for repeating the list of IPs and complicates the deployment process by adding more custom node config. I'm currently trying out k3OS and static IP config isn't really a standard feature there at all :) I played with applying the IPs from a DaemonSet with host networking. Works, but still adds some complexity.

[ghorofamike]

came across this project now: https://github.com/costela/hcloud-ip-floater which does it the other way >round by simply applying the floating IPs to the nodes the LB expects them on. Has a few glitches still >though. Guess I'll keep experimenting with both wa

I'm curious what glitches have you met?

[mstarostik]

Haven't had too much time for the project meanwhile. But it sometimes lost track of things and needed pod restarts.

[MohammedNoureldin]

Is there any news regarding following MetalLB advertising node?

[cbeneke]

Hey @MohammedNoureldin, unfortunately not from my side, and as far as I'm aware also @phiphi282 is quite booked work-wise. Happy to take PRs though if you like to implement this :)