Docker container technology-container network

table of Contents

The development trend of container network

CNI

CNI (Container Network Interface) is a container network standard led by Google and CoreOS. It is developed on the basis of the RKT network proposal, taking into account factors such as flexibility, scalability, IP allocation, and multiple network cards. .

CNI aims to provide network standardization for container platforms. Different container platforms (eg Kubernetes, Mesos, and RKT) can call different network components through the same interface. This protocol connects two components:

1. Container Management System
2. Network plugin

Specific things are implemented by plug-ins, including: creating a container network space (network namespace), placing a network interface (interface) in the corresponding network space, and assigning IP to the network interface.

Currently, the solutions provided by CNI are generally divided into two types

1. Tunnel plan
2. Routing scheme

Specifically: Flannel, Callico, Weave and macvlan network solutions. In terms of difficulty, Callico is the simplest, followed by Flannel, and Weave is the most complicated. From the perspective of network technology, both Weave and Flannel are network encapsulation tunnel technologies. The difference lies in the location of the encapsulation on the network device or the host.

Flannel

Flannel is a network solution proposed by CoreOS to solve cross-host communication in container clusters. Flannel is essentially an Overlay network, that is, TCP data is packaged in another network packet for routing, forwarding and communication. Currently, it supports UDP, VXLAN, AWS VPC, GCE routing and other data forwarding methods, among which VXLAN technology is the most Popular, many data centers consider switching to Flannel's VXLAN network when considering the introduction of containers.

Flannel assigns a Subnet to each host, and the container assigns IP from this Subnet. These IPs can be routed between hosts, and containers can communicate across hosts without NAT and port mapping. Flannel allows different node hosts in the cluster to have a unique virtual IP address in the entire cluster when creating containers, and connect to the host node network. Flannel can re-plan IP address usage rules for all nodes in the cluster, so that containers on different nodes can obtain "same intranet" and "non-duplicate" IP addresses, allowing containers on different nodes to directly pass through the intranet For IP communication, the network encapsulation part is invisible to the container. The source host service encapsulates the original data content in UDP and delivers it to the destination node according to its own routing table. After the data arrives, it is unpacked, and then directly enters the destination node virtual network card, and then directly reaches the destination host container virtual network card to achieve the purpose of network communication.

Although Flannel has high requirements on the network, encapsulation technology is introduced, and the forwarding efficiency is also affected, but it can smoothly transition to the SDN network. VXLAN technology can be well integrated with SDN, and it is worthy of automatic deployment and intelligent operation and maintenance of the entire network. And management, more suitable for new data center network deployment.

Callico

The biggest difference between the Callico container network and other virtual networks is that it does not use an overlay network for packet forwarding, and provides a pure three-layer network model. The three-layer communication model means that each container communicates directly through IP. For routing to work properly, the host node where each container is located must have some way to know the routing information of the entire cluster. Callico uses the BGP routing protocol to make the entire network The Node and network equipment of the network record the route to the whole network.

However, this method will produce a lot of invalid routes, which requires a lot of network equipment routing specifications, and the entire network cannot have equipment with low routing specifications. In addition, Callico realizes routing from the source container to the source host, through the data center, then to the destination host, and finally to the destination container. The entire process is always routed and forwarded according to the BGP protocol, without packetization or unpacking. Process, so the forwarding efficiency will be much faster, which is the technical advantage of Callico container network.

Weave

Weave is essentially an Overlay network. Weave can virtualize the network connecting containers on different hosts into a network similar to a local network. Different hosts use their own private IP addresses. When containers are distributed on multiple different hosts At the time, the communication between these containers can be simplified through Weave.

Containers in the Weave network use standard ports to provide services (eg MySQL uses 3306 by default), and managing microservices is very straightforward and simple. Each container can communicate with other containers through a domain name, or communicate directly without using NAT, and without port mapping or complicated connections.

The biggest advantage of deploying Weave container network is that you don't need to modify your application code. Weave starts a virtual router on each host in the container cluster and uses the host as a router to form an interconnected network topology. On this basis, it realizes the cross-host communication of the container.

To deploy Weave, you need to ensure that the host Linux kernel version is above 3.8, Docker 1.10 or above. If there is a firewall for access between hosts, the firewalls must let each other port numbers such as TCP 6783 and UDP 6783/6784. These are the Weave control and data ports. The names cannot be the same, Weave needs to identify the subnet by the host name.

The Weave network is similar to the host Overlay technology, which directly encapsulates the packet traffic on the host, so as to realize the mutual access between the host and the host across the Underlay three-layer network. This is the biggest difference from the Flannel network. Flannel is a network overlay solution. .

Macvlan

Macvlan is a relatively new feature of Linux Kernel. It allows multiple virtual network interfaces to be configured on a network interface of the host. These network interfaces have their own independent MAC addresses, and can also be configured with IP addresses for communication. The virtual machine or container network under macvlan and the host are in the same network segment and share the same broadcast domain. Macvlan and bridge are similar, but because it eliminates the existence of bridge, configuration and debugging are relatively simple, and the efficiency is relatively high. In addition, macvlan itself also perfectly supports VLAN.

ServiceMesh + CNI

ServiceMesh and CNI are a combined relationship. ServiceMesh does not replace CNI. They work at different SDN levels. CNI works more at the L2-4 level, and ServiceMesh works at the L5-7 level Application SDN. ServiceMesh cannot be deployed independently of CNI, and together with CNI provides the network services required by hierarchical microservice applications. According to a Gartner report, in 2020, almost 100% of container clouds will have ServiceMesh technology built in. The current open source Istio only provides microservice governance within a single Kubernetes cluster, and lacks heterogeneous container cloud and cross-cloud capabilities.

CNI needs to be delivered to each POD container inside the microservice at the L2-4 layer of the container cloud. Application terminal delivery required L2 network connection, L3 routing, L2-4 layer security isolation, overall container cloud security, load balancing, etc.

ServiceMesh is more committed to service governance at the microservice application level, and is committed to L5-7 layer network services. The service mesh deploys a Sidecar Envoy application proxy in front of each application container to provide intelligent routing between microservices and distributed loads. Balance, traffic management, blue-green, canary release, microservice elasticity, current limit circuit breaker, timeout retry, visualization between microservices, security, etc.
·

Docker container network

Docker provides several types of networks, which determine the way of communication between containers and between containers and the outside world.

• Basic network type
  

• View all container network types:

$ docker network ls
NETWORK ID          NAME                DRIVER              SCOPE
c79756cf9cde        bridge              bridge              local
204025a5abbc        host                host                local
9b9024f5ac40        macvlan             macvlan             local
6478888548d8        none                null                local
p2e02u1zhn8x        overlay             overlay             swarm

bridge mode

The Docker network in bridge mode is implemented based on Linux's virtual network technology. Container Docker's network interfaces are virtual interfaces by default, which can give full play to the efficiency of data forwarding between different Containers or between Containers across hosts. This is because Linux virtual network technology realizes data forwarding between virtual interfaces by copying data in the kernel, that is: the data packets in the sending buffer of the sending interface will be copied directly to the receiving buffer of the receiving interface without going through External physical network equipment is exchanged.

When the Docker Daemon is started, a Linux Bridge named docker0 will be created on the host, and Docker Containers started on the host will be connected to this virtual bridge. Docker Daemon will assign an IP from the docker0 (a virtual L2 network) subnet to the Container for use, and set the IP address of docker0 as the default gateway of the Container. At the same time, create a pair of veth pair virtual network cable devices on the host. Docker Daemon inserts one end of the veth pair device into the newly created Container and named it eth0 (the container's network card), and inserts the other end into the docker0 Linux Bridge in vethxxx format name.

Containers in this network can communicate with each other. If the outside world wants to access Containers in this network, they also need to access the bridge network and implement DNAT rules through iptables to achieve internal and external address conversion.

$ ip a
3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:46:c3:00:eb brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:46ff:fec3:eb/64 scope link
       valid_lft forever preferred_lft forever

$ docker run -itd --name box1 busybox

$ docker exec -it box1 sh

/ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
6: eth0@if7: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue
    link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.2/16 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:acff:fe11:2/64 scope link
       valid_lft forever preferred_lft forever

/ # ip r
default via 172.17.0.1 dev eth0
172.17.0.0/16 dev eth0 scope link  src 172.17.0.2

$ brctl show
bridge name	bridge id		STP enabled	interfaces
docker0		8000.024246c300eb	no		vethd4ae072

host mode

If the host mode is used when starting the Container, the container will not get an independent Network Namespace, but will share a Network Namespace with the host. In other words, Container will not virtualize its own network card, configure its own IP, etc., but directly use the host's IP and port.

Of course, other aspects of the Container, such as the file system, process list, etc., are still isolated from the host. Containers that only use this type of network will use the host's network. This type of network is completely open to the outside world. If you can access the host, you can access the container.

$ docker run -itd --network host --name box2 busybox

$ docker exec -it box2 sh

/ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether fa:16:3e:94:84:10 brd ff:ff:ff:ff:ff:ff
    inet 172.18.22.204/24 brd 172.18.22.255 scope global dynamic eth0
       valid_lft 48054sec preferred_lft 48054sec
    inet6 fe80::f816:3eff:fe94:8410/64 scope link
       valid_lft forever preferred_lft forever
3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
    link/ether 02:42:46:c3:00:eb brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:46ff:fec3:eb/64 scope link
       valid_lft forever preferred_lft forever
7: vethd4ae072@if6: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue master docker0
    link/ether ce:95:19:64:d0:d4 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::cc95:19ff:fe64:d0d4/64 scope link
       valid_lft forever preferred_lft forever

macvlan mode

For some applications, such as monitoring network traffic and expecting to connect directly to the physical network, in this case, you can use the macvlan network mode. The macvlan driver not only assigns the IP address to the container, but also assigns the physical MAC address container. Through macvlan, communication before cross-host container can also be realized.

1. Create a macvlan network:

docker network create -d macvlan --subnet=172.16.86.0/24 --gateway=172.16.86.1 -o parent=eth0 macvlan1

2. Set the network card to promiscuous mode:

ip link set eth0 promisc on

3. Create a container using the macvlan network:

docker run -it --network macvlan1  --ip=172.16.86.2 busybox /bash

Container mode

Container mode, also known as Docker links, is a communication mechanism between Docker Containers. If a new container is linked to an existing container, the new container will obtain the link information of the existing container through environment variables. Communication between containers is realized by providing link information about existing containers to trusted containers.

The Container mode is similar to the host mode, except that the container created in the Container mode shares the IP and Port of other containers instead of the physical machine. In this mode, the container itself does not configure the network and port. After you create this mode, you will find it inside. The IP is the container IP you specified and the Port is also shared. Of course, others are isolated from each other, such as processes.

docker run -it --network container:<container ID>

none mode

In none mode, the Container will have its own Network Namespace, but it does not perform any network configuration for the Container. In other words, this Container will not have information such as network card, IP, routing, etc. You need to manually add network cards and configure IP for the Container. Containers using this type of network will be completely isolated.

After using the none mode, the container is closed and will not participate in network communication, so that the security of the container can be guaranteed.

$ docker run -itd --network none --name box3 busybox

$ docker exec -it box3 sh

/ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever

Overlay mode

Overlay mode is used in Swarm clusters to connect cross-host Docker Containers, allowing containers on different hosts to communicate with each other. Overlay mode adds a layer of virtual network between the Docker cluster nodes. It has an independent virtual network segment. Therefore, the content sent by the Container will first be sent to the virtual subnet, and then the virtual subnet will be packaged as the host's real URL for delivery. .

# 初始化 manager node。
$ docker swarm init

# 添加 worker node 到 manager。
$ docker swarm join --token <token> <manager_host>:2377

# 新建一个 Overlay 网络
$ docker network create --driver=overlay --attachable overlay

# 分别在不同的 worker node 上启动一个 busybox 容器，并连接到 Overlay 网络
$ docker run -it --network overlay --name box4 sh

In this way, cross-host Containers on the same Overlay network can communicate with each other.

Based on Swarm, we can also manage Containers cluster services. For example, create an Nginx Cluster with five copies connected to the Overlay network, and the exposed port is 80:

$ docker service create --name my-nginx --publish target=80,published=80 --replicas=5 --network overlay nginx

In this Nginx Cluster, if any node ends a copy, the cluster service will restart a new copy to keep the number of Nginx copies in all Worker Nodes to five.

Container port mapping

Core options:

• -p Host port: Map the application listening port in the container to a specific port on the physical host.

Example:

• Custom mapping:

docker run -d -p 8888:80  nginx:latest 

• Random mapping

# 需要镜像支持
docker run -P