The Docker daemon pulls a /16 address space for each automatic network setup, starting from 172.17.0.0/12 until it starts eating into the 192.168.0.0/16 address space /20 at a time as well¹⁾. This may conflict with any internal subnets associated with your network, especially if the subnets are not under your control²⁾.

To mitigate this problem, use an unused address range and also reduce the number of addresses per network, by configuring³⁾ the Docker daemon:

/etc/docker/daemon.json

{
  "default-address-pools": [
    { "base": "10.134.18.0/20", "size": 26 }
  ]
}

The base corresponds to the address pool, and the size denotes the size of each subnet (also in CIDR notation). I would think it would be strange to have:

• More than 64 hosts (especially in a non-HA setting, and without network segmentation)
• More than 64 groups of services on a single server (unless your electrical bill is through the roof :p)

Both would correspond to 6-bits, so size should have a prefix length of 26 and base a length of 20. Roll two 8-bit numbers from the random number generator to fill in the second and third bytes of the 10.0.0.0/8 address space (rolled 134 and 18 in the example above). Then prune existing Docker networks (after tearing down the services) and restart the daemon:

user:~$ ip r
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 
172.18.0.0/16 dev br-24af806f6a7d proto kernel scope link src 172.18.0.1 linkdown 
172.19.0.0/16 dev br-cf60abcce4eb proto kernel scope link src 172.19.0.1 linkdown
 
user:~$ docker network prune
user:~$ systemctl restart docker
user:~$ ip r
10.134.16.0/26 dev docker0 proto kernel scope link src 10.134.16.1 linkdown