The ReactiveOps “Bestest Kubernetes Cluster Upgrade”
ReactiveOps
482

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.