Provide cluster name as part of the Configuration and not as flag

[jorgemoralespou]

What would you like to be added:
I would like to have the cluster name being specified in the Config object that is provided to Kind rather than specified as a flag.

You would be able to create a cluster this way:

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
metadata:
  name: my-cluster

Then you can create programatically multiple clusters with any available mechanism, but only changing the definition file, which is stored in VCS:

kind create cluster --config=config.yaml

Why is this needed:
By default, you can only specify the name of the cluster via the --name flag. If you want to programatically create multiple clusters for testing purposes, you need to change the invocation arguments, instead of the configuration file. For automation, we want everything stored in VCS and so the name of the cluster should be part of the configuration.
This would also be consistent with how Kubernetes resources work, and since Kind is a tool for creating a k8s cluster, consistency should be desired for the usage.

There's some other places that consistency should be desirable, but those will go to other issues:

• labels (cluster and node labels)
• CLI arguments alignment to kubectl (so that it can be eventually used as a plugin)
• -o output for certain commands (e.g. kind export kubeconfig)

[BenTheElder]

the downside to this is that you're going to need to specify --name for any other command, how will you delete these clusters?

[BenTheElder]

There's some other places that consistency should be desirable, but those will go to other issues:
labels (cluster and node labels)

hmm? these are internal details and have changed before. please do NOT use these!

CLI arguments alignment to kubectl (so that it can be eventually used as a plugin)

I don't think "be a kubectl plugin" is really a goal for us right now and i'm not really sure how helpful that is, but I admit i'm curious about what this means.

-o output for certain commands (e.g. kind export kubeconfig)

?? we have --kubeconfig and KUBECONFIG to control where the output goes, this is 1:1 with kubectl ...

[jorgemoralespou]

the downside to this is that you're going to need to specify --name for any other command, how will you delete these clusters?

One of the things that I'm finding quite interesting lately in the k8s ecosystem is the lack of consistency when developing a solution. This comment doesn't try to be targeted at kind, but it can be applied to many projects, it just happens to be posted here.

When I look into the "target" users of Kind, I think that it's mostly people that "develop" kubernetes, but more and more I'm also finding that people that "uses" kubernetes as their local platform are moving from minikube to kind for simplicity and speed reasons. What this means is that most of the users are familiar with how kubectl and all the new CLIs kn, tkn, eksctl, clusterctl works. What this means to me, is that there's some expectations on how some things work:

• Most commands follow this pattern: command verb resource-type resource-name parameters (e.g. kind delete cluster my-cluster)
• Create/Apply/Update/Delete can happen providing all the information in a file command verb -f file (e.g. kind create -f my-cluster.yaml)
• but also providing some mandatory information via CLI and flags (e.g. kind create cluster my-cluster --workers=2 --control-plane=1 ...`)

As I would want the learning curve to be minimial, as then I would be able to use the tool without hardly any reading, I would think that Cluster configuration would need to have a name in it so I can just create the cluster easily: kind create -f my-cluster.yaml. I can then use the longer versions of the commands (without requiring --name) to interact with my clusters (e.g. kind delete cluster my-cluster, kind scale cluster my-cluster ..., kind pause cluster my-cluster )

When designing a new CLI that is targeted for users with a known experience, and the experience this tool provides is close, one of the targets should be to mimic the experience and minimise the learning curve (as long as it fits). For kind I think the experience fits perfectly with that of kubectl hence I requested this change.

[BenTheElder]

One of the things that I'm finding quite interesting lately in the k8s ecosystem is the lack of consistency when developing a solution. This comment doesn't try to be targeted at kind, but it can be applied to many projects, it just happens to be posted here.

Perhaps not so surprisingly, when we were building this little tool there was nobody else involved in this. There is not a unified design leadership in OSS, and even if Kubernetes had one I doubt they'd have had the bandwidth for our toy cluster thing.

When I look into the "target" users of Kind, I think that it's mostly people that "develop" kubernetes, but more and more I'm also finding that people that "uses" kubernetes as their local platform are moving from minikube to kind for simplicity and speed reasons.

Yes, The original target was 100% people developing Kubernetes. And they were unlikely to use it directly, we were to have the test suites automated under things like kubetest, and very unlikely to use any cluster naming as they'd have one test cluster. --name was for future feature completeness.

As I would want the learning curve to be minimial, as then I would be able to use the tool without hardly any reading,

This reads like "I don't want to read the docs", which is not a super encouraging attitude.

When designing a new CLI

kind is not a new CLI. It's year(s) old. If we change the CLI to have a new required parameter or parameters we break all of our existing users. We have to look at the tradeoff.

New users shouldn't even be worried about --name. They should start with a single cluster.
Then they should consider reading the docs. or the CLI's --help information!

[BenTheElder]

The current plan is to allow using KIND_CLUSTER_NAME (environment) as an option that will apply to all commands, this will be a non-breaking change, and matches kops. #1094

[BenTheElder]

kn, eksctl, clusterctl, tkn all did not exist when we started, to my knowledge, however minikube did with --profile

[jorgemoralespou]

I understand all the reasons you post here, but I also think that as many other parts of the kubernetes ecosystem as well as the Kubernetes platform itself, there's always ways to evolve apis/usage though versioning/depreciation,etc...
I filled this issue mostly because initially I was no target of this tool, but now I have found myself that I am, because my company has decided to adopt it (against my advice) for LOB developer usage as their "local clusters" for developing apps.
In any case, I understand the initial goals and design, so feel free to close this issue if it's not something that can be considered.

[BenTheElder]

Now that more things are solved I have had some time to think more about the UX we have here and how we could bring more of it in line.

#1519 will enable a migration path off of the one argument we have so we can start supporting name as an argument.

in that light, we're also supporting KIND_CLUSTER_NAME, I don't see any reason not to support this as well except a slight concern that users will not supply the name to delete etc... but we could allow --config for those commands too.

The proposed value override would be (most over-ridding to least)

• cli argument for name EDIT: forgot about kind export ... last night :/ .. looking at other tools again
• --name
• KIND_CLUSTER_NAME env
• --config file value

/assign

[BenTheElder]

actually CLI arg will need more thought (see edit) but config file based name for create / delete should be fine.

eksctl has a slightly awkward --name on some commands for the cluster and --cluster on some others.
I don't think any tool has totally nailed this UX yet.

[BenTheElder]

/lifecycle active

[BenTheElder]

the name is in config