feat(loadbalancers): new selector style annotation to assoc LB with VPC/PN

[andreaswachs]

Changes

• Adds support for a new annotation on Kubernetes services of type LoadBalancer named service.beta.kubernetes.io/scw-loadbalancer-pn-names in order to make GitOps easier by using pairs of <VPC-name>/<PN-name>[,<...>/<...>] as opposed to using service.beta.kubernetes.io/scw-loadbalancer-pn-ids that might change over time or adds a second step of configuration when deploying clusters

Backwards compatiblity

Since there are already settings for getting the LB associated with a specific PN, we put the priority as such for acting on specific configuration if multiple are present:
pn-ids (annotation) > pn-names (annotation) > PN_ID env var.

Key details

• Name format: vpc-name/pn-name required to avoid ambiguity across VPCs. Comma-separated for multiple networks.
• Project scoping: VPC/PN lookups scoped to the project where cluster nodes run (derived via Instance API), preventing cross-project name collisions.
• Backend IP resolution: Uses precise IPAM-based lookup via getNodeIPsForPrivateNetworks — queries each node's private NICs and resolves IPs through IPAM rather than relying on extractNodesInternalIps which may return IPs from unrelated private networks.
• Private LB guard: Updated to accept pn-names (and pn-ids) so private LBs no longer require the PN_ID env var when annotations are set.
• Error handling: Clear errors for missing/duplicate VPCs and private networks.

This has been tested to work in a self-managed Kubernetes cluster running on Scaleway VMs.

[jtherin]

I don't think we will accept this pr, vpc and pn names are not unique, duplicate names are allowed. this pr is too error prone

[nfm-corti]

There is a problem though @jtherin. When provisioning a cluster using cluster API, we can't predict the UUID, which means that we would need to manually look up the ID and add it to GitOps. Currently, there is no way to get a deterministic identifier / selector for a VPC. Do you have any alternative suggestion?

As far as I know the VPC / PN name combination is unique within a project and the CCM is always linked to a single project AFAIK. Are we missing something?

[jtherin]

There is a problem though @jtherin. When provisioning a cluster using cluster API, we can't predict the UUID, which means that we would need to manually look up the ID and add it to GitOps.

Kapsule does not create any PN, you provide a PN to kapsule api, so the issue is more likely on cluster api side

As far as I know the VPC / PN name combination is unique within a project

No, you can have many pns with the same name inside the same vpc inside the same project

[nfm-corti]

But this means that we need to pre-create the network with an external orchestration layer, which makes the process rather involved. Would it be an option to hide this behind a feature flag?

[nfm-corti]

Other CCMs, such as Azure allow you to do a similar thing. I feel like having multiple non-unique VPC name / PN names should be a bug not a feature.

While not the same, Azure does allow you to associate a pre-created public IP by name using service.beta.kubernetes.io/azure-pip-name.

If you can't create a deterministic unique identifier, infrastructure is really hard to manage.

[andreaswachs]

Hey @jtherin.

I hope that Nicklas comments could be taken up for debate in the team. Especially the comment on perhaps pairs of PVC name and PN names should perhaps be unique.

IF that discussion is not able to materialize or you/the team are in disagreement with us on this, can I propose that we spin this feature into selecting VPC/PN's based on tags on the PNs instead? I see that tags on Scaleway resources are supported and we could add the ability to configure this on ScalewayCluster resources.

Our goal is to simplify our cluster operations and make cluster provisioning with Cluster API more automated and I see this as another solution to the same problem.