Support joining any network namespace

[mrunalp]

If docker supports joining any network namespace, then network topology could be left to higher level orchestration. This allows for flexibility in docker deployments. The user could setup the network by creating a new network namespace via ip netns, customize as required and then just pass it to docker with something like --net=netns:/var/run/netns/mycustomnet1.

The advantage is that docker does not have to worry about supporting all the different types of bridges/switches/custom protocols that users might want to use.

[mrunalp]

ping @shykes @crosbymichael

[larsks]

+1

This seems like a very flexible option for handling network configuration. People are constantly trying to do things other than simple "give docker a bridge and total control over address range" model, and this would make that a lot easier.

[rhatdan]

I kind of like this idea. Might have to handle the /etc/resolv.conf issues also

[larsks]

I guess this is pretty much what kubernetes does already, using native docker support:

• create a "no-op" container (e.g. using the kubernetes/pause image), possibly with --net=none,
• configure networking in that container as desired,
• boot additional containers in that network namespace using --net=container:xxx

So that basically gets you to the same place, at the expense of always requiring the network container.

[thockin]

The extra net container is a constant source of questions for kubernetes,
and it brings some complexity to the code. We would love to get rid of it,
or hide it, or something.

On Sat, Oct 4, 2014 at 8:16 PM, Lars Kellogg-Stedman <
notifications@github.com> wrote:

I guess this is pretty much what kubernetes does already, using native
docker support:

• create a "no-op" container (e.g. using the kubernetes/pause image),
  possibly with --net=none,
• configure networking in that container as desired,
• boot additional containers in that network namespace using
  --net=container:xxx

So that basically gets you to the same place, at the expense of always
requiring the network container.

Reply to this email directly or view it on GitHub
#7455 (comment).

[mrunalp]

@larsks @thockin This could be one potential solution to avoid having the networking container in kubernetes.

[larsks]

Yes, totally; a docker native solution would be much preferable. My comment stemmed from the fact that I was explaining kubernetes container networking to somebody and suddenly a light went off in my head and I realized the connection to this issue.

[byxorna]

+1

[rhatdan]

It would be nice to get someone from Docker to actually comment on this...

[crosbymichael]

There was a PR opened here #8216 where a is discussion going on.

[cpuguy83]

Closing as this is no longer relevant (and ultimately rejected in the aforementioned PR).
Docker provides a backend api for configuring network namespaces that can be hooked into via plugins in github.com/docker/libnetwork as of docker 1.9.