Enhance cluster creation for kind-on-docker users

[ProbStub]

Apologies if this is a duplicate feature request or even a misconfiguration. I was unable to find anything similar and did face issues with kind-on-docker setup. A similar feature might be useful for minikube but since I was unable to identify what would need to be changed with minikube I am filing the request here.

What would you like to be added: It appears that kind is presently not aware whether it is running in a (sibling) docker container or in a child docker. As a result, clusters are created successfully but they become inaccessible from the (sibling) container. A test for which kind of docker environment kind is being started in (host, child or sibling), perhaps checking for /var/run/docker.sock, could help to correct the network configuration as part of the cluster creation procedure.

Why is this needed: Running kind-on-docker is useful for CI scenarios where there is very very little control on the host's docker setup. In addition, inexperienced users might be confused by the inability to connect to the master through kubectl despite a successful cluster creation.

[aojea]

this is not something easy to implement and to generalize, it will require kind to make changes in the host and outer docker network,

[ProbStub]

I see the complexity involved - especially when considering container tools other than docker. I would imagine a note to the user at the end of the cluster creation would already go a long way. Perhaps it is possible to show some kind of advice that manual network changes are required if a kind-on-docker setup is detected, e.g., connecting the cluster network to the container.

[BenTheElder]

~I think any such note at the end of cluster creation would quickly grow out of hand and should live in the docs instead.~

Edit: Actually if it were only printed with confidence that we're running in a container ourselves, this might? be reasonable. but it's also unnecessary noise if the container is on the correct network.

This probably belongs in an advanced usage guide.

The simplest approach is to ensure that any containers that wish to interact with kind are attached to the kind network. You can either create them with --net=kind or you can use docker network attach $container kind.

[BenTheElder]

I don't think this is a mode we're recommending or prioritizing. KIND is published as a single static go binary that should run on the host and only depends on the container runtime and indirectly the node image