Re:Ask HN: What are the disadvantages of Docker?
by chatmasta on Monday April 23, 2018 @08:49AM
(#16902911)
Docker makes a lot of things easy, but the tradeoff is hidden complexity, with default configuration that may not be the best choice for what the user needs.
Let's look at networking as an example. Docker makes basic networking setup very easy with the default docker0 bridge setup. However, this is really a "solve 90% of cases" default that can really damage the 10% of cases that it is ill-suited for. Developers unfamiliar with Linux networking are unlikely to even realize it's a bottleneck. Concrete examples of where it becomes a bottleneck depend on use case, but some can be (a) unnecessary ARP table overflows when scaling to thousands of containers, (b) heavy TCP connections between containers (think appContainer<->redisContainer). The reason for the bottleneck seems to be an overreliance on iptables and ebtables for filtering container-to-container communication.
The default container-container communication is so bad that I actually switched to a shared socket (mounted in a named volume) for communication with redis instead of using the default docker networking. I didn't do any formal benchmarking, but the socket communication was significantly faster than TCP communication for high throughput reads from redis (50mb+).
Since Docker uses netns + veth under the hood, I really wish it were possible to create a netns and launch a Docker container into it with something like --net-ns MYNETNS, like you can launch it into a cgroup with --cgroup-parent. Unfortunately it's not possible without some ugly hacks AFAIK.
Of course, you can mitigate any issues like this, but it requires networking knowledge and awareness of tradeoffs you are committing to by going "off the reservation" in terms of Docker setup.
Let's look at networking as an example. Docker makes basic networking setup very easy with the default docker0 bridge setup. However, this is really a "solve 90% of cases" default that can really damage the 10% of cases that it is ill-suited for. Developers unfamiliar with Linux networking are unlikely to even realize it's a bottleneck. Concrete examples of where it becomes a bottleneck depend on use case, but some can be (a) unnecessary ARP table overflows when scaling to thousands of containers, (b) heavy TCP connections between containers (think appContainer<->redisContainer). The reason for the bottleneck seems to be an overreliance on iptables and ebtables for filtering container-to-container communication.
The default container-container communication is so bad that I actually switched to a shared socket (mounted in a named volume) for communication with redis instead of using the default docker networking. I didn't do any formal benchmarking, but the socket communication was significantly faster than TCP communication for high throughput reads from redis (50mb+).
Since Docker uses netns + veth under the hood, I really wish it were possible to create a netns and launch a Docker container into it with something like --net-ns MYNETNS, like you can launch it into a cgroup with --cgroup-parent. Unfortunately it's not possible without some ugly hacks AFAIK.
Of course, you can mitigate any issues like this, but it requires networking knowledge and awareness of tradeoffs you are committing to by going "off the reservation" in terms of Docker setup.