Add a finer grained per-node lock about kured

[leth]

A similar use case: it would be nice to be able to pick which node may reboot.

Currently we want to be careful which nodes are rebooted, it'd be nice to be able to use the kured lock to allow a specific node to reboot, but no subsequent nodes.

[leth]

Actually, on reflection, I really want a blacklist so that I can say which nodes should not be rebooted, and let the others update normally.

[tdihp]

Would it be possible to use node labels (or, pod labels) to select nodes before reboot logic? So that if any critical pod / thing is underway on the node we can have some degree of control.

[awh]

ISTM this could be accomplished using a NodeSelector on the kured pod template to stop the DaemonSet scheduling us on nodes that we don't want rebooted; is that sufficient?

[tdihp]

Thanks @awh. Haven't tried NodeSelector/Affinity yet because I was under the impression that after node selection pod won't evict even if the condition changes. I'll try NodeSelector with DaemonSet.

[awh]

Good point @tdihp - I think you're right. Let us know, we'll keep the issue open if that doesn't work.

[elutsky]

@awh slightly different question, maybe I am missing something - we are looking to the ability to run kured on all nodes, but to be able to have some control over the order of reboot, or just to say "reboot this node(s) last".
Use cases are, for example, stateful sets, Prometheus, ... - we can be fine with moving it from node to node, but would like to do this once during the restarts on the cluster.

My understanding is saying, that having restarting their node last, we'll move it to already patched node, so no future updates will be done.

[evrardjp]

This is an Oct 2018 issue, should we close it, and move to new issues for extra questions instead?

[dholbach]

That might make sense, yes. Please reopen if you feel this is still necessary. A clear update would be welcome in this case too.