Update k8s-best-practices-platform-upgrade.adoc

Author: mwlinca

modules/k8s-best-practices-platform-upgrade.adoc

@@ -37,6 +37,19 @@ For an application to stay healthy during this process, if they are stateful at
 Applications may not set the pod disruption budget to minUnavailable equal to the number of pods in the deployment/replicaset or maxUnavailable pods to zero, operations will change your pod disruption budget to proceed with an upgrade at the risk of your application.  
 ====
 
+Additionally pod disruption budgets must not be set to very low numbers of unavailable; doing so prevents system patching from completing in a timely manner. Statefulsets/Replicasets/Deployments that have a requirement for pod antiaffinity spread to greater than 20% of the nodes in a given cluster must set the pod disruption budget to 20% for the set of pods.
+
+.Example
+[source,terminal]
+----
+100 node cluster
+20% of nodes would be 20 nodes
+Any D/S 20 nodes or more would require 20% PDB
+
+20 node deployment would have 4 pod PDB
+40 node deployment would have 8 pod PDB
+----
+
 A corollary to the pod disruption budget is a strong readiness and health check. A well implemented readiness check is key for surviving these upgrades in that a pod should not report itself ready to kubernetes until it is actually ready to take over the load from another pod of the example set. An example of this being implemented poorly would be for a pod to report itself ready but it is not in sync with the other DB pods in the example above. Kubernetes could see that three of the pods are "ready" and destroy a second pod and cause disruption to the DB leading to failure of the application served by said DB.
 
 See link:https://kubernetes.io/docs/tasks/run-application/configure-pdb/[pod disruption budget reference], link:https://docs.openshift.com/container-platform/latest/rest_api/policy_apis/poddisruptionbudget-policy-v1.html[pod disruption budget policy & API].