Docker网络 overlay模式
本文翻译自docker官网： https://docs.docker.com/network/overlay/
The overlay network driver creates a distributed network among multiple
Docker daemon hosts. This network sits on top of (overlays) the host-specific
networks, allowing containers connected to it (including swarm service
containers) to communicate securely when encryption is enabled. Docker
transparently handles routing of each packet to and from the correct Docker
daemon host and the correct destination container.
When you initialize a swarm or join a Docker host to an existing swarm, two
new networks are created on that Docker host:
You can create user-defined overlay networks using docker network create ,
in the same way that you can create user-defined bridge networks. Services
or containers can be connected to more than one network at a time. Services or
containers can only communicate across networks they are each connected to.
Although you can connect both swarm services and standalone containers to an
overlay network, the default behaviors and configuration concerns are different.
For that reason, the rest of this topic is divided into operations that apply to
all overlay networks, those that apply to swarm service networks, and those that
apply to overlay networks used by standalone containers.
To create an overlay network for use with swarm services, use a command like
the following:
To create an overlay network which can be used by swarm services or
standalone containers to communicate with other standalone containers running on
other Docker daemons, add the --attachable flag:
You can specify the IP address range, subnet, gateway, and other options. See
docker network create --help for details.
All swarm service management traffic is encrypted by default, using the
AES algorithm in
GCM mode. Manager nodes in the swarm rotate the key used to encrypt gossip data
every 12 hours.
To encrypt application data as well, add --opt encrypted when creating the
overlay network. This enables IPSEC encryption at the level of the vxlan. This
encryption imposes a non-negligible performance penalty, so you should test this
option before using it in production.
When you enable overlay encryption, Docker creates IPSEC tunnels between all the
nodes where tasks are scheduled for services attached to the overlay network.
These tunnels also use the AES algorithm in GCM mode and manager nodes
automatically rotate the keys every 12 hours.
You can use the overlay network feature with both --opt encrypted --attachable
and attach unmanaged containers to that network:
Most users never need to configure the ingress network, but Docker allows you
to do so. This can be useful if the automatically-chosen subnet conflicts with
one that already exists on your network, or you need to customize other low-level
network settings such as the MTU.
Customizing the ingress network involves removing and recreating it. This is
usually done before you create any services in the swarm. If you have existing
services which publish ports, those services need to be removed before you can
remove the ingress network.
During the time that no ingress network exists, existing services which do not
publish ports continue to function but are not load-balanced. This affects
services which publish ports, such as a WordPress service which publishes port
The docker_gwbridge is a virtual bridge that connects the overlay networks
(including the ingress network) to an individual Docker daemon's physical
network. Docker creates it automatically when you initialize a swarm or join a
Docker host to a swarm, but it is not a Docker device. It exists in the kernel
of the Docker host. If you need to customize its settings, you must do so before
joining the Docker host to the swarm, or after temporarily removing the host
from the swarm.
Swarm services connected to the same overlay network effectively expose all
ports to each other. For a port to be accessible outside of the service, that
port must be published using the -p or --publish flag on docker service create or docker service update . Both the legacy colon-separated syntax and
the newer comma-separated value syntax are supported. The longer syntax is
preferred because it is somewhat self-documenting.
<table>
<thead>
<tr>
<th>Flag value</th>
<th>Description</th>
</tr>
</thead>
<tr>
<td><tt>-p 8080:80</tt> or<br /><tt>-p published=8080,target=80</tt></td>
<td>Map TCP port 80 on the service to port 8080 on the routing mesh.</td>
</tr>
<tr>
<td><tt>-p 8080:80/udp</tt> or<br /><tt>-p published=8080,target=80,protocol=udp</tt></td>
<td>Map UDP port 80 on the service to port 8080 on the routing mesh.</td>
</tr>
<tr>
<td><tt>-p 8080:80/tcp -p 8080:80/udp</tt> or <br /><tt>-p published=8080,target=80,protocol=tcp -p published=8080,target=80,protocol=udp</tt></td>
<td>Map TCP port 80 on the service to TCP port 8080 on the routing mesh, and map UDP port 80 on the service to UDP port 8080 on the routing mesh.</td>
</tr>
</table>
By default, swarm services which publish ports do so using the routing mesh.
When you connect to a published port on any swarm node (whether it is running a
given service or not), you are redirected to a worker which is running that
service, transparently. Effectively, Docker acts as a load balancer for your
swarm services. Services using the routing mesh are running in virtual IP (VIP)
mode . Even a service running on each node (by means of the --mode global
flag) uses the routing mesh. When using the routing mesh, there is no guarantee
about which Docker node services client requests.
To bypass the routing mesh, you can start a service using DNS Round Robin
(DNSRR) mode , by setting the --endpoint-mode flag to dnsrr . You must run
your own load balancer in front of the service. A DNS query for the service name
on the Docker host returns a list of IP addresses for the nodes running the
service. Configure your load balancer to consume this list and balance the
traffic across the nodes.
By default, control traffic relating to swarm management and traffic to and from
your applications runs over the same network, though the swarm control traffic
is encrypted. You can configure Docker to use separate network interfaces for
handling the two different types of traffic. When you initialize or join the
swarm, specify --advertise-addr and --datapath-addr separately. You must do
this for each node joining the swarm.
The ingress network is created without the --attachable flag, which means
that only swarm services can use it, and not standalone containers. You can
connect standalone containers to user-defined overlay networks which are created
with the --attachable flag. This gives standalone containers running on
different Docker daemons the ability to communicate without the need to set up
routing on the individual Docker daemon hosts.
For most situations, you should connect to the service name, which is load-balanced and handled by all containers ("tasks") backing the service. To get a list of all tasks backing the service, do a DNS lookup for tasks.<service-name>.
沃承汕鮀： 如何免 sudo 使用 docker方法如下: 如果还没有 docker group 就添加一个: sudo groupadd docker 将用户加入该 group 内.然后退出并重新登录就生效啦. sudo gpasswd -a ${USER} docker 重启 docker 服务 sudo service docker restart 切换当...
武安市17395955368： docker overlay干什么用的 - ？
沃承汕鮀： docker overlay 泊坞窗覆盖
武安市17395955368： 如何在Docker中使用Open vSwitch - ？
沃承汕鮀： 你好,使用方法如下:首先我们让ovsdb-server监听一个TCP端口:ovs-appctl -t ovsdb-server ovsdb-server/add-remote ptcp:6640 接下来,启动ovn-northd后台进程.这个进程负责将来自Docker的网络信息(存储在OVN_Northbound 数据库中)...
武安市17395955368： docker网络问题 怎么解决 - ？
沃承汕鮀： 网络基础 Docker 现有的网络模型主要是通过使用 Network namespace、Linux Bridge、iptables、veth pair 等技术实现的.(出处8) Network namespace:它主要提供了网络资源的隔离,包括网络设备、IPv4/IPv6 协议栈、IP 路由表、防火墙、...
武安市17395955368： 每个docker一个ip地址吗？
沃承汕鮀： docker run创建Docker contains时,可以用--net选项指定容器的网络模式,Docker有以下4种网络模式: host模式,使用--net=host指定. container模式,使用--net=container:NAME_or_ID指定. none模式,使用--net=none指定. bridge模式,...
武安市17395955368： 如何使不同主机上的docker容器互相通信 - ？
沃承汕鮀： Docker网络基础---Docker跨主机容器访问通信 在同一宿主机下的Docker的容器之间是默认互相联通的.通过docker inspect id或name可以查看到ip地址.在不通的容器中来执行ping是可以ping通的.但我们通过观察发现,每一个启动容器的ip...
