Rename Kind to something that will play better with SEO?

[jroper]

Firstly, I just want to say that I think kind is great, both for working in CI, and for local development, being able to run kubernetes in the host OS has a lot of advantages.

That said, has anyone considered the SEO ramifications of the naming of kind? It makes it really hard to search for answers to questions, due to the following problems:

• Kind is a generic word. Search for "kind" in Google, and nothing related to Kubernetes IN Docker appears on the first page, probably nothing appears in the first 100 results.
• Every single kubernetes descriptor has the word "kind" in it. So, even when searching "Kubernetes kind", you get a lot of false positives, since you'll find the word "kind" in almost every page of the Kubernetes documentation and almost every stack overflow pgae relating to Kubernetes in general.
• Kubernetes IN Docker is no better, since IN is a generic word not included in searches, and Docker and Kubernetes are like two peas in a pod, a significant portion of all the content out there on Kubernetes involves Docker and has nothing to do with Kind.

My team has been finding this, and when one person in the team raised the issue on Slack, there was a loud resounding agreement that it introduced a lot of friction when working with kind.

I do have some ideas for other names, but I think it's best to discuss and agree (or disagree) on whether there's a problem with the name kind before there's any discussion on alternatives.

[wtgtybhertgeghgtwtg]

jroper added the kind/feature label

Kinda Sorta supports the argument for a name change.

[BenTheElder]

The Short Answer:

We definitely didn't have SEO concerns launching the project (though we noted this) because it was originally just scoped to solve the Kubernetes project's internal testing needs. It's certainly not ideal but ...

There are a lot of references we'd have to fix up and this is not something we're planning to do right now. Possibly later.

---

The Long Answer:

Kubernetes IN Docker is certainly not the name now, especially given #1302, we'll likely fix this up in the near future.

KIND / kind however are, and we have a lot of momentum behind this within the Kubernetes project in particular.

Renaming everything and updating all references would be pretty expensive (including homebrew & cholocolately packages, go import paths, all of our CI, docs, slack, and even the Kubernetes project scoping doc ...) and doesn't align terribly well to our own project scope and current priorities (see the rest of the issue tracker and the project roadmap).

We'll certainly re-consider this in the future, but right now I think it's perhaps not the best use of our time and I'm not excited at the prospect of breaking all of our existing users.

We hope that kind.sigs.k8s.io (the first of its kind within the Kubernetes project after jumping through many hoops!) which is linked at the top of our readme at sigs.k8s.io/kind is the best place to find documentation, and we are working with authors of dated external documentation to upstream their work.

We don't monitor stackoverflow, but for help with KIND this issue tracker and #kind in the Kubernetes community slack are well monitored and noted in our README.

For disambiguation issues within your team slack I recommend KIND all caps when referring to this project.

[BenTheElder]

Raising to some other existing stakeholders before definitively saying we should or shouldn't, but the reasons above outline where I'd lean towards at least "not now, but never say never...".

[neolit123]

searching for k8s kind get's you what you want, so i'm giving my -1 vote.

[cblecker]

SEO concerns are valid, but the pain of renaming the project (along with the loss of velocity) are probably not worth it. If there ends up being support for this type of thing, it might be worth asking other projects that have gone through renames (like Heptio Ark -> Velero) and see if they have advice to give.

[absoludity]

* Kubernetes IN Docker is no better, since IN is a generic word not included in searches, and Docker and Kubernetes are like two peas in a pod, a significant portion of all the content out there on Kubernetes involves Docker and has nothing to do with Kind.

This doesn't seem to be true? If I search for "kubernetes in docker" with google in a private tab, kubernetes-sigs/kind is the first result, where as if I search without "in", a docker.com result is first (in ddg, docker.com is first either way). Sure it's not ideal for SEO, but perhaps "kubernetes in docker" should be used over "kind" - it's descriptive and searchable.

[christianh814]

searching for k8s kind get's you what you want, so i'm giving my -1 vote.

Just commenting as a heavy user. I am giving my -1 for this very reason :)

[tao12345666333]

searching for k8s kind get's you what you want, so i'm giving my -1 vote.

Just commenting as a heavy user. I am giving my -1 for this very reason :)

In most cases, the results can be directly searched (especially there are a lot of articles about KIND in China). So I'm giving my -1 vote.

We'll certainly re-consider this in the future, but right now I think it's perhaps not the best use of our time and I'm not excited at the prospect of breaking all of our existing users.

The consequences of renaming are terrible, and I think it is more harmful than the benefits it brings.

[jroper]

Those people who are searching for just "kind kubernetes" or "kubernetes in docker" and seeing kind come up in the search results have missed the point. It's not finding the project that's the problem, it's finding answers to questions.

So, here's an example, let's say I am a kind user, and I've created a LoadBalancer service, and it's not getting an IP address assigned, and I don't know why. So I search Google for "kind kubernetes loadbalancer ip address". None of the results on the top page are specific to kind, in fact none of the first 5 pages are specific to kind. It's not because that content doesn't exist, there's an issue discussing it in this project for example.

Another example, I might be having trouble configuring kind to access Google Container Registry. There is a page in the kind documentation explaining exactly how to do this. Googling "kind access gcr" or "kind kubernetes access gcr" doesn't return this page. For comparison, googling "minikube access gcr" brings up a full page of search results all of which are useful to solve the same problem on minikube.

Anyway, I just wanted to ensure people are aware that there are real users experiencing friction here, I didn't just raise this issue to be pedantic, it's born out of real lived frustration, so please don't treat it like it's a non issue.

[BenTheElder]

Those people who are searching for just "kind kubernetes" or "kubernetes in docker" and seeing kind come up in the search results have missed the point. It's not finding the project that's the problem, it's finding answers to questions.

Once you find the project we hope you check the README, where we have many sources of question answering... the results you find elsewhere are usually pretty dated so we haven't focused on that too much except for a few curated under the resources page. This project is still in alpha and at times moves fast.

https://github.com/kubernetes-sigs/kind#please-see-our-documentation-for-more-in-depth-installation-etc
https://github.com/kubernetes-sigs/kind#community

So, here's an example, let's say I am a kind user, and I've created a LoadBalancer service, and it's not getting an IP address assigned, and I don't know why. So I search Google for "kind kubernetes loadbalancer ip address". None of the results on the top page are specific to kind, in fact none of the first 5 pages are specific to kind. It's not because that content doesn't exist, there's an issue discussing it in this project for example.

Again we hope you'd check our docs and issue tracker (we even point to them from the CLI now!), or ask one of our community channels, where you'll find a result. We're pretty responsive at the listed contact points along with many community members.

Besides the community channels have a new issue template dedicated to questions and another dedicated to requesting more documentation.

In this case you'll find some issue discussion of why this is technically tricky to do with docker sadly :/

Another example, I might be having trouble configuring kind to access Google Container Registry. There is a page in the kind documentation explaining exactly how to do this. Googling "kind access gcr" or "kind kubernetes access gcr" doesn't return this page. For comparison, googling "minikube access gcr" brings up a full page of search results all of which are useful to solve the same problem on minikube.

This is a bit on the nose .. 😬

A bit of background: While other usage has picked up and we're quite happy to do our best to support it actively (and use it this way ourselves!), officially KIND has a position being hosted within the Kubernetes project to test Kubernetes under the "Testing" special interest group. The other project mentioned is hosted under "Cluster Lifecycle" for app developers etc., officially. That may be revisited at some point, but this is where the project comes from.

We are not really expected to be competing with other projects hosted by Kubernetes (ideally not!) and avoid this where possible, even if it seems perhaps inevitable that this might happen anyhow. Especially now that the mentioned project is borrowing some code and ideas to offer similar operation 🤷‍♂️

Our efforts and limited resources have been focused on trying to ship useful tools that solve problems rather than specifically compete for mindshare of our free software. We try to bring on users to contribute to the documentation etc. and helping answering each others' questions as you might expect in open source. We are not a commercial product and nobody works exclusively on this project currently.

As tempting as it would be to rebrand to "tinykube" or something like that .. that's probably likely to cause issues for the project and isn't without cost.

Anyway, I just wanted to ensure people are aware that there are real users experiencing friction here, I didn't just raise this issue to be pedantic, it's born out of real lived frustration, so please don't treat it like it's a non issue.

We're definitely aware, it comes up from time to time in the main community slack channel in particular. We've discussed it a few times with suggestions like you might see above. It is a bit similar to the Go programming language being named "Go", a generic term, and searched typically as "golang" (which... almost all of Kubernetes is written in...), I don't think anyone thinks this is ideal either.

It certainly is a real issue, but it is an issue with trade-offs like any other.

When we started the project it was a non-issue as essentially an internal tool, most of which have terrible names, we just picked something and go to work. As usage shifted and grew it certainly has become one, but renaming wouldn't be without issue either.

The question is what is the right trade off for the project.

I at least am not trying to brush you off, and I don't think anyone else is either. It does cause real problems for users and adoption, particularly for app development etc.

Renaming is something I've seriously considered many times and as I said would be tempted to do but I'm not so sure it's the right call ... and that's why I've reached out to some known stakeholders (contributors, heavy users ...) for their input. So far consensus seems to be against it.

[timothysc]

I'm a -1 on name change b/c of the inertia and impact.

SEO ~ kubernetes kind = 1st hit.

[christianh814]

Those people who are searching for just "kind kubernetes" or "kubernetes in docker" and seeing kind come up in the search results have missed the point. It's not finding the project that's the problem, it's finding answers to questions.

I've never had trouble finding answers to questions. As Ben suggested, I usually hang out in the k8s KIND slack channel and file issues to track.

I find that with smaller communities; one has to actually be actively involved, instead of just consuming answers (which I'm guilty of at times as well)

So, here's an example, let's say I am a kind user, and I've created a LoadBalancer service, and it's not getting an IP address assigned, and I don't know why. So I search Google for "kind kubernetes loadbalancer ip address". None of the results on the top page are specific to kind, in fact none of the first 5 pages are specific to kind. It's not because that content doesn't exist, there's an issue discussing it in this project for example.

Another example, I might be having trouble configuring kind to access Google Container Registry. There is a page in the kind documentation explaining exactly how to do this. Googling "kind access gcr" or "kind kubernetes access gcr" doesn't return this page. For comparison, googling "minikube access gcr" brings up a full page of search results all of which are useful to solve the same problem on minikube.

Most of the answers I find is with search for kubeadm since kind uses it. Second, it's usually a "docker issue".

Anyway, I just wanted to ensure people are aware that there are real users experiencing friction here, I didn't just raise this issue to be pedantic, it's born out of real lived frustration, so please don't treat it like it's a non issue.

Although I'm still -1, I do think people should give it a bit more thought. I've been frustrated before with finding answers.

But in the end, reaching out to the community has always been a positive experience for me.

[cblecker]

Anyway, I just wanted to ensure people are aware that there are real users experiencing friction here, I didn't just raise this issue to be pedantic, it's born out of real lived frustration, so please don't treat it like it's a non issue.

Just to touch on this point directly:
As @BenTheElder said, I think everyone here is weighing the pros and cons of the proposed action (renaming the project). It is a heavy action to take, with both technical and human barriers to consider, and as such, the bar is pretty high. I don't feel like anyone is treating it as a non-issue, but it's more when weighing it against the downsides, it doesn't feel like it's worth it when looking at that overall health of the project.

[BenTheElder]

I think given all the input for now we're going to not go forward with this.
Thank you for the detailed issue.