Umbrella issue for Label Sync Between Machines and underlying Kubernetes Nodes proposal implementation

[ykakarap]

This is an umbrella issue for the implementation of the Label Sync Between Machines and underlying Kubernetes Nodes proposal. As the proposal is merged the implementation can now be done.

The work is broken down into:

• Synchronization of CAPI Labels ✨ Add Node managed labels support #7173
  • Notes:
    • A subset of labels as defined in Label domains & prefixes should be synced between the machine and the nodes.
    • SSA should be used to apply the labels the labels. Take special look at the labels that could be applied by kubeadm and could also be applied by the Machine Controller. This might lead to co-ownership. Making deletion harder.
• Migrate machine controller tests to envtest and drop disableNodeLabelSync.
  • Issue: switch machine controller tests that use SSA to envtest and drop disableNodeLabelSync #7964
• Apply node.cluster.x-k8s.io=uninitialized:NoSchedule taint on newly created nodes which did have the labels synced. The taint should be removed after the labels are synced for the first time.
  • PR: ⚠️ apply node.cluster.x-k8s.io/uninitialized during machine creation #7993
• Document optional Bootstrap provider contract to support node.cluster.x-k8s.io=uninitialized:NoSchedule at creation.

---

Issues/PRs that could be affected by this work:

• ✨ Taint nodes with PreferNoSchedule during rollouts #7631

[ykakarap]

/assign

[fabriziopandini]

/triage accepted

[sbueringer]

cc @srm09 (IIRC once this issue is completed there might be some work to do in CAPV)

[ykakarap]

/milestone v1.4

[k8s-ci-robot]

@ykakarap: You must be a member of the kubernetes-sigs/cluster-api-maintainers GitHub team to set the milestone. If you believe you should be able to issue the /milestone command, please contact your Cluster API Maintainers and have them propose you as an additional delegate for this responsibility.

In response to this:

/milestone v1.4

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.

[sbueringer]

@ykakarap is this issue done?

[ykakarap]

Yes. All the items are done. This issue can be closed.

/close

[k8s-ci-robot]

@ykakarap: Closing this issue.

In response to this:

Yes. All the items are done. This issue can be closed.

/close

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.

[lubronzhan]

Hi @ykakarap this new label will breaks existing cloud-providers for example cloud-provider-vsphere. Since it only tolerates existing k8s tolerations, https://github.com/kubernetes/cloud-provider-vsphere/blob/master/releases/v1.26/vsphere-cloud-controller-manager.yaml#L218-L230

CPI is crucial to initialize the node, setting provideID and externalIP on the node. Now node will stuck in uninitialized state, because CPI can't be deployed. And CAPI can't find the providerID of the node since CPI is not deployed. While CAPI won't remove the tolerations node.cluster.x-k8s.io=uninitialized:NoSchedule since it can't find the providerID.

This is a breaking change that either requires all cloud-providers to adopt this tolerations.

[fabriziopandini]

this is being discussed in #8357, fix in flight