Improve kind get kubeconfig and kind export kubeconfig for multicluster

[howardjohn]

What would you like to be added:

• A new flag, kind export kubeconfig --internal, matching kind get kubeconfig --internal. I don't personally care about this one, but it seems like we should be consistent.
• A new flag, like kind export kubeconfig --docker (with a better name). This would export the result of docker inspect "${CLUSTER_NAME}-control-plane" --format "{{ .NetworkSettings.Networks.kind.IPAddress }}" as the address

Why is this needed:

• Default of 127.0.0.1 allows only reaching from host
• --internal only allows reaching from internal
• This mode allows reaching from the host and internally

[BenTheElder]

The first point has an open discussion / tracking issue and pull request that need following up on. @aojea has been active reviewing that.

The second point I brought up in that discussion.

[BenTheElder]

This mode allows reaching from the host and internally

• On Linux, or else it would be the default. Also it will not be the case if rebooting / restarting docker and getting a new IP, which otherwise works for single node clusters. I think John knows this, but for anyone else interested this is why.

Existing discussion: #2217

[aojea]

what if we use a env variable to modify the internal flag or export kubeconfig behaviour?
at least with some EXPERIMENTAL_KUBECONFIG_INTERNAL_IP=true we can unblock this

[BenTheElder]

I guess we can, but people will start to depend on it obviously, I would've liked an answer for this before #2218

[gprossliner]

Having Environment-Variable based Flags without an corresponding CLI flag is no good UX, in my opinion. So I would consider implementing the --address-type flag, as discussed in #2217.

From #2217 (comment):

My suggestion for --address-type would be:

-address-type=	URL	Host-Resolvable	Container-Resolvable
container-name	https://kind-control-plane:6443	No	Yes
container-ip	https://172.18.0.2:6443	Linux only	Yes, on 'kind' network
host-port	https://127.0.0.1:36995	Yes	No

The current default would be "host-port". I would use "container-ip" as the default on Linux, because the URL is resolvable on the host, and internally.

A clean migration path could be like:

• Phase 1: Quit with error if one uses --internal and --address-type
• Phase 1: Output a descriptive warning to stderr if --internal is used, and continue with --address-type=container-name
• Phase 2: Remove --internal from help, and quit with a descriptive error if it is still used
• Phase 3: Remove --internal completely, if it is still used one will just get an "invalid flag" generic error

[aojea]

This LGTM

[howardjohn]

Having Environment-Variable based Flags without an corresponding CLI flag is no good UX, in my opinion. So I would consider implementing the --address-type flag, as discussed in #2217.

From #2217 (comment):

My suggestion for --address-type would be:

-address-type=
URL
Host-Resolvable
Container-Resolvable

container-name
https://kind-control-plane:6443
No
Yes

container-ip
https://172.18.0.2:6443
Linux only
Yes, on 'kind' network

host-port
https://127.0.0.1:36995
Yes
No

The current default would be "host-port". I would use "container-ip" as the default on Linux, because the URL is resolvable on the host, and internally.
A clean migration path could be like:

• Phase 1: Quit with error if one uses --internal and --address-type
• Phase 1: Output a descriptive warning to stderr if --internal is used, and continue with --address-type=container-name
• Phase 2: Remove --internal from help, and quit with a descriptive error if it is still used
• Phase 3: Remove --internal completely, if it is still used one will just get an "invalid flag" generic error

A few years later this still sounds great to me, any appetite to merge something like this if I put up a PR?

[aojea]

we are doing this in cloud provider kind https://github.com/kubernetes-sigs/cloud-provider-kind/blob/680d0901472bed1c7d57deb5c6a0d454e1cef8c4/pkg/controller/controller.go#L58-L62 ,

how will it look like?
or it will be simpler to create an external tool just for this?

[howardjohn]

Main motivation for getting this into kind and not an external tool is people use kind for documentation walkthrough, where we don't really want to impose a requirement for a bunch of tools

[aojea]

bunch of tools
fair

I get the --internal flag but the one that says --docker to reach from host ... you can already do that with the existing one to localhost and the portmaps