Do we want to allow services to use the host's network namespace? #989
Comments
|
@jpetazzo All if this is technically possible. We just have to decide on what the swarmkit api should be for this. One options is to introduce a network attachment type |
|
@mrjana Rather than a new attachment type, this sounds like a new network type. This could be implicit or explicit, but you would just attach to The main complexity here will be dispatching containers such that their ports don't collide. |
|
@stevvooe The reason why I was hesitant about a new network type is because we have already something like that in docker and we have to define something like that here as well. Those two would conflict in docker UX. And yes we have to take care of port conflicts. Doesn't look likely for 1.12 |
|
+1 |
What properties are required by Netflix Eureka? Is it just the ability to route directly to an instance of the service? |
|
@stevvooe I need register my apps with a valid IP (host IP) because Eureka is an external service that I'm only a client. I cannot start my containers with overlay network as third clients won't have route to this. |
|
@fabiodoaraujo So, this is a requirement we've heard coming from a few places. It's basically to register the location of a specific instance via an IP. Host-level networking is one solution, but not the only solution. Routability is the key problem. Thank you for the description! |
|
I have the same problem like @fabiodoaraujo . My App can register its IP:PORT to Zookeeper for Service Discovery. But I do not know how to do the same thing in swarmkit. Would you please give me a solution. |
|
I would like to use host network in docker swarm mode. The overlay network is good. But VXLAN base networks are decreased performance than host-to-host network. (I think that ipvlan is better performance. And docker driver of it is.) So sometimes I would like to use host network for Network-intensive apps. And I feel like the docker swarm mode is less flexible then docker swarm. It is not good to me. Do you have any roadmaps or opinions for it? |
|
@anarcher The main issue is how to represent it. Everyone says they want "host" networking, but which host in the swarm? How should it be configured? What if there are two services with conflicting requirements for host networking? And that just scratches the surface. At least these questions need to be answered before we add this. |
|
I'm going to try to answer @stevvooe's questions, since I think this is a useful feature.
My understanding is that a container belonging to a service running with "host" networking would access the host stack on which it's running.
API-wise, it could use a network named
This can be reframed within the more general context:
It's up to the user to specify placement constraints to ensure that this doesn't happen. Let me know if I can help further! |
|
Also, Weave Scope need this, as it uses conntrack for monitoring all network connections in a cluster. |
|
@jpetazzo Superficially, these seem like simple problems, but how do you manage port allocation, especially against ports that may not be observable? If we leverage optimistic allocation (try to bind and respond error), how can we guarantee convergence? |
|
@stevvooe I don't think that it should be SwarmKit's job to manage port allocation in this very specific scenario. If somebody is using host networking, they have to understand that port allocation can fail, and they have to plan for it (e.g. by setting appropriate labels and placement constraints). There are other similar scenarios out there, for instance code optimized for a specific CPU running in a cluster where incompatible CPUs are present: the operator has to step in. |
|
We really need the ability for services to affect the host it is running on. In my case, I am am trying to run lldp in a container and forward that info somewhere, so I don't even need to port forwarding, but I really need host networking. |
|
I also need the docker service to use my custom bridge network in the cluster. |
|
This would be very useful. I see it very useful for deploying infrastructural applications which do need to leverage swarm services. |
|
+1 |
|
"Asterisk poses some challenges for Docker, namely that the RTP ports are pseudo-dynamic, and there’s a lot of them. Docker does proxying for each port that’s mapped into a container, and spawns a docker-proxy process for each one. That’s fine if you have 1-2 ports, but if you may have over 10,000 of them that’s a big problem. The solution here is to configure the container to use the host’s networking stack, then do some config on the container so that it uses a different IP from the host (to keep the host’s IP space “clean”)." How could the above be done without using host's networking stack? |
|
+1 |
|
+1 |
|
+1 |
|
It's a great news!! |
|
waiting add to compose-file |
|
Would this also let us create a service and bind its published port to a specific interface on that node with a deployment constraint? |
When experimenting, I came across a few cases where I wish I could run services with host networking (à la
--net hostin Docker).Specifically:
vconfigand setup 802.1lacp in global services, to automate bonding and VLAN provisioning...)It could also make the case for using SwarmKit without the associated network stack (but I don't know if that is easily modularizable).
The text was updated successfully, but these errors were encountered: