A few other options:

• A "Stevedore" is a man who loads ships (http://en.wikipedia.org/wiki/Stevedore)
• Hyperetes is greek for "under-rower" and refers to the deck and command crew headed by the helmsman (kubernetes)

I don't want to change, but if we do I would vote for something bland like "node".

The name we use in code is kubelet. Any reason why we shouldn't consider that one? (idk if it falls under the "slave" umbrella)

Kubelet is the name of the agent. "Minion" is what we call the machine the agent runs on.

I kind of like stevedore but it is long. Hyperetes apparently has some connotations around 'slave' according to wikipedia. I also worry that it is hard to pronounce. We already get enough crap around the name "kubernetes".

What do you think about KNode? It is generic (as @lavalamp) wants but also kubernetes specific.

I vote for a change. Minion did cause confusion to me initially when I first worked on this project. But I don't have a better naming suggestion here, and ok with KNode for sure.

"(k)node" or "machine" sounds good.

We often shorten Kubernetes Master to KMaster, so I can see the argument for shortening Kubernetes Node to KNode. Personally I'd prefer to just spell it out and say Kubernetes Node since just "None" seems a bit too generic.

Knode - pronounced "node". The K is silent. :P

On Fri, Aug 29, 2014 at 1:41 PM, roberthbailey notifications@github.com
wrote:

We often shorten Kubernetes Master to KMaster, so I can see the argument
for shortening Kubernetes Node to KNode. Personally I'd prefer to just
spell it out and say Kubernetes Node since just "None" seems a bit too
generic.

Reply to this email directly or view it on GitHub
#1111 (comment)
.

I actually don't see a need, long-term, for distinguishing master vs. minion, since master components will be replicated & distributed across whatever minions are in the correct security zone to run them.

I still like short generic terms. "kbox" is better than knode, but I like "box" better. :) Or "unit", which takes a k in front even easier: kunit.

Please no box or unit. box has pohysical implications, and unit is a
horrible name. Also systemd uses "unit".

On Fri, Aug 29, 2014 at 1:50 PM, Daniel Smith notifications@github.com
wrote:

I actually don't see a need, long-term, for distinguishing master vs.
minion, since master components will be replicated & distributed across
whatever minions are in the correct security zone to run them.

I still like short generic terms. "kbox" is better than knode, but I like
"box" better. :) Or "unit", which takes a k in front even easier: kunit.

Reply to this email directly or view it on GitHub
#1111 (comment)
.

Having to make up a new word to describe a fairly standard concept (a slave, minion, node, host, box) seems risky. I'd prefer not to make up new terminology for people to learn when they administer new systems. Master is pretty unambiguous, let's pick a word that matches the common use for the things masters control.

I really think knode is self-explanatory

On Fri, Aug 29, 2014 at 2:26 PM, Clayton Coleman notifications@github.com
wrote:

Having to make up a new word to describe a fairly standard concept (a
slave, minion, node, host, box) seems risky. I'd prefer not to make up new
terminology for people to learn when they administer new systems. Master is
pretty unambiguous, let's pick a word that matches the common use for the
things masters control.

Reply to this email directly or view it on GitHub
#1111 (comment)
.

I'm a fan of node / knode / Kubernetes node.

I'm fine with node, but it's not very consistent with "master", which is also a node/host rather than a component in k8s. How about worker?

Personally, worker sounds like a process running on one of the pool nodes.

If we use KNode, I think it is reasonable that users will figure out that the master host isn't necessarily running on one of the KNodes. A KNode is a node that is part of a k8s cluster.

+1 for kNode: it's mercifully short, and not confusing. kMachine would also be fine.

(Although I like "minion" for being nicely tongue-in-cheek, it's a bit too easily confused with the functionality of a kubelet. But if you want to go down that path, then "vassal" would be nice - historically, some were immensely powerful. I agree that "worker" is confusing.)

A "master" is a software function, like a kubelet, not a (k)node, so I'm not sure it matters where it runs.

I'm not sure why we need a distinctive/cute name for the machines that run kubelets.

In all of the documentation and code that K8s devs write, we will almost always be talking about machines that are part of a k8s cluster, and rarely about ones that are not. So "machine" will be clear enough.

For the ops folks who run k8s clusters alongside a range of other services, they will already have terms to distinguish machines with different roles, and don't need us to make one up.

I vote for "machine".

"machine" is generic enough for me. I feel like we completely used up our cuteness quota with "Kubernetes".

Summarizing:

The thing that tells other things what to do:

• master
  • You can run the Kubernetes master inside a container on a host, or as a standalone service on a regular system.
• ???

The thing that hosts pods

• machine (a Kubernetes machine)
  • Pods are scheduled onto machines. Each machine runs an agent called the Kubelet that watches for changes in the list of pods.
• node (a Kubernetes node)
  • Pods are scheduled onto nodes. Each node runs an agent called the Kubelet that watches for changes in the list of pods.

+1 for node over machine.

Here is what I'd say we go with:

• Master: a set of services that need to run to control a cluster. Often this will run on a dedicated machine but it isn't required. Over time we'll look to have master components run across a cluster.
• Kubernetes Node or KNode: a worker node that participates in a Kubernetes cluster. Replaces the use of minion now.
• Kubelet The agent that communicates with master components to run and manage containers (in concert with Docker). Running a Kubelet is one of the primary things that defines a KNode.

I'm not a huge fan of plain "node" as it is pretty generic. KNode is short and kubernetes specific.

So here's my counter to "K*" anything (I'm fine with Kubernetes *) - why not "KPods" or "KServices" or "KReplicationControllers"? Mesos doesn't call its slaves "MSlaves" (it's just a Mesos slave), and the same argument probably applies to most systems. It also avoids us having to do terrible things with casing in function definitions (or at least I think they're terrible):

func AddKNode(kNodeName string) {
}

I think the K* / Kubernetes is either implied by context and thus unnecessary, or K by itself isn't sufficient to know what it is (if I told a random admin "check out this KNode" he'd look at me like I was crazy).

Okay -- how about we say the official name is "Kubernetes Node" but that can be abbreviated KNode or Node as necessary. In code and such, plain old Node is perfectly okay if Kubernetes is implied.

As for K* -- Pods and ReplicationControllers are unique enough they don't need a K. Services is way too generic already and I'm sure we'll bikeshed on that soon :)

Someone want to sign up on doing this? Or did I sign myself up?

(I was just reading this article on zookeeper where they talk about zNodes. Heh. https://www.found.no/foundation/ZooKeeper-King-of-Coordination/)

Suggestion:

Rather than bikeshedding on each new naming decision, we should bikeshed once on picking a benevolent Name Czar, and then defer to the Czar, after a short discussion period, to make a decision on all Naming issues. That will result in faster progress and more thoughtful, consistent naming throughout the project.

Why don't we hoist the bikesheding on bikesheding discussion to kubernetes-dev@googlegroups.com?

I'm going to call this one -- we'll rename minion to node. If the Kubernetes context is confusing, refer to them as Kubernetes Nodes or KNodes.

Minion is still present in scripts in /cluster, such as:

We should at least be able to eradicate it when we fully remove provider-specific code from this repo.

Not sure if this is the right place and time, but how about having the master and a worker types of the node? (where node is a single system in a cluster of many systems)

I think that would remove one level of ambiguity.

Sad! I love minions.

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.

Prevent issues from auto-closing with an /lifecycle frozen comment.

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

https://github.com/kubernetes/kubernetes/search?utf8=%E2%9C%93&q=minion&type=

This only exists in a few places in the cluster directory, which we're going to eliminate at some point, so this done enough