LoadBalancer IPAM: support IP assignment with `Service.spec.externalIPs/loadBalancerIP`

[defo89]

We use Calico for BGP peering and announcing Service IPs to the upstream fabric.

BGPConfiguration allows Services from pre-defined ranges to be used and announced:

› kubectl get bgpconfiguration default -oyaml | yq .spec.serviceLoadBalancerIPs
- cidr: 10.10.10.0/24
- cidr: 192.168.0.0/27

It would be great if Loadbalancer controller would not only tolerate projectcalico.org/loadBalancerIPs for manual assignment but also actual Service.spec.externalIPs and Service.spec.loadBalancerIP.

This would help to gradually migrate existing charts when payload is deployed to clusters where Calico LoadBalancer IP address management is used without having to switch the whole chart fleet to the Calico-specific annotation.

[caseydavenport]

Agree this would be nice to do.

[MichalFupso]

The Service.spec.loadBalancerIP is deprecated in upstream API, that's why we went with the annotation to specify which IPs need to be assigned to the service.

For the Service.spec.externalIPs I think the use case is not for Calico kube-controller to assign those specific IPs to the service, but rather update the service.Status with those IPs that are managed externally. I agree that would be a nice addition

[caseydavenport]

Looks like we've got two PRs for this now! So, calling everyone here to coordinate 😅

• Support spec.externalIPs and spec.loadBalancerIP in LoadBalancer cont… #11961 (@nebojsaj1726)
• LoadBalancer IPAM: support spec.loadBalancerIP and spec.externalIPs as fallback #12447 (@VedantMadane)

The two PRs make slightly different choices in how this is implemented, which raises a few questions.

• Do we want to support spec.LoadBalancerIP at all, when the upstream docs call it deprecated and mention to defer to per-implementation annotations (which we have)? @MichalFupso raised this above. I think I'm OK with implementing it (the field isn't going anywhere, most likely).
• Do we want to reflect ExternalIPs in Calico IPAM? Or just into the Service status? I think these probably don't need to go into Calico IPAM? It provides a way to manage access without needing our IPAM, which is a key difference between the LB implementation.
• Dual-stack support in the spec.LoadBalancerIP field - not specified well upstream, do we handle this? Or defer to our annotation for this?

Thoughts?

[nebojsaj1726]

As I can see, both PRs handle spec.loadBalancerIP, and for the spec.externalIPs - in mine they bypass Calico IPAM and go directly to status. I can add dual-stack support for spec.loadBalancerIP if that's the path forward.