Helm chart does not select control-plane nodes on 1.24

[kwohlfahrt]

What happened:

When deploying the cloud provider from the Helm Chart using the configuration below, the daemonset selects no nodes to deploy on.

USER-SUPPLIED VALUES:
args:
- --cloud-provider=aws
- --cluster-cidr=10.0.0.0/12
- --cluster-name=kai-test-cluster
- --configure-cloud-routes=false
image:
  tag: v1.24.1

This additional configuration is required (note that node-role.kubernetes.io/master: null is required to remove this selector):

nodeSelector:
  node-role.kubernetes.io/control-plane: ""
  node-role.kubernetes.io/master: null
tolerations:
- effect: NoSchedule
  key: node-role.kubernetes.io/control-plane
- effect: NoSchedule
  key: node-role.kubernetes.io/master

What you expected to happen:

I expect the helm chart to successfully deploy without having to specify custom labels and taints.

How to reproduce it (as minimally and precisely as possible):

Provision a kubernetes version 1.24 cluster, for example with kubeadm. Add the above configuration snippets to values.yaml, and install the provider with helm install --repo 'https://kubernetes.github.io/cloud-provider-aws' --values aws-values.yaml --version 0.0.6 aws-cloud-controller-manager aws-cloud-controller-manager.

Anything else we need to know?:

The control-plane node labels and taints have been present since v1.20, and the master label and taint will be removed in v1.25 (for reference, see the v1.24 release notes), the next upstream release. It seems like now is a good time to make this transition.

I'm happy to open a PR for this.

Environment:

• Kubernetes version (use kubectl version): 1.24.2
• Cloud provider or hardware configuration: AWS EC2 (not EKS)
• OS (e.g. from /etc/os-release): Ubuntu 20.04.4
• Kernel (e.g. uname -a): 5.13.0-1031-aws
• Install tools: kubeadm
• Others:

/kind bug

[k8s-ci-robot]

@kwohlfahrt: This issue is currently awaiting triage.

If cloud-provider-aws contributors determine this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[k8s-triage-robot]

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

This bot triages issues and PRs 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 or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[kwohlfahrt]

I think this was fixed in #466

[discordianfish]

Not sure if the control-plane tagging done by k3s is wrong or the default nodeSelector here. Either way, it doesn't work out the for me either:

$ kubectl -n kube-system describe ds aws-cloud-controller-manager
Name:           aws-cloud-controller-manager
Selector:       k8s-app=aws-cloud-controller-manager
Node-Selector:  node-role.kubernetes.io/control-plane=

$  kubectl -n kube-system describe node ip-10-10-189-148|grep control-plane
Roles:              control-plane,master
                    node-role.kubernetes.io/control-plane=true

[olemarkus]

Different installers may use different roles/labels/taints for the control plane. Should K3s use different than e.g kOps or kubeadm, I wouldn't say they are doing anything wrong, but that you have to adjust accordingly.

[discordianfish]

That makes sense but I was still confused by the default empty value node-selector that is used here..