Unclear wording in “Disruptions” concept page

[mltsy]

This is a Bug Report

Problem:
Under the "Dealing with Disruptions" heading, it says "The frequency of voluntary disruptions varies. On a basic Kubernetes cluster, there are no voluntary disruptions at all." This is just not true... unless I'm missing some very limited definition of "Basic Kubernetes Cluster".

Essentially every possible "voluntary disruption" mentioned earlier on the page does happen on a basic Kubernetes cluster (deploying a new revision, deleting a pod accidentally, upgrading the cluster, etc.). I assume what is meant here is that no voluntary disruptions are automated on a basic K8s cluster? But I'm not sure...

Proposed Solution:
Possibly change the wording to "On a basic Kubernetes cluster, there is no automated process that causes voluntary disruptions (all processes involving voluntary disruption are initiated manually, by default)."

Page to Update:
https://kubernetes.io/docs/concepts/workloads/pods/disruptions/

[sftim]

On a basic Kubernetes cluster, there are no voluntary disruptions at all.

This seems valid to me, although the text doesn't back this up with an explanation. The blue-green deployment pattern is simpler to implement than, say, a canary release

If you use blue-green deployments then you have two Deployments (blue and green) and neither of these has any voluntary disruptions whilst in service.

If rewording this page to make things clearer, bear in mind that coarse-grained deployments are easier to implement than the fine-grained kind that need to heed PodDisruptionBudget etc.

@mltsy the text you suggested:

On a basic Kubernetes cluster, there is no automated process that causes voluntary disruptions (all processes involving voluntary disruption are initiated manually, by default).

also doesn't feel quite right, because you can have a very basic-looking cluster where deployments (ie, updates to Deployments) are triggered automatically. I think that might even be on the CKAD syllabus, it's that fundamental.

(Aside, but relevant: PodDisruptionBudget and EvenPodsSpread are both beta features).

[mltsy]

Interesting... though I'm not sure I understand what your opinion is. First you say that the phrase "there are no voluntary disruptions at all" seems valid to you, but then you are also saying it's incorrect to claim there are no automated voluntary disruptions because "you can have a very basic-looking cluster where deployments are triggered automatically" ... so does a basic cluster have or not have voluntary disruptions? If it has "no voluntary disruptions at all" then it certainly doesn't have any automated voluntary disruptions, right?

Even if we ignore the case of deployments for the time being, and expect that on a "basic cluster" you should be using blue-green deployments, surely someone who launches a basic cluster will update the cluster with a new K8s version at some point, right? That's a voluntary disruption. It just seemed confusing to me, after I just got done reading all the things that might cause a "voluntary disruption" to say that they never happen on a "basic Kubernetes cluster".

I guess I'm just not sure what the point of that sentence is in the first place. I think it's meant to illustrate the difference between something like a hosted cluster (like GKE), and the most basic kind you might setup on your own... where in the case of a hosted cluster, there are automations, by default, that will cause voluntary disruptions, whereas in the case of a default cluster setup on your own, there would not be, unless you set them up. (But that doesn't mean there will be no voluntary disruptions ever on that cluster - it just means they aren't going to happen unless you make them happen)

[sftim]

We'd have to ask the original author to uncover their intent.

I suspect they were trying to distinguish between cases where people aren't worried about voluntary disruptions and comparing that to the cases where someone is actively keen to manage the impact of voluntary disruptions, whether those are from application rollouts or from cluster upgrades.

[mltsy]

Sure - that makes sense. Maybe better wording, then, would be:

"On a basic Kubernetes cluster, there are no hidden/default automated voluntary disruptions to worry about."

That seems more to the point and a bit less confusing to me. Does it seem at least as accurate as the current wording?

[sftim]

/kind cleanup
/language en
/priority backlog
/retitle Unclear wording in “Disruptions” concept page

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[mltsy]

/remove-lifecycle stale

The confusing documentation still exists.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[mltsy]

/remove-lifecycle stale

I think this could be resolved by replacing:
"On a basic Kubernetes cluster, there are no voluntary disruptions at all."
with:
"On a basic Kubernetes cluster, there are no automated voluntary disruptions."

Although is this actually true? The text mentions "Removing a pod from a node to permit something else to fit on that node." which I believe is something a basic Kubernetes cluster will do if you try to deploy something that doesn't fit on a node currently, but could by shifting other pods around... isn't it? That strikes me as an automated process (although it has a manual catalyst) that causes a voluntary disruption.

If that's the case, it might be better to say: "Rescheduling (moving) other pods during a deployment is the only voluntary disruption that may be considered automated (or indirectly triggered at least) on a basic Kubernetes cluster." Or maybe more succinctly and more to the point... "Every multi-node cluster is, by default, subject to some voluntary disruption"

[sftim]

Removing a pod from a node to permit something else to fit on that node.

AIUI Kubernetes does not come with a descheduler but you can add one in, such as: https://github.com/kubernetes-sigs/descheduler

/sig scheduling

[mltsy]

Ah! Okay, well that simplifies it then. (I'm using GKE, so it must have use a custom de/scheduler if Kubernetes doesn't come with a standard one that has this behavior) Yeah, it looks like the default plugin that determines this behavior is the DefaultPreemption plugin, which only evicts pods if a priority are set, which is not a default, so I think it's safe to say that's not a "default" behavior (since you have to enable it by creating and using PriorityClasses).

So, how about: "On a basic Kubernetes cluster, there are no automated voluntary disruptions (only user-triggered ones)."

[sftim]

So, how about: "On a basic Kubernetes cluster, there are no automated voluntary disruptions (only user-triggered ones)."

(Sounds good to me)

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[mltsy]

This is resolved :)