CCM may not work when Instances or InstancesV2 isn't implemented

[xagent003]

Usecase: We want to use the CCM for LBaaS. We don't have and/or don't want to implement a cloud compute API. The LBaaS functionality just relies on the Service and Node resources.

So kubelet taints the nodes when they come up, until the CCM does it's initialization.

However the CCM expects either Instances or InstancesV2 to be implemented to fetch some metadata. If neither are implemented or the metadata returned is nil, it returns an error here:

cloud-provider/controllers/node/node_controller.go

Line 605 in b60a8ce

return nil, fmt.Errorf("failed to get instances from cloud provider")

syncNode returns prematurely here if metadata is nil or there is an error:

cloud-provider/controllers/node/node_controller.go

Line 434 in b60a8ce

if err != nil {

As a result, it never gets here to remove the taint from the node and update the Node:

cloud-provider/controllers/node/node_controller.go

Line 449 in b60a8ce

n.Spec.Taints = excludeCloudTaint(n.Spec.Taints)

Therefore the node remains tainted and unuseable. But if you look at the code, it seems like the instances metadata can be empty - just not nil. I think syncNode should work if Instances is not implemented - is there any absolute requirement on instances/instance metadata when we want to leverage CCM just for loadbalancers?

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[elmiko]

thank you for reporting this @xagent003 , it is a good question.

this repository is mirrored from the staging location in the kubernetes/kubernetes repository, would you mind opening this issue there? (apologies for the confusion)

https://github.com/kubernetes/kubernetes/issues