Interesting post, thanks for making me rethink the update process ;)
Question: Could this be more easily achieved by adding a
PreferNoSchedule taint to all the “old” nodes before starting the update?
I think that will achieve the goal of avoiding extra pod reschedules while continuing to allow updates of any batch size (including N=1). In particular,
PreferNoSchedule will also work on baremetal-type scenarios, where we don’t have the luxury of bursting to double our regular cluster size.