Supporting taints via NFD operator

[yevgeny-shnaidman]

Taints are specified in the NodeRules objects, and are applied by master pod. This may cause the NFD worker pods on the tainted nodes to become unscheduled, since NFD operator is not aware of the NodeRules and is not updating the worker daemonsets with appropriate tolerations.
The possible solution is to create additional controller in the operator, that will watch for NodeRules creation. In case NodeRule contains taint definition, the controller will kick off reconcilation of the nodefeaturediscovery controller, which will check the presence of the taints in any existing NodeRule and will update the worker daemonset accordingly.
The new controller will have to watch for Create and Update events, but not for Delete events, since there is no problem for worker to be running with additional tolerations
Reconciliation kick-off can be achieved by applying an annotation to the NFD CR. We can agree on a specific naming , and the value of the annotation will be increased subsequently with each time the reconciliation loop needs to be restarted

[marquiz]

This would be very nice feature, making tainting a lot more user-friendly.

[yevgeny-shnaidman]

We will start working on it once we finish with the refactoring

[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

[k8s-triage-robot]

The Kubernetes project currently lacks enough active 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 rotten
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle rotten