浅聊几种主流Docker网络的实现原理

#!/bin/bash

NAMESPACE=$1

if [[-z $NAMESPACE ]]; 


    
then
    ls -1 /var/run/docker/netns/
    exit 0
fi

NAMESPACE_FILE=/var/run/docker/netns/${NAMESPACE}

if [[ ! -f $NAMESPACE_FILE ]]; then
    NAMESPACE_FILE=$(docker inspect -f "{{.NetworkSettings.SandboxKey}}"


    
 $NAMESPACE 2>/dev/null)
fi

if [[ ! -f $NAMESPACE_FILE ]]; then
    echo "Cannot open network namespace '$NAMESPACE': No such file or directory"
    exit 1
fi
shift

if [[ $# -lt 1 ]]; then
    echo "No command specified"
    exit 1



    
fi
nsenter --net=${NAMESPACE_FILE} $@

# ./docker_netns.sh # list namespaces
4-a4a048ac67
abe31dbbc394
default

# ./docker_netns.sh busybox ip addr # Enter busybox namespace
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 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
354: eth0@if355: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default



    
    link/ether 02:42:c0:a8:64:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet
192.168.100.2/24 brd 192.168.100.255 scope global eth0
       valid_lft forever preferred_lft forever

356: eth1@if357: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 


    
1500 qdisc noqueue state UP group default
    link/ether 02:42:ac:12:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 1
    inet 172.18.0.2/16 brd 172.18.255.255 scope global eth1
       valid_lft forever preferred_lft forever

#!/bin/bash




    
DOCKER_NETNS_SCRIPT=./docker_netns.sh
IFINDEX=$1

if [[ -z $IFINDEX ]]; then
    for namespace in $($DOCKER_NETNS_SCRIPT); do
        printf "\e[1;31m%s: \e[0m\n" $namespace
        $DOCKER_NETNS_SCRIPT $namespace ip -c -o link
        printf "\n"
    done
else



    
    for namespace in $($DOCKER_NETNS_SCRIPT); do
        if $DOCKER_NETNS_SCRIPT $namespace ip -c -o link | grep -Pq
 "^$IFINDEX: "; then
            printf "\e[1;31m%s: \e[0m\n" $namespace
            $DOCKER_NETNS_SCRIPT $namespace ip -c -o link | grep -P "^$IFINDEX: ";
            printf "\n"
        fi



    
    done
fi

# ./find_links.sh 354
abe31dbbc394:
354: eth0@if355: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP mode DEFAULT group default
     link/ether 02:42:c0:a8:64:02 brd ff:ff:ff


    
:ff:ff:ff link-netnsid 0

docker network create -d overlay --subnet 10.20.0.0


    
/16 overlay

docker run -d --name busybox --net overlay busybox sleep 36000

我们发现容器有两个IP，其中eth0 10.20.0.0/16为我们创建的Overlay网络ip，两个容器能够互相ping通。而不在同一个Node的容器IP eth1都是172.18.0.2，因此172.18.0.0/16很显然不能用于跨主机通信，只能用于单个节点容器通信。

2.2 容器南北流量

这里的南北流量主要是指容器与外部通信的流量，比如容器访问互联网。

我们查看容器的路由：

# docker exec busybox-node-1 ip r



    
default via 172.18.0.1 dev eth1
10.20.0.0/16 dev eth0 scope link  src 10.20.0.3
172.18.0.0/16 dev eth1 scope link  src 172.18.0.2

# docker exec busybox-node-1 ip link show eth1
77: eth1@if78: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue



    
    link/ether 02:42:ac:12:00:02 brd ff:ff:ff:ff:ff:ff
# ./find_links.sh 78
default:78: vethf2de5d4@if77: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker_gwbridge state UP mode DEFAULT
group default
link/ether 2e:6a:94:6a


    
:09:c5 brd ff:ff:ff:ff:ff:ff link-netnsid 1

# brctl show
bridge name     bridge id               STP enabled     interfaces
docker0         8000.02427406ba1a       no
docker_gwbridge         8000.0242bb868ca3       no              vethf2de5d4

# iptables-save -t nat  | grep -- '-A POSTROUTING'



    
-A POSTROUTING -s 172.18.0.0/16 ! -o docker_gwbridge -j MASQUERADE

# docker exec busybox-node-1 ip link show eth0
75: eth0@if76: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1450 qdisc noqueue
    link


    
/ether 02:42:0a:14:00:03 brd ff:ff:ff:ff:ff:ff
# ./find_links.sh 76
1-19c5d1a7ef:
76: veth0@if75: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master br0 state UP mode DEFAULT group default \    link/ether 6a:ce:89:a2:89


    
:4a brd ff:ff:ff:ff:ff:ff link-netnsid 1

# ./docker_netns.sh 1-19c5d1a7ef ip link show veth0
76: veth0@if75: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master br0 state UP mode DEFAULT group default
    link/ether 6a:ce:89:a2:89


    
:4a brd ff:ff:ff:ff:ff:ff link-netnsid 1

 # ./docker_netns.sh 1-19c5d1a7ef brctl show
bridge name     bridge id               STP enabled     interfaces

br0             8000.6ace89a2894a       no              veth0

                                                     vxlan0

./docker_netns.sh 1-19c5d1a7ef ip -c -d link show vxlan0
74: vxlan0:


    
 <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master br0 state UNKNOWN mode DEFAULT
group default
    link/ether 96:9d:64:39:76:4e brd ff:ff:ff:ff:ff:ff link-netnsid 0 promiscuity 1
    vxlan id 256 srcport 0 0 dstport 4789 proxy l2miss l3miss ttl inherit ageing 300 udpcsum noudp6zerocsumtx noudp6zerocsumrx
...


    

vxlan0是一个VXLAN虚拟网络设备，因此可以推断Docker Overlay是通过VXLAN隧道实现跨主机通信的。这里直接引用Deep dive into docker overlay networks part 1的图：

图中192.168.0.0/16对应前面的10.20.0.0/16网段。

2.4 ARP代理

如前面所述，跨主机的两个容器虽然是通过Overlay通信的，但容器自己却不知道，他们只认为彼此都在一个二层中（同一个子网），或者说大二层。我们知道二层是通过MAC地址识别对方的，通过ARP协议广播学习获取IP与MAC地址转换。当然通过VXLAN隧道广播ARP包理论上也没有问题，问题是该方案将导致广播包过多，广播的成本会很大。

和OpenStack Neutron的L2 Population原理一样，Docker也是通过ARP代理+静态配置解决ARP广播问题。我们知道，虽然Linux底层除了通过自学习方式外无法知道目标IP的MAC地址是什么，但是应用却很容易获取这些信息，比如Neutron的数据库中就保存着Port信息，Port中就有IP和MAC地址。Docker也一样会把Endpoint信息保存到KV数据库中，如etcd：

有了这些数据完全可以实现通过静态配置的方式填充IP和MAC地址表（neigh表）替换使用ARP广播的方式。因此vxlan0还负责了本地容器的ARP代理：

./docker_netns.sh  2-19c5d1a7ef ip -d -o link show vxlan0 | grep proxy_arp

# ./docker_netns.sh 3-19c5d1a7ef ip neigh



    
10.20.0.3 dev vxlan0 lladdr 02:42:0a:14:00:03 PERMANENT
10.20.0.4 dev vxlan0 lladdr 02:42:0a:14:00:04 PERMANENT

./docker_netns.sh 3-19c5d1a7ef bridge fdb
...
02:42:0a:14:00:04 dev vxlan0 dst 192.168.1.245 link-netnsid 0 self permanent
02:42:0a:14:00


    
:03 dev vxlan0 dst 192.168.1.254 link-netnsid 0 self permanent
...

weave launch --ipalloc-range 172.111.222.0/24 192.168.1.68 192.168.



    
1.254 192.168.1.245

# node-1
docker run -d --name busybox-node-1 --net weave busybox sleep 3600
# node-2
docker run -d --name busybox-node-2 --net weave busybox sleep 3600
# node-3
docker run -d --name busybox-node-


    
3 --net weave busybox sleep 3600

在容器中我们相互ping：

从结果发现，Weave实现了跨主机容器通信，另外我们容器有两个虚拟网卡，一个是Docker原生的桥接网卡eth0，用于南北通信，另一个是Weave附加的虚拟网卡ethwe0，用于容器跨主机通信。

另外查看容器的路由：

# docker exec -t -i busybox-node-$NODE ip r
default via 172.18.0.1 dev eth0
172.18.0.0/16 dev eth0 scope link  src 172.18.0.2
172.111.222.0/24 dev ethwe0 scope link  src 172.111.222.128
224.0.0.0/


    
4 dev ethwe0 scope link

# ./find_links.sh 14
default:
14: vethwl816281577@if13: <BROADCAST,MULTICAST,UP,LOWER_UP>mtu
1376 qdisc noqueue
    master weave state UP mode DEFAULT group default
    link/ether de:12:50:59:f0:d9 brd ff


    
:ff:ff:ff:ff:ff link-netnsid 0

# brctl show weave
bridge name     bridge id               STP enabled     interfaces
weave           8000.d2939d07704b       no              vethwe-bridge

                                                       vethwl816281577

# ip link show vethwe-bridge
9: vethwe-bridge@vethwe-datapath: 


    
<BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1376 qdisc noqueue
    master weave state UP mode DEFAULT group default
    link/ether 0e:ee:97:bd:f6:25 brd ff:ff:ff:ff:ff:ff

# ip -d link show vethwe-datapath
8: vethwe-datapath@vethwe-bridge


    
: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1376 qdisc noqueue
    master datapath state UP mode DEFAULT group default
    link/ether f6:74:e9:0b:30:6d brd ff:ff:ff:ff:ff:ff promiscuity 1
    veth
    openvswitch_slave addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535

# ovs-vsctl show
96548648-a6df-4182-98da-541229ef7b63
    ovs_version: "2.9.2"

# ovs-dpctl show
system@datapath:
        lookups: hit:109 missed:1508 lost:3
        flows: 1



    
        masks: hit:1377 total:1 hit/pkt:0.85
        port 0: datapath (internal)
        port 1: vethwe-datapath
        port 2: vxlan-6784 (vxlan:packet_type=ptap)

    
# ip -d link show vxlan-6784
10: vxlan-6784: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65535 qdisc noqueue
    master datapath state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether d2:21:db:c1:9b:28 brd ff:ff:ff:ff:ff:ff promiscuity 1
    vxlan id 0 srcport 0


    
 0 dstport 6784 nolearning ttl inherit ageing 300 udpcsum noudp6zerocsumtx udp6zerocsumrx external
    openvswitch_slave addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535

最后Weave的网络流量图如下：

docker run -d --name busybox busybox:latest sleep 36000

# ./docker_netns.sh busybox ip -d -c  link
416: eth0@if417


    
: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8951 qdisc noqueue state UP mode DEFAULT group default
    link/ether 02:42:28:0f:2b:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0 promiscuity 0
    veth addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535

# ./find_links.sh 417
default:
417: veth1cfe340@if416: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 8951 qdisc noqueue master docker0 state UP mode DEFAULT group default
     link/ether 26:bd:de:86:21:78 brd ff:ff:ff:ff:ff:ff link-netnsid 0

# brctl show
bridge name     bridge id               STP enabled     interfaces
docker0         8000.0242d6f8613e       no              veth1cfe340
                                                       vethd1fae9d
docker_gwbridge         8000.024257f32054       no

# ip r
default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.68 metric 100



    
40.15.26.0/24 via 40.15.26.0 dev flannel.1 onlink
40.15.43.0/24 dev docker0 proto kernel scope link src 40.15.43.1
40.15.56.0/24 via 40.15.56.0 dev flannel.1 onlink
...

413: flannel.1: <BROADCAST


    
,MULTICAST,UP,LOWER_UP> mtu 8951 qdisc noqueue state UNKNOWN mode DEFAULT group default
    link/ether 0e:08:23:57:14:9a brd ff:ff:ff:ff:ff:ff promiscuity 0
    vxlan id 1 local 192.168.1.68 dev eth0 srcport 0 0 dstport 8472 nolearning ttl inherit ageing 300
    udpcsum noudp6zerocsumtx noudp6zerocsumrx addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536


    
 gso_max_segs 65535

bridge fdb | grep flannel.1
4e:55:ee:0a:90:38 dev flannel.1 dst 192.168.1.245 self permanent
da:17:1b:07:d3:70 dev flannel.1 dst 192.168.1.254


    
 self permanent

# for subnet in $(etcdctl ls /coreos.com/network/subnets); do etcdctl get $subnet;done
{"PublicIP":"192.168.1.68","BackendType":"vxlan","BackendData":{"VtepMAC":"0e:08:23:57:14:9a"}}
{"PublicIP":"192.168.1.254","BackendType":"vxlan","BackendData":{"VtepMAC":"da:17:1b:07:d3:70"}}
{"PublicIP":"192.168.1.245","BackendType":"vxlan","BackendData":{"VtepMAC":


    
"4e:55:ee:0a:90:38"}}

因此Flannel的Overlay网络实现原理简化如图：

可见除了增加或者减少Node，需要Flannel配合配置静态路由以及fdb表，容器的创建与删除完全不需要Flannel干预，事实上Flannel也不需要知道有没有新的容器创建或者删除。

4.3 Flannel host-gw网络

前面介绍Flannel通过VXLAN实现跨主机通信，其实Flannel支持不同的backend，其中指定backend type为host-gw支持通过静态路由的方式实现容器跨主机通信，这时每个Node都相当于一个路由器，作为容器的网关，负责容器的路由转发。

需要注意的是，如果使用AWS EC2，使用Flannel host-gw网络需要禁用MAC地址欺骗功能，如图：

使用OpenStack则最好禁用Neutron的port security功能。

同样地，我们在三个节点分别创建BusyBox容器，结果如下：

# ip r



    
default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.68 metric 100
40.15.26.0/24 via 192.168.1.254 dev eth0
40.15.43.0/24 dev docker0 proto kernel scope link src 40.15.43.1
40.15.56.0/24 via 192.168.1.245 dev eth0
...

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            


    
"Effect": "Allow",
            "Action": [
                "ec2:DescribeInstances",
                "ec2:CreateRoute",
                "ec2:DeleteRoute",
                "ec2:ModifyInstanceAttribute",
                "ec2:DescribeRouteTables",
                "ec2:ReplaceRoute"
            ],
            "Resource": "*"
        }



    
    ]
}

即EC2实例需要具有修改路由表等相关权限。

之前一直很疑惑AWS的role如何与EC2虚拟机关联起来的。换句话说，如何实现虚拟机无需配置Key和Secretd等认证信息就可以直接调用AWS API，通过awscli的 --debug信息可知awscli首先通过metadata获取role信息，再获取role的Key和Secret：

关于AWS如何知道调用metadata的是哪个EC2实例，可参考之前的文章OpenStack虚拟机如何获取metadata。

另外所有EC2实例均禁用了MAC地址欺骗功能（Change Source/Dest Check），安全组允许flannel网段40.15.0.0/16通过，另外增加了如下iptables规则：

iptables -I FORWARD --dest 40.15.0.0/16 -j ACCEPT
iptables -I FORWARD --src 40.15.0.0/16 -j ACCEPT

# etcdctl get /coreos.com/network/config | jq .
{
  "Network": "40.15.0.0/16",
  "Backend": {
    "Type": "aws-vpc"
  }
}

我们查看node-1、node-2、node-3关联的路由表如图：

node-4关联的路由表如图：

由此可见，每增加一个Flannel节点，Flannel就会调用AWS API在EC2实例的子网关联的路由表上增加一条记录，Destination为该节点分配的Flannel子网，Target为该EC2实例的主网卡。

在4个节点分别创建一个BusyBox容器，容器IP如下：

所有节点ping node-4的容器，如图：

我们发现所有节点都能ping通node-4的容器。但是node-4的容器却ping不通其余容器：

这是因为每个Node默认只会添加自己所在路由的记录。node-4没有node-1 ~ node-3的路由信息，因此不通。

可能有人会问，node1 ~ node3也没有node4的路由，那为什么能ping通node4的容器呢？这是因为我的环境中node1 ~ node3子网关联的路由是NAT网关，node4是Internet网关，而NAT网关的子网正好是node1 ~ node4关联的子网，因此node1 ~ node3虽然在自己所在的NAT网关路由没有找到node4的路由信息，但是下一跳到达Internet网关的路由表中找到了node4的路由，因此能够ping通，而node4找不到node1 ~ node3的路由，因此都ping不通。

以上只是默认行为，Flannel可以通过 RouteTableID参数配置Node需要更新的路由表，我们只需要增加如下两个子网的路由如下：

# etcdctl get  /coreos.com/network/config | jq .
{
  "Network": "40.15.0.0/16",
  "Backend": {
    "Type": "aws-vpc",
    "RouteTableID": [
      "rtb-0686cdc9012674692",



    
      "rtb-054dfd5f3e47102ae"
    ]
  }
}

重启Flannel服务，再次查看两个路由表：

我们发现两个路由表均添加了node1 ~ node4的Flannel子网路由。

此时四个节点的容器能够相互ping通。

从中我们发现，aws-vpc解决了host-gw不能跨子网的问题，Flannel官方也建议如果使用AWS，推荐使用aws-vpc替代overlay方式，能够获取更好的性能：

When running within an Amazon VPC, we recommend using the aws-vpc backend which, instead of using encapsulation, manipulates IP routes to achieve maximum performance. Because of this, a separate flannel interface is not created.

The biggest advantage of using flannel AWS-VPC backend is that the AWS knows about that IP. That makes it possible to set up ELB to route directly to that container.

另外，由于路由是添加到了主机网关上，因此只要关联了该路由表，EC2实例是可以从外面直接ping通容器的，换句话说，同一子网的EC2虚拟机可以直接与容器互通。

不过需要注意的是，AWS路由表默认最多支持50条路由规则，这限制了Flannel节点数量，不知道AWS是否支持增加配额功能。另外目前最新版的Flannel v0.10.0好像对aws-vpc支持有点问题，再官方修复如上问题之前建议使用Flannel v0.8.0版本。

# calicoctl  get ipPool -o yaml
- apiVersion: v1
  kind: ipPool
  metadata:
    cidr: 197.19.0.0/16
  spec:
    ipip:
      enabled: true



    
      mode: cross-subnet
    nat-outgoing: true
- apiVersion: v1
  kind: ipPool
  metadata:
    cidr: fd80:24e2:f998:72d6::/64
  spec: {}

for host 


    
in $(etcdctl --endpoints $ENDPOINTS ls /calico/ipam/v2/host/); do
    etcdctl --endpoints $ENDPOINTS ls  $host/ipv4/block | awk -F '/' '{sub(/-/,"/",$NF)}{print $6,$NF}'
done | sort

int32bit-docker-1 197.19.38.128/26
int32bit-docker-2 197.19.186.192/26



    
int32bit-docker-3 197.19.26.0/26

相互ping通没有问题。

5.2 Calico容器内部网络

我们查看容器的link设备以及路由：

# ./docker_netns.sh busybox ip a
1: lo


    
: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 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
2: tunl0@NONE: <NOARP


    
> mtu 1480 qdisc noop state DOWN group default qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0
14: cali0@if15: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether ee:ee:ee:ee:ee:ee brd ff:ff:ff:ff:ff:


    
ff link-netnsid 0
    inet 197.19.38.136/32 brd 197.19.38.136 scope global cali0
       valid_lft forever preferred_lft forever

 # ./docker_netns.sh busybox ip r
default via 169.254.1.1 dev cali0
169.254.1.1 dev cali0 scope link

有如下几点个人感觉很神奇：

• 所有容器的MAC地址都是ee:ee:ee:ee:ee:ee

• 网关地址是169.254.1.1，然而我找尽了所有的namespaces也没有找到这个IP。

这两个问题在Calico官方的faq中有记录#1 Why do all cali* interfaces have the MAC address ee:ee:ee:ee:ee:ee?、#2 Why can’t I see the 169.254.1.1 address mentioned above on my host?。

针对第一个问题，官方认为不是所有的内核都能支持自动分配MAC地址，所以干脆Calico自己指定MAC地址，而Calico完全使用三层路由通信，MAC地址是什么其实无所谓，因此直接都使用ee:ee:ee:ee:ee:ee。

第二个问题，回顾之前的网络模型，大多数都是把容器的网卡通过VETH连接到一个bridge设备上，而这个bridge设备往往也是容器网关，相当于主机上多了一个虚拟网卡配置。Calico认为容器网络不应该影响主机网络，因此容器的网卡的VETH另一端没有经过bridge直接挂在默认的namespace中。而容器配的网关其实也是假的，通过proxy_arp修改MAC地址模拟了网关的行为，所以网关IP是什么也无所谓，那就直接选择了local link的一个IP，这还节省了容器网络的一个IP。我们可以抓包看到ARP包：

可以看到容器网卡的对端calia2656637189直接代理回复了ARP，因此出去网关时容器的包会直接把MAC地址修改为 06:66:26:8e:b2:67，即伪网关的MAC地址。

有人可能会说那如果在同一主机的容器通信呢？他们应该在同一个子网，容器的MAC地址都是一样那怎么进行二层通信呢？仔细看容器配置的IP掩码居然是32位的，那也就是说跟谁都不在一个子网了，也就不存在二层的链路层直接通信了。

5.3 Calico主机路由

前面提到Calico通过BGP动态路由实现跨主机通信，我们查看主机路由如下，其中197.19.38.139、197.19.38.140是在本机上的两个容器IP：

# ip r | grep 197.19
197.19.26.0/26 via 192.168.1.245 dev eth0 proto bird
blackhole 197.19.38.128/26 proto bird
197.19.38.139 dev calia2656637189 scope link
197.19.38.140 dev calie889861df72 scope link
197.19.186.192


    
/26 via 192.168.1.254 dev eth0 proto bird

# docker network ls | grep calico
ad7ca8babf01        calico-net-1        calico              global
5eaf3984f69d        calico-net-2        calico              global

docker run -d --name busybox-


    
3 --net calico-net-2 busybox sleep 36000
# docker exec busybox-3 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
2: tunl0@NONE: <NOARP> mtu 1480 qdisc noop qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0
24: cali0@if25: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue
    link/ether ee:ee:ee:ee


    
:ee:ee brd ff:ff:ff:ff:ff:ff
    inet 197.19.38.141/32 brd 197.19.38.141 scope global cali0
       valid_lft forever preferred_lft forever

# ip r | grep 197.19
197.19.26.0/26 via 192.168.1.245 dev eth0 proto bird
blackhole 197.19.38.128/26 proto bird
197.19.38.139 dev calia2656637189 scope link



    
197.19.38.140 dev calie889861df72 scope link
197.19.38.141 dev calib12b038e611 scope link
197.19.186.192/26 via 192.168.1.254 dev eth0 proto bird

我们发现在同一个主机不在同一个网络的容器IP地址在同一个子网，那不是可以通信呢？

我们发现虽然两个跨网络的容器分配的IP在同一个子网，但居然实现了隔离。

如果使用诸如VXLAN的Overlay网络，很好猜测是怎么实现隔离的，无非就是使用不同的VNI。但Calico没有使用Overlay，直接使用路由通信，而且不同网络的子网还是重叠的，它是怎么实现隔离的呢。

要在同一个子网实现隔离，我们猜测实现方式只能是逻辑隔离，即通过本地防火墙如iptables实现。

查看了下Calico生成的iptables规则发现太复杂了，各种包mark。由于决定包的放行或者丢弃通常是在filter表实现，而不是发往主机的自己的包应该在FORWARD链中，因此我们直接研究filter表的FORWARD表。

# iptables-save -t filter | grep -- '-A FORWARD'
-AFORWARD -m comment --comment "cali:wUHhoiAYhphO9Mso"


    
 -j cali-FORWARD
...

# iptables-save -t filter | grep -- '-A cali-FORWARD'
-A cali-FORWARD -i cali+ -m comment --comment "cali:X3vB2lGcBrfkYquC" -j cali-from-wl-dispatch
-A cali-FORWARD -o cali+ -m comment --comment "cali:UtJ9FnhBnFbyQMvU" -j cali-to-wl


    
-dispatch
-A cali-FORWARD -i cali+ -m comment --comment "cali:Tt19HcSdA5YIGSsw" -j ACCEPT
-A cali-FORWARD -o cali+ -m comment --comment "cali:9LzfFCvnpC5_MYXm" -j ACCEPT
...

# iptables-save -t filter | grep -- '-A cali-to-wl-dispatch'
-A cali-to-wl-dispatch -


    
o calia2656637189 -m comment --comment "cali:TFwr8sfMnFH3BUla" -g cali-tw-calia2656637189
-A cali-to-wl-dispatch -o calib12b038e611 -m comment --comment "cali:ZbRb0ozg-GGeUfRA" -g cali-tw-calib12b038e611
-A cali-to-wl-dispatch -o calie889861df72 -m comment --comment "cali:5OoGv50NzX0sKdMg" -g cali-tw-calie889861df72
-A cali-to


    
-wl-dispatch -m comment --comment "cali:RvicCiwAy9cIEAKA" -m comment --comment "Unknown interface" -j DROP

# iptables-save -t filter | grep -- '-A cali-tw-calia2656637189'
-A cali-tw-calia2656637189 -m comment --comment "cali:259EHpBvnovN8_q6" -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A cali-tw-calia2656637189 -m comment 


    
--comment "cali:YLokMEiVkZggfg9R" -m conntrack --ctstate INVALID -j DROP
-A cali-tw-calia2656637189 -m comment --comment "cali:pp8a6fGxqaALtRK5" -j MARK --set-xmark 0x0/0x1000000
-A cali-tw-calia2656637189 -m comment --comment "cali:bgw2sCtlIfZjhXLA" -j cali-pri-calico-net-1
-A cali-tw-calia2656637189 -m comment 


    
--comment "cali:1Z2NvhoS27pP03Ll" -m comment --comment "Return if profile accepted" -m mark --mark 0x1000000/0x1000000 -j RETURN
-A cali-tw-calia2656637189 -m comment --comment "cali:mPb8hORsTXeVt7yC" -m comment --comment "Drop if no profiles matched" -j DROP

# iptables-save -t filter | grep -- '-A cali-pri-calico-net-1'
-A cali-pri-calico-net-1 -m comment --comment "cali:Gvse2HBGxQ9omCdo" -m set --match-set cali4-s:VFoIKKR-LOG_UuTlYqcKubo src -j MARK --set-xmark 0x1000000/0x1000000
-A cali-pri-calico-net-1 -m comment --comment 


    
"cali:0vZpvvDd_5bT7g_k" -m mark --mark 0x1000000/0x1000000 -j RETURN

# ipset list cali4-s:VFoIKKR-LOG_UuTlYqcKubo
Name: cali4-s:VFoIKKR-LOG_UuTlYqcKubo
Type: hash:ip
Revision: 4
Header: family inet hashsize 1024 maxelem 1048576
Size in memory: 


    
280
References: 1
Number of entries: 4
Members:
197.19.38.143
197.19.26.7
197.19.186.199
197.19.38.144

docker run 


    
-d --name busybox-node-4 --net calico-net-1 busybox sleep 36000
docker exec busybox-node-4 ping -c 1 -w 1 197.19.38.144
PING 197.19.38.144 (197.19.38.144): 56 data bytes
64 bytes from 197.19.38.144: seq=0 ttl=


    
62 time=0.539 ms

--- 197.19.38.144 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.539/0.539/0.539 ms

# ip r | grep 197.19
197.19.26.0/


    
26 via 192.168.1.245 dev eth0 proto bird
blackhole 197.19.38.128/26 proto bird
197.19.38.142 dev cali459cc263d36 scope link
197.19.38.143 dev cali6d0015b0c71 scope link
197.19.38.144 dev calic8e5fab61b1 scope link
197.19.65.128/26 via 192.168.0.33 dev tunl0 proto bird onlink
197.19.186.192/26 via 192.168.1.254 dev eth0 proto bird

# ip -d link show tunl0
5: tunl0@NONE: <NOARP,UP,LOWER_UP> mtu 1440 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0 promiscuity 0
    ipip any remote any local any ttl inherit nopmtudisc addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
# ip -d tunnel show
 tunl0: any/


    
ip remote any local any ttl inherit nopmtudisc

    vm               Container        whatever
    |                    |                |
   tapX                tapY             tapZ
    |                    |                |



    
    |                    |                |
  qbrX                 qbrY             qbrZ
    |                    |                |
 ---------------------------------------------
    |               br-int(OVS)           |
 ---------------------------------------------
                         |                  
 ----------------------------------------------
    |               br-tun(OVS)           


    
|    
 ----------------------------------------------

基于Kubernetes的DevOps战培训将于2019年9月27日在上海开课，3天时间带你系统掌握Kubernetes，学习效果不好可以继续学习。本次培训包括：容器特性、镜像、网络；Kubernetes架构、核心组件、基本功能；Kubernetes设计理念、架构设计、基本功能、常用对象、设计原则；Kubernetes的数据库、运行时、网络、插件已经落地经验；微服务架构、组件、监控方案等，点击下方图片或者阅读原文链接查看详情。