In the previous section:Docker container Network – Basic
The article mentioned the dependence of container network on Linux virtualization technology. In this chapter, we will explore how docker works. Usually, the network of Linux container is isolated in its own network namespace, including network interface, loopback device, routing table and iptables rules. For a process, these elements constitute the basic environment for it to initiate and respond to network requests.
to see only one spot
We’re doing it
docker run -d --name xxxAfter that, enter the container:
##Docker PS to view all dockers ##Enter the container docker exec -it 228ae947b20e /bin/bash
And execute ifconfig:
$ ifconfig eth0 Link encap:Ethernet HWaddr 22:A4:C8:79:DD:1A inet addr:192.168.65.28 Bcast:
We see a network card called eth0, which is a Veth pair device at this end of the container.
We can view the routing table of the container through route
$ route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use If
We can see that eth0 is the default routing device for this container. We can also see from the second routing rule that all requests for 169.254.1.1/16 network segment will be handled by eth0.
On the other end of the Veth pair device, we can also view it by looking at the host’s network devices
$ ifconfig ...... eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 172.16.241.192 netmask 255.255.240.0 broadcast 172.16.255.255 ether 00:16:3e:0a:f3:75 txqueuelen 1000 (Ethernet) RX packets 3168620550 bytes 727592674740 (677.6 GiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 2937180637 bytes 8661914052727 (7.8 TiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 ...... docker0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255 ether 02:42:16:58:92:43 txqueuelen 0 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 ...... vethd08be47: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 ether 16:37:8d:fe:36:eb txqueuelen 0 (Ethernet) RX packets 193 bytes 22658 (22.1 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 134 bytes 23655 (23.1 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 ......
On the host computer, the Veth pair device corresponding to the container is a virtual network card, which we can reuse
brctl showCommand to view the bridge:
$ brctl show bridge name bridge id STP enabled interfaces docker0 8000.0242afb1a841 no vethd08be47
You can clearly see that one end of the Veth pair, vethd08be47, is plugged into docker 0.
I will now execute docker run to start two containers, and I will find one end of the Veth pair with two containers inserted on docker 0. If we Ping each other’s IP address in one container, can we Ping each other?
$ brctl show bridge name bridge id STP enabled interfaces docker0 8000.0242afb1a841 no veth26cf2cc veth8762ad2
$ docker exec -it f8014a4d34d0 /bin/bash $ ifconfig eth0 Link encap:Ethernet HWaddr 02:42:AC:11:00:0
$ docker exec -it 9a6f38076c04 /bin/bash $ ifconfig eth0 Link encap:Ethernet HWaddr 02:42:AC:11:00:0
Ping from one container to another:
#- > container 1 internal Ping container 2 $ ping 172.17.0.3 PING 172.17.0.3 (172.17.0.3): 56 data bytes 64 bytes from 172.17
We can see that it is possible to Ping the IP address of another container in one container. This means that the two containers can communicate with each other.
We might as well combine what we said above to understand why one container can access another container? Let’s take a simple look at this picture
When the address of container 2 is accessed in container 1, the destination IP address will match the second routing rule of container 1. The gateway of this routing rule is 0.0.0.0, which means that this is a direct connection rule. In other words, all requests matching this routing rule will be directly sent to the destination host through the eth0 network card through the layer 2 network. To reach container 2 through layer 2 network, the MAC address corresponding to 127.17.0.3 is required. Therefore, the network protocol stack of container 1 needs to send an ARP broadcast through eth0 network card, and find the MAC address through IP.
The so-called ARP (address resolution protocol) is to find the MAC address of layer 2 through layer 3 IP address. The eth0 mentioned here is one end of the Veth pair, and the other end is plugged into the docker 0 bridge of the host. When a virtual network card such as eth0 is inserted on docker 0, it means that eth0 becomes the “slave device” of the docker 0 bridge. The slave device will be demoted to the port of the docker 0 device, and the qualification of calling the network protocol stack to process the packets is handed over to the docker 0 bridge.
Therefore, after receiving the ARP request, docker 0 will play the role of layer 2 switch and send the ARP broadcast to other virtual network cards inserted in the docker 0 bridge. In this way, 127.17.0.3 will receive the broadcast and return its MAC address to container 1. With this MAC address, the network card of eth0 in container 1 can send the packet out. This packet will go through the Veth pair on the other end of the host, veth26cfc, and directly deliver it to docker 0.
The forwarding process of docker 0 is to continue to act as a layer 2 switch. According to the destination MAC address of the packet, docker 0 finds the corresponding port in the cam table as veth8762ad2, and then sends the packet to this port. This port is that the Veth pair of container 2 is at the other end of the host. In this way, the packet enters the network namespace of container 2, and finally container 2 will ping the response back to container 1. In the real data transmission, the Linux kernel Netfilter / iptables will also participate in the process, which will not be repeated here.
Cam is the corresponding table of port and MAC address learned and maintained by switch through MAC address
The communication mode between containers introduced here is the most common bridge mode in docker. Of course, there are also host mode, container mode, none mode and so on. Those who are interested in other modes can read relevant materials.
Cross master communication
Well, I can’t help asking a question here. So far, it’s only communication between containers within a single host. What about cross host networks? Under the default configuration of docker, the docker 0 bridge of one host cannot be connected with other hosts. There is no association between them. Therefore, the containers on these bridges naturally cannot communicate with each other. However, no matter how it changes, the truth is the same. If we create a public bridge, can all containers in the cluster be connected through this public bridge?
Of course, under normal circumstances, nodes can communicate with each other through NAT. However, with the development of the Internet today, it may not be applicable in the container environment. For example, when you register an instance with the registry, you will certainly carry the IP. Of course, there is no problem with the application in the normal physical machine, but not necessarily in the containerized environment. The IP in the container is likely to be 172.17.0.2 as mentioned above. Multiple nodes will have this IP, and the IP will conflict in large probability.
If we want to avoid this problem, we will carry the host’s IP and mapped port to register. However, this brings another problem, that is, the application in the container realizes that this is a container, not a physical machine. When inside the container, the application needs to take the IP of the physical machine where the container is located, and when outside the container, the application needs to take the IP of the current physical machine. Obviously, this is not a very good design, which requires the application to cooperate with the configuration. Therefore, based on this, we must look for other container network solutions.
In the above container network, we need to build a virtual network covering multiple hosts and connecting all containers through software on our existing host network. This is the overlay network.
As for these specific network solutions, such as flannel, calico, etc., I will continue to present them in the following pages.
A kind of Link:https://www.cnblogs.com/sally…
Author Mr_ Zack_