cloud provider doesn't honor the "exclude-from-external-load-balancers" label value

[kayrus]

Issue Description

Setting the node.kubernetes.io/exclude-from-external-load-balancers label to "false" does not behave as expected. Instead of honoring the boolean value, the controller always excludes the node from the load balancer, regardless of the label’s value.

Impact

In OpenStack’s cloud provider integration, the node-selector annotation functions as a standard node selector. However, when a node’s labels are updated, the LBaaS service is not automatically reconciled. The only current workaround is to modify the exclude-from-external-load-balancers label (e.g., adding it with the "false" value) to trigger reconciliation. This should not impact the node’s inclusion in LBaaS, but instead, it incorrectly excludes the node from the load balancer.

Expected Behavior

The controller should respect the explicit "false" value and not exclude the node from the load balancer.

Reference

According to the official Kubernetes documentation, only the "true" value should trigger exclusion. Therefore, the logic should be updated to properly handle the label’s value.

Suggested Fix

Modify the controller logic to explicitly check for "true" or invalid boolean value rather than treating any presence of the label as exclusionary, e.g.

"" -> exclude (to keep the backwards compatibility)
"true" -> exclude
"foo" -> exclude (to keep the backwards compatibility)
"false" -> include

cloud-provider/controllers/service/controller.go

Lines 1012 to 1016 in 2773935

	// We consider the node for load balancing only when the node is not labelled for exclusion.
	func nodeIncludedPredicate(node *v1.Node) bool {
	_, hasExcludeBalancerLabel := node.Labels[v1.LabelNodeExcludeBalancers]
	return !hasExcludeBalancerLabel
	}

see also kubernetes/cloud-provider-openstack#2869

[elmiko]

thanks for bringing this up. given that this has been broken for some time and people might have inadvertently been using it "as is", should we take this through the normal deprecation process to ensure that we don't disrupt any users?

[kayrus]

normal deprecation process

it would be nice if you can share more details about this process and how do you think to proceed

[elmiko]

let me do a little research and i'll post the results here. it might take me a day or two.

[elmiko]

i've reviewed the Kubernetes Deprecation Policy but i don't think anything you are proposing would necessarily dictate that we need any additional warning.

i think the main thing we need to make clear when this change gets released is that user might need to adjust their labels if they had been expectating the previous behavior.