Add the ablity to specify extra labels in the config file

[christianh814]

What would you like to be added:

It would be nice to be able to add labels to running KIND instances. To do this, the config can be updated to include something like this...

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
containerRuntime:
  extraLabels:
    - name: myspecialkey
      value: myspecialvalue
    - name: foo
      value: bar

I know currently the labels io.x-k8s.kind.cluster and io.x-k8s.kind.role are automatically added, but it would be nice to be able to add additional labels.

Why is this needed:

When using KIND as a library, there's no way to distinguish which ones are created by KIND itself, or if it was created by another tool using KIND as a library. It would be nice to filter out these running containers based on other labels.

I looked into using Docker for this, but it looks like you can't add labels once the container is running:

• Add labels to running Docker containers moby/moby#15496 (comment)
• Proposal: Update labels  moby/moby#21721

Other Considerations

Although I don't use it in my workflow (I just the config file mostly), it would be useful to add --label to the kind create cluster command to get the same effect.

[BenTheElder]

This is going to be clunky to support portably, because of varying restrictions in the underlying tools on what labels can be in the node runtimes, the current labels are a technically undocumented implementation detail and if we had to support a new node backend with compat issues for our internal usage we could use some other technique entirely (or base64 encode or ...).

I would recommend tracking this out of band?

[BenTheElder]

When using KIND as a library, there's no way to distinguish which ones are created by KIND itself, or if it was created by another tool using KIND as a library.

I mean, to the kind CLI and to the packages, that's working as intended? These just indicate that the kind code should be able to manipulate the container-nodes and stores some internal metadata used by the packages/cli.

Usually people pick reasonably unique cluster names like istio-test or something.

[christianh814]

I would recommend tracking this out of band?

I see that Provider.List() returns a []string so I can probably create a filter like...

func filter(s []string) []string {
	prefix := "foo-"
	var ns []string
	for _, i := range s {
		if strings.HasPrefix(i, prefix) {
			ns = append(ns, i)
		}
	}
	return ns
}

I would have to mutate the name passed to me (because I still allow that in my wrapper utility)

[BabisK]

I have a use case where labels could be a good automation facilitator. I'm dynamically creating clusters on bare metal hosts with kind and I'm using Traefik as reverse proxy to route traffic to different clusters. If I was able to add labels on the node containers, I would be able to use the Docker provider of Traefik to automatically set this up.

I can provide a PR if you are interested in this functionality.

[aojea]

I don't think that can be very portable to label the container provider, bear in mind we support now docker, podman and nerdctl ... and the use cases seems better solved by moby/moby#21721

[BenTheElder]

If I was able to add labels on the node containers, I would be able to use the Docker provider of Traefik to automatically set this up.

But not with the current labels? Traefik doesn't support custom labels?

I don't really think this sort of highly non-portable behavior is something we want to support, and we use labels internally as an important internal implementation detail and will now be conflicting with user labels.

You can get nodes via the portable Kubernetes API and our node names are 1:1 with the hosts which are in this case the containers.