Network driver alternative to --net=container:id for pod networking

[bradrydzewski]

There are a number of systems including kubernetes that provide the ability to use pod-style networking:

Each Pod in a Kubernetes cluster is assigned an IP in a flat shared networking namespace. This allows for a clean network model where Pods, from a networking perspective, can be treated much like VMs or physical hosts.

This allows containers in the pod to share the same network and communicate over localhost

This can be achieved today by creating and starting a dummy container for the sole purpose of providing a shared network. The group of containers in the pod use --net=container:id to share the dummy container's network. This is certainly a viable approach, however, there seems to be room for improvement.

The proposal is to implement a new network driver for creating a flat, shared networking namespace that can be used without creating a dummy container:

docker network create -d shared my-shared-network

The creation of a network driver is not something I have much experience with, so I apologize if the proposal is light on technical detail. I wanted to first gauge interest.

note there is an existing GitHub issue for making pods first class citizens in Docker (see #8781), however, the scope seems pretty large. The purpose of creating this as a separate issue is to propose incremental / smaller scale changes that could improve how we work with pods today.

[justincormack]

A shared network namespace is not really a "network" in the sense of docker network create, so I don't really think this is the right way of thinking of it.

Why create a dummy container? Why not just use the first one you create?

[bradrydzewski]

A shared network namespace is not really a "network" in the sense of docker network create

I guess I thought of it as creating a network since --net=container:id is described as "putting the container's processes inside of the network stack that has already been created". I'll admit I don't now enough about the internals, though, to argue semantics. I was thinking docker network create <name> would create a network stack and allocate and IP that would get shared across all containers using --network=<name>

Why create a dummy container? Why not just use the first one you create?

any containers using --net=container:id will lose connectivity if the container sharing the network stops and restarts. This makes such a configuration a bit more fragile if there is an unexpected restart, or if we want to isolate and upgrade a container that also happens to be providing the shared network.

[justincormack]

Ah I see. Technically you can create namespaces that live independently of containers, by holding a file descriptor corresponding to the namespace open somewhere else (eg in the daemon). As you say you need to manage the lifecycle. You might be able to prototype this outside docker, there might well be some issues haven't really gone through the detailed mechanics.

[thaJeztah]

Let me close this ticket for now, as it looks like it went stale.