From 21b1e83147332372935e606adba9c6bc5bec5cdd Mon Sep 17 00:00:00 2001 From: Joe Marty Date: Thu, 4 Mar 2021 09:54:52 -0600 Subject: [PATCH] Clarify sources of voluntary disruptions See issue #22391 --- content/en/docs/concepts/workloads/pods/disruptions.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/content/en/docs/concepts/workloads/pods/disruptions.md b/content/en/docs/concepts/workloads/pods/disruptions.md index d0a8bbf5a9..04c35e0322 100644 --- a/content/en/docs/concepts/workloads/pods/disruptions.md +++ b/content/en/docs/concepts/workloads/pods/disruptions.md @@ -80,12 +80,14 @@ Here are some ways to mitigate involuntary disruptions: [multi-zone cluster](/docs/setup/multiple-zones).) The frequency of voluntary disruptions varies. On a basic Kubernetes cluster, there are -no voluntary disruptions at all. However, your cluster administrator or hosting provider +no automated voluntary disruptions (only user-triggered ones). However, your cluster administrator or hosting provider may run some additional services which cause voluntary disruptions. For example, rolling out node software updates can cause voluntary disruptions. Also, some implementations of cluster (node) autoscaling may cause voluntary disruptions to defragment and compact nodes. Your cluster administrator or hosting provider should have documented what level of voluntary -disruptions, if any, to expect. +disruptions, if any, to expect. Certain configuration options, such as +[using PriorityClasses](https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/) +in your pod spec can also cause voluntary (and involuntary) disruptions. ## Pod disruption budgets