Associate loadBalancerIP to the network when specified in the Spec

[vishesh92]

Fixes #51

Details

This pull request introduces enhancements to the CloudStack cloud provider for Kubernetes, focusing on better management and tracking of load balancer IP addresses associated by the controller. The main improvements are the addition of a service annotation to track controller-associated IPs, logic to set and use this annotation, and safer handling of public IP allocation and release.

Enhancements to load balancer IP management:

• Added a new service annotation, service.beta.kubernetes.io/cloudstack-load-balancer-ip-associated-by-controller, to mark when the controller has associated a load balancer IP. This annotation is used to determine if the IP should be disassociated when the service is deleted.
• Implemented the setServiceAnnotation method in cloudstack.go, which uses the Kubernetes client to update service annotations, ensuring that the annotation is set when the controller associates an IP.
• Modified the load balancer lifecycle:
  • When the controller associates an IP, the annotation is set on the Service object.
  • On deletion, the controller checks this annotation to decide whether to disassociate the IP, ensuring that only controller-associated IPs are released. Additional checks prevent disassociation if other load balancer rules still use the IP.

Improvements to public IP address handling:

• Updated the logic in getPublicIPAddress to associate an IP if it is found but not yet allocated, and improved error messages for clarity. [1] [2]
• Enhanced associatePublicIPAddress to set the IP address parameter if known and to record when the controller has associated the IP, enabling accurate annotation and cleanup. [1] [2]

Internal API and structure changes:

• Added a clientBuilder field to CSCloud and ensured it is set during initialization, enabling the provider to interact with the Kubernetes API for annotation management. [1] [2] [3]
• Extended the loadBalancer struct to track whether the controller associated the IP (ipAssociatedByController).

These changes improve the reliability and correctness of load balancer IP management, particularly in scenarios where IPs are dynamically allocated and need to be safely cleaned up.

[Copilot]

Pull request overview

This PR enhances the CloudStack Kubernetes provider to support associating user-specified load balancer IP addresses that are unallocated. When a user specifies a LoadBalancerIP in the service spec that exists but is not yet allocated, the controller will now associate it to the appropriate network. The PR also introduces annotation-based tracking to determine whether the controller should disassociate the IP when the service is deleted.

• Adds logic to detect and associate unallocated IPs specified in service specs
• Implements annotation tracking to record controller-associated IPs for proper cleanup
• Enhances deletion logic to check for shared IP usage before disassociation

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
cloudstack_loadbalancer.go	Adds new annotation constant for tracking controller-associated IPs, extends loadBalancer struct with ipAssociatedByController field, implements logic to find and associate unallocated IPs, and enhances deletion logic to safely handle IP disassociation based on annotation and shared usage checks
cloudstack.go	Adds clientBuilder field to CSCloud struct, implements setServiceAnnotation method to update service annotations via Kubernetes API, and stores clientBuilder during initialization

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

[nitpick] The condition lb.ipAddr == service.Spec.LoadBalancerIP is subtle and could benefit from a clarifying comment. This condition is true only when the user specified a LoadBalancerIP that the controller then associated. When the user doesn't specify an IP (empty string), the condition is false, which is correct because the deletion logic at line 372 already handles releasing controller-allocated IPs when they don't match the spec. Consider adding a comment explaining this behavior to make the intent clear.