CONVENTIONS: Daemonsets should use maxAvailability 10%
statement in
is important
enough to be documented as a convention in this document.
@@ -199,6 +199,17 @@ To avoid disruption and mass pod-death, it is important to
* Components that support workloads directly must not disrupt end-user workloads during upgrade or reconfiguration
* E.g. the upgrade of a network plugin must serve pod traffic without disruption (although tiny increases in latency are allowed)
* All components that currently disrupt end-user workloads must prioritize addressing those issues, and new components may not be introduced that add disruption
+* All dameonsets of OpenShift components should use the maxUnavailable rollout strategy, allowing up to 10% of instances to be taken down at once.
+Any bugs that block that should be fixed.
+`10%` is an arbitrary ratio that ensures that most of the cluster is up and
+serving clients, while a big-enough chunk of the cluster is upgradable.
+There wasn't a huge amount of analysis beyond the fact that it significantly
+improved upgrade times and hit our targets. Additionally, 10% is roughly in
+line with the minimum disruption experienced by the default sized cluster
+whenever we reboot nodes and that's mandatory in order to complete an upgrade.
+Keeping the default of `1` makes an operator upgrade unacceptably slowly on
+big clusters because only one host running the daemonset can be drained (and upgraded) at a time.
+
#### Priority Classes
