The world loved me first, and I can’t help loving it! — Wang Zengqi [Human Plants and Trees]

What? I heard that some people want to tell it to themselves [surprised], others are telling it to their girlfriends, tell it to a three-year-old child! Uh, uh… This is not have no girlfriend [hey hey]!! Today, we are going to study the network foundation of Docker seriously (I believe that many people only stay at the level of knowing how to use Docker, when it comes to Docker network, the heart should be very vague).

Docker network is strongly dependent on the support of the Linux system kernel. Docker mainly uses the following Linux network technologies:

  • Network Namespace

  • Veth equipment for

  • The bridge

  • Iptables/Netfilter

  • routing

Network namespace

In general, physical network devices (devices connected to physical hardware) can only be associated with the root namespace. Virtual network devices (virtual Ethernet interfaces or virtual network interface pairs) can be created and associated with the specified namespace.

  • The purpose of a Linux network namespace is to run on a virtual machineVirtualize multiple instances of separate, isolated network environmentsRepresents separate network protocol stacks that cannot communicate with each other.
  • Docker takes advantage of this feature to achieve network isolation between different containers.
  • Each network instance has its own independent routing table and independent Iptables/Netfilter to provide packet forwarding, NAT, and IP packet filtering.
  • Some devices in space can be transferred to each other, such as Veth, but like bridging devices, LO devices are not.
Here are some common namespace operations using the Linux iproute2 tool: - Create a namespace IP netns add <name> - Run the IP netns command in the namespaceexec <name> <command> - Enter sh IP netns inside the namespaceexec <name> bash
Copy the code

Veth equipment for

So how do different cyberspace communicate with each other and with the outside world? The answer is a “Veth device pair,” which acts like a tube connecting and communicating with Ethernet cards in two different network namespaces. Docker also uses this to communicate with the outside world.

- Create Veth device pair veth0, veth1 in a namespace IP link add veth0typeVeth peer name veth1 - View the result IP link show - Throw the 'network cable header' to another namespace IP linksetVeth1 netns netns1 n/A Access netns1 to view IP NetnsexecNetns1 IP link show At this time, only two namespace Veth device pairs are created, there is no IP, cannot communicate. - Assign IP IP netnsexecNetns1 IP addr add 10.1.1.1/24 dev veth1 IP addr add 10.1.1.2/24 dev veth0 - Restart IP netns againexec netns1 ip link set dev veth1 up
  ip link setDev veth0 up Verify communication between the two namespaces: ping 10.1.1.1 IP netnsexecNetns1 ping 10.1.1.2 Check the peer end of Veth: IP netns excec netns1 ethtool -s veth1 IP netnsexecNetns2 IP link | grep $(step on the device number)Copy the code

The bridge

A bridge is a layer 2 device. It parses the received packets, removes the MAC header, and combines it with the RECORDED MAC address table to determine the port for forwarding the packets. If an unrecorded MAC address is encountered, it can only broadcast to all network device ports.

  • Can be thought of as an “underlying router” (router works at the network layer and forwards IP based on network address)

To prevent the transfer and detection failure of the network device, the port of the packet sent based on the historical MAC address table is no longer received by the peer. The bridge determines the timeout period and broadcasts the packet again if the timeout period expires.

After the packet from eth0 or eth1 is submitted to the bridge, the bridge determines whether the packet should be forwarded, lost, or forwarded to the network

Common bridge operation commands are as follows: - Add a bridge BRCTL addbr XXXX - Add an Ethernet interface card to the bridge BRCTL addif XXX ethx - Configure an IP address for the bridge ifconfig BRXXX XXX.XXX.xxx.xxxCopy the code

Iptables/Netfilter

A set of callback functions in the Linux network protocol stack hook hook functions can filter, modify, and discard packets while they are being processed by Linux. This hook point technology is called Iptables and Netfilter.

  • Netfilter performs various mount rules in kernel mode
  • Iptables assists in maintaining the various rule tables of Netfilter in the kernel in user mode
  • They work together to realize flexible packet processing mechanism in the whole Linux network protocol stack

Netfilter can be connected to five rule points:

Rule Table Table

The rules attached to the rule Table can be classified into different types. We can add rules to different tables. Currently, the Table types supported are as follows:

The above rules decrease in priority from left to right. When a packet is processed at the hang point, the functions at the hang point are called in turn until it is clear whether the packet is received or rejected.

Features of data processing rules:

  • What is the table type (ready to do something)
  • What hook point (and when it works)
  • What parameters are matched (for what packet, incoming, outgoing, source, destination, protocol type, etc.)
  • What is the action after the match? (What is the specific operation after the match?)

Iptables command: - View existing rules: iptables -l -nCopy the code

routing

Routing is implemented by the routing table maintained by the IP layer. If the IP address in the packet is not the IP address of the host, the packet is forwarded or discarded.

Routing tables usually contain:

  • Destination IP address
  • IP address of the next router
  • Flag (is it a host address or router address)
  • Network interface specification
- to seelocalRouting table IP route show tablelocal type local
  ip route list
  netstat -rn
Copy the code

Docker network implementation

Docker supports four types of network modes:

  • Host mode, –net=host
  • Container mode, –net=container:NAME_or_ID
  • None mode, –net= None
  • Bridge mode, –net=bridge

In K8s network mode, usually just bridge mode is used

In bridge mode, the Docker Daemon creates a virtual bridge when it first starts. The default name is Docker0 and a subnet is allocated.

Docker0 bridge subnet address range:

  • 17-172. [31]. 42.1/16
  • 10. [0-255]. 42.1/16
  • 192.168. [42-44]. 1/24

Most of the time the docker0 bridge address is 172.17.xxx.xxx.

  • Each container created by Docker will create a virtual Ethernet device (Veth device pair), one end is placed in the host’s network namespace and associated with the bridge, the other end is mapped to eth0 in the container, and then an IP address is assigned to eth0 from the address segment of the Docker0 bridge.
  • A host container can communicate with each other through the assigned IP address. Containers on different hosts cannot communicate with each other
  • Both the Docker0 bridge and Iptables rules are in the root namespace

You can ping gateways or other containers on a host from the container

Custom Docker bridge devices

Generally, a self-defined bridge device is no different from the default Docker0.

service docker stop
ip link set docker0 down
brctl delbr docker0
brctl add addbr cookbook
ip link setCookbook up IP addr Add 10.0.0.1/24 dev cookbookCopy the code

When there is communication between multiple Docker hosts, you can use GRE tunnel or Weave network automatic IP allocation and integrated DNS service discovery, because the next will continue to summarize k8S container overlay network, to achieve cross-host communication, so it will not expand here.

conclusion

Based on Linux network technology, Docker enables containers on the same host to communicate with each other and share a subnet segment. The concept of Docker is that simplicity is beauty. It solves the problem of Docker interconnection through virtualization network technology, so as not to leave the shadow of network to users like OpenStack, which is also the reason for Docker’s rapid popularity. In the next installment, we will continue studying the networking basics of K8s and take you through the details of the components and how they communicate.

reference

  • The Definitive K8S Guide
  • Docker Classic Examples