Several glossary entries about cluster architecture may lead to confusion #48556
Comments
k8s-ci-robot
added
the
needs-triage
|
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the The Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
No; that wouldn't be correct. The control plane is always part of the cluster, but doesn't have to run as containers. |
The control plane is always part of the cluster, but you don't have to use Kubernetes technology to supervise and deploy it. |
You are welcome to send in a pull request.
Yes, lots of documentation and code in the wider ecosystem still uses the term master. Some very old docs talk about minions. We could move the minion explanation to its own glossary entry; contributions are, again, very welcome. /language en |
A worker node is a node that isn't used to host any part of the control plane. If this isn't clear, let's try to improve the docs we have. |
|
@sftim : can i take it up? |
|
Hi,
Firstly thanks for responding.
Secondly is this the best place for discussion? Please feel free to redirect me if not.
Finally - I guess my question about the distinction is less about the definition itself, but more about:
- Whether a node without any part of the control plane is treated fundamentally differently from other nodes in any way? Does it get preferential treatment or otherwise?
- Whether you can have a cluster with no worker nodes, i.e. that each node hosts some aspect of the control plane? For example a basic 2 node cluster with that has control plane elements on both nodes?
Again thanks for engaging, and helping me contribute as best I can.
Cheers
Paul
… On Oct 27, 2024, at 08:39, Tim Bannister ***@***.***> wrote:
Is the distinction between a worker node and a non-worker node meaningful?
A worker node is a node that isn't used to host any part of the control plane. If this isn't clear, let's try to improve the docs we have.
—
Reply to this email directly, view it on GitHub <#48556 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BMOPC6CCMZXIWP7K5XJ4WB3Z5T3KFAVCNFSM6AAAAABQVP2NVOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINBQGA3TAOBRHE>.
You are receiving this because you authored the thread.
|
|
Best place for discussion? Likely https://discuss.kubernetes.io/
I'd take that question to the forums. This repo is for improving the docs.
You can have no nodes at all, but it's rarely done. The jargon term is scaling to zero. You also get clusters with only control plane nodes, and workloads scheduled onto the nodes that run the control plane. This is more common but still not the typical way to operate Kubernetes. |
|
@TransitivityPaul if your main aim was to learn Kubernetes, please consider closing this issue. |
|
Hi Tim,
Not my aim. But a fair question to ask.
My aim is to improve the docs, and in so doing ensure that I have the right definitions for my needs. I’d rather align with the place where everyone goes, rather than use terminology that is divergent and then have to say why my definition is slightly different.
For the work I do I need simplicity and precision. And glossaries are where I look for the simple and precise canonical definitions, as it should be easier than looking through the code. My point with worker node/machine, is that sometimes there is a difference without distinction. Yes, descriptively there is a difference between a node that doesn’t host control plane components, or that doesn’t host non-control plane workloads. But are they managed differently in any way by the control plane, operators or users? If the answer to such questions as the latter is no, then my tendency is to deprecate the use of a term so that all future docs are simpler and easier to understand, and reference that deprecation to cover for where it hasn’t been removed from the broader corpus of docs. Otherwise you’re left with lots of clutter - nomenclature debt if you will ;) - that can be confusing, and have interesting consequences...
...in my prior roles I have seen disastrous outcomes, in one case costing many, many millions of dollars, that resulted from the slightest of misunderstandings about the definition of a term describing a thing. In this case the same, very common, term was used by two different teams to describe two things that were almost completely, but not quite, identical. But when a reader assumed that the behavior of both was the same in a particular circumstance, it resulted in an extraordinarily expensive problem that impacted many millions of users. These kinds of experiences have rather conditioned me to be perhaps a little obsessive when it comes to clarity, and precision wrt definitions ;)
Anyway, a non goal of mine is to needlessly distract others. Suffice to say I think what you do is important. I’ll close the issue, and submit changes for those things that you’ve suggested. And then I’ll look at the code, consult the community or whatever to see if the proletariat nodes are distinct.
Anon
Paul
… On Oct 31, 2024, at 11:49, Tim Bannister ***@***.***> wrote:
@TransitivityPaul <https://github.com/TransitivityPaul> if your main aim was to learn Kubernetes, please consider closing this issue.
—
Reply to this email directly, view it on GitHub <#48556 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BMOPC6GKVD6YTSHFGO2UFMLZ6J3VHAVCNFSM6AAAAABQVP2NVOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJQGU4TSNJVGM>.
You are receiving this because you were mentioned.
|
|
/retitle Several glossary entries about cluster architecture may lead to confusion It's more that the glossary entries fail to head off (avoid) the confusion, but we like terse issue titles. We don't set out for the glossary to supersede or substitute for reading the actual concept guide, but it's plausible that a minority of readers will do the same thing. |
k8s-ci-robot
changed the title
|
See #48686 |
I'm not sure if this is the right channel, but..
For various reasons I'm modeling Kubernetes and am trying to land on definitions that are a little more precise so that I can reason about the structure. Any thoughts below are as much to get a response around their correctness (so that I get my model right) as they are about suggested updates to the glossary itself.
Regarding the definition of Cluster - The terms "worker machine" and "worker node" seem perhaps unnecessary and potentially confusing. Especially as worker * may also (optionally) host elements of the control plane. Is the distinction between a worker node and a non-worker node meaningful? Is it possible to simplify the definition by saying that:
As it stands, the definition also doesn't preclude the control plane being hosted outside of the cluster, even though the architecture diagram shows it being within the cluster. I know of some cluster frameworks that do support "externalized" control planes or control plane components.
Control Plane - It might make sense to reorder the words or to add a comma to make it clear that..
Node could perhaps likewise be simplified...
Is there a reason to continue to refer to Masters and Minions at all? If they still occur in documents that are not yet deprecated, then it might make sense to call this out specifically as glossary items.
Otherwise it may make sense to drop the terms completely. The term Master is somewhat pejorative, especially considering cluster role definitions of the past.
Anyway, I hope you can help me me land on the accurate definitions for myself, and perhaps these may also help evolve the glossary.
Best regards
Paul
The text was updated successfully, but these errors were encountered: