From fc8797f9020029d534871a1647d0bf6a5e931d62 Mon Sep 17 00:00:00 2001 From: Joe Marty Date: Thu, 4 Mar 2021 09:32:32 -0600 Subject: [PATCH] Clarify sources of voluntary disruptions --- 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 d0a8bbf5a9976..04c35e0322355 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