Kind: Allow configuration of docker network

[meyskens]

What would you like to be added:
The ability to specify specific Docker network configuration for the kind network that is getting created analog to specifying the Pod and Service CIDRs.
Something like:

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
networking:
  docker:
    subnet: "192.168.0.0/16"
    gateway: "192.168.0.0/16"

which will result into docker network create kind --subnet [...]

Why is this needed:
We are running kind inside prow jobs in GKE. When upgrading to 0.8.1 we noticed the pod networking going down.
By default docker chooses the next internal subnet to be 172.18. as it's default is 172.17.
But this subnet is used inside our cluster to route traffic over, Docker is not and can not be aware of this.

This is why it would be nice to be able to specify the specific subnet the kind containers run on.
For now we worked around this by manually creating the network as kind will not try to recreate it.

PS: Happy to work on a PR for this! Just checking first :)

[munnerz]

One of the issues we'll run into here is that the docker network is not created per-cluster, but rather per host, which makes having this config on the Cluster resource problematic (what should kind do if two different CIDRs are specified on two different clusters?).

I'm not too familiar with the internals of the docker network (I'm sure @BenTheElder is by now 😅), but _perhaps_ it is possible to (optionally) create a network-per-cluster? But if we were to do that, I'm not sure if Docker will allow us to have overlapping CIDRs between two clusters either, although perhaps that's an acceptable tradeoff? 🤷‍♂️

[BenTheElder]

We do one network to mimic the default bridge, except that the default bridge lacks the embedded DNS resolved for backwards compatibility in docker.

So far we've said "you can precreate the network yourself with whatever flags you want using docker network create ..." since the network name is intentionally well-known.

Related: #1596

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[meyskens]

/remove-lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten