萬字長文：聊聊幾種主流Docker網路的實現原理

一、容器網路簡介

容器網路主要解決兩大核心問題：一是容器的IP地址分配，二是容器之間的相互通訊。本文重在研究第二個問題並且主要研究容器的跨主機通訊問題。

實現容器跨主機通訊的最簡單方式就是直接使用host網路，這時由於容器IP就是宿主機的IP，複用宿主機的網路協議棧以及underlay網路，原來的主機能通訊，容器也就自然能通訊，然而帶來的最直接問題就是埠衝突問題。

因此通常容器會配置與宿主機不一樣的屬於自己的IP地址。由於是容器自己配置的IP，underlay平面的底層網路裝置如交換機、路由器等完全不感知這些IP的存在，也就導致容器的IP不能直接路由出去實現跨主機通訊。

要解決如上問題實現容器跨主機通訊，主要有如下兩個思路：

• 思路一：修改底層網路裝置配置，加入容器網路IP地址的管理，修改路由器閘道器等，該方式主要和SDN結合。

• 思路二：完全不修改底層網路裝置配置，複用原有的underlay平面網路，解決容器跨主機通訊，主要有如下兩種方式：

• Overlay隧道傳輸。把容器的資料包封裝到原主機網路的三層或者四層資料包中，然後使用原來的網路使用IP或者TCP/UDP傳輸到目標主機，目標主機再拆包轉發給容器。Overlay隧道如Vxlan、ipip等，目前使用Overlay技術的主流容器網路如Flannel、Weave等。

• 修改主機路由。把容器網路加到主機路由表中，把主機當作容器閘道器，透過路由規則轉發到指定的主機，實現容器的三層互通。目前透過路由技術實現容器跨主機通訊的網路如Flannel host-gw、Calico等。

本文接下來將詳細介紹目前主流容器網路的實現原理。

在開始正文內容之前，先引入兩個後續會一直使用的指令碼：

第一個指令碼為 docker_netns.sh：

#!/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} $@

該指令碼透過指定容器id、name或者namespace快速進入容器的network namespace並執行相應的shell命令。

如果不指定任何引數，則列舉所有Docker容器相關的network namespaces。

# ./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

另一個指令碼為 find_links.sh：

#!/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
" $namespace
        $DOCKER_NETNS_SCRIPT $namespace ip -c -o link
        printf "
"
    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
" $namespace
            $DOCKER_NETNS_SCRIPT $namespace ip -c -o link | grep -P "^$IFINDEX: ";
            printf "
"
        fi
    done
fi

該指令碼根據ifindex查詢虛擬網路裝置所在的namespace:

# ./find_links.sh 354abe31dbbc394: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

該指令碼的目的是方便查詢veth的對端所在的namespace位置。如果不指定ifindex，則列出所有namespaces的link裝置。

二、Docker原生的Overlay

Laurent Bernaille在DockerCon2017上詳細介紹了Docker原生的Overlay網路實現原理，作者還總結了三篇乾貨文章一步一步剖析Docker網路實現原理，最後還教大家一步一步從頭開始手動實現Docker的Overlay網路，這三篇文章為:

• Deep dive into docker overlay networks part 1

• Deep dive into docker overlay networks part 2

• Deep dive into docker overlay networks part 3

建議感興趣的讀者閱讀，本節也大量參考瞭如上三篇文章的內容。

2.1 Overlay網路環境

測試使用兩個Node節點：

首先建立一個overlay網路:

docker network create -d overlay --subnet 10.20.0.0/16 overlay

在兩個節點分別建立兩個busybox容器:

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 rdefault via 172.18.0.1 dev eth110.20.0.0/16 dev eth0 scope link  src 10.20.0.3172.18.0.0/16 dev eth1 scope link  src 172.18.0.2

由此可知容器預設閘道器為172.18.0.1，也就是說容器是透過eth1出去的：

# docker exec busybox-node-1 ip link show eth177: 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 78default:78: vethf2de5d4@if77: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker_gwbridge state UP mode DEFAULT group defaultlink/ether 2e:6a:94:6a:09:c5 brd ff:ff:ff:ff:ff:ff link-netnsid 1

透過 find_links.sh指令碼查詢ifindex為78的link在預設namespace中，並且該link的master為 docker_gwbridge，也就是說該裝置掛到了 docker_gwbridgebridge。

# brctl showbridge name     bridge id               STP enabled     interfacesdocker0         8000.02427406ba1a       nodocker_gwbridge         8000.0242bb868ca3       no              vethf2de5d4

而 172.18.0.1正是bridge docker_gwbridge的IP，也就是說 docker_gwbridge是該節點的所有容器的閘道器。

由於容器的IP是172.18.0.0/16私有IP地址段，不能出公網，因此必然透過NAT實現容器IP與主機IP地址轉換，檢視iptables nat表如下：

# iptables-save -t nat  | grep -- '-A POSTROUTING'-A POSTROUTING -s 172.18.0.0/16 ! -o docker_gwbridge -j MASQUERADE

由此可驗證容器是透過NAT出去的。

我們發現其實容器南北流量用的其實就是Docker最原生的bridge網路模型，只是把 docker0換成了 docker_gwbridge。如果容器不需要出網際網路，建立Overlay網路時可以指定 --internal引數，此時容器只有一個Overlay網路的網路卡，不會建立eth1。

2.3 容器東西向流量

容器東西流量指容器之間的通訊，這裡特指跨主機的容器間通訊。

顯然容器是透過eth0實現與其他容器通訊的：

# 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

eth0的對端裝置ifindex為76，透過 find_links.sh指令碼查詢ifindex 76在 1-19c5d1a7ef namespace下，名稱為 veth0，並且master為br0，因此veth0掛到了br0 bridge下。

透過 docker_netns.sh指令碼可以快速進入指定的namespace執行命令：

# ./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

可見除了veth0，bridge還繫結了vxlan0：

./docker_netns.sh 1-19c5d1a7ef ip -c -d link show vxlan074: 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

而vxlan0代理回覆時直接查詢本地的neigh表回覆即可，而本地neigh表則是Docker靜態配置，可檢視Overlay網路namespaced neigh表：

# ./docker_netns.sh 3-19c5d1a7ef ip neigh10.20.0.3 dev vxlan0 lladdr 02:42:0a:14:00:03 PERMANENT10.20.0.4 dev vxlan0 lladdr 02:42:0a:14:00:04 PERMANENT

記錄中的 PERMANENT說明是靜態配置而不是透過學習獲取的，IP 10.20.0.3、10.20.0.4正是另外兩個容器的IP地址。

每當有新的容器建立時，Docker透過Serf以及Gossip協議通知節點更新本地neigh ARP表。

2.5 VTEP表靜態配置

前面介紹的ARP代理屬於L2層問題，而容器的資料包最終還是透過Vxlan隧道傳輸的，那自然需要解決的問題是這個資料包應該傳輸到哪個node節點？如果只是兩個節點，建立vxlan隧道時可以指定本地ip（local IP)和對端IP(remote IP)建立點對點通訊，但實際上顯然不可能只有兩個節點。

我們不妨把Vxlan出去的物理網路卡稱為VTEP（VXLAN Tunnel Endpoint），它會有一個可路由的IP，即Vxlan最終封裝後的外層IP。透過查詢VTEP表決定資料包應該傳輸到哪個remote VTEP：

VTEP表和ARP表類似，也可以透過廣播洪泛的方式學習，但顯然同樣存在效能問題，實際上也很少使用這種方案。在硬體SDN中通常使用BGP EVPN技術實現Vxlan的控制平面。

而Docker解決的辦法和ARP類似，透過靜態配置的方式填充VTEP表，我們可以檢視容器網路namespace的轉發表(Forward database，簡稱fdb)，

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

可見MAC地址02:42:0a:14:00:04的對端VTEP地址為192.168.1.245,而02:42:0a:14:00:03的對端VTEP地址為192.168.1.254,兩條記錄都是 permanent，即靜態配置的，而這些資料來源依然是KV資料庫，endpoint中 locator即為容器的node IP。

2.6 總結

容器使用Docker原生Overlay網路預設會建立兩張虛擬網路卡，其中一張網路卡透過bridge以及NAT出容器外部，即負責南北流量。另一張網路卡透過Vxlan實現跨主機容器通訊，為了減少廣播，Docker透過讀取KV資料靜態配置ARP表和FDB表，容器建立或者刪除等事件會透過Serf以及Gossip協議通知Node更新ARP表和FDB表。

三、和Docker Overlay差不多的Weave

weave是weaveworks公司提供的容器網路方案，實現上和Docker原生Overlay網路有點類似。

初始化三個節點192.168.1.68、192.168.1.254、192.168.1.245如下：

weave launch --ipalloc-range 172.111.222.0/24 192.168.1.68 192.168.1.254 192.168.1.245

分別在三個節點啟動容器：

# node-1docker run -d --name busybox-node-1 --net weave busybox sleep 3600# node-2docker run -d --name busybox-node-2 --net weave busybox sleep 3600# node-3docker 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 rdefault via 172.18.0.1 dev eth0172.18.0.0/16 dev eth0 scope link  src 172.18.0.2172.111.222.0/24 dev ethwe0 scope link  src 172.111.222.128224.0.0.0/4 dev ethwe0 scope link

其中 224.0.0.0/4是一個組播地址，可見Weave是支援組播的，參考Container Multicast Networking: Docker & Kubernetes | Weaveworks.

我們只看第一個容器的ethwe0，VETH對端ifindex為14：

# ./find_links.sh 14default: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

可見ethwe0的對端在default namespace下，名稱為 vethwl816281577，該虛擬網路卡橋接到 weave bridge下：

# brctl show weavebridge name     bridge id               STP enabled     interfacesweave           8000.d2939d07704b       no              vethwe-bridge                                                        vethwl816281577

weave bridge下除了有 vethwl816281577，還有 vethwe-bridge:

# ip link show vethwe-bridge9: 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

可見 vethwe-bridge與 vethwe-datapath是一個VETH對，我們檢視對端 vethwe-datapath：

# ip -d link show vethwe-datapath8: 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

vethwe-datapath的master為 datapath，由 openvswitch_slave可知 datapath應該是一個openvswitch bridge，而 vethwe-datapath掛到了 datapath橋下，作為 datapath的port。

為了驗證，透過ovs-vsctl檢視：

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

使用 ovs-vsctl發現並沒有 datapath這個橋。官方文件中fastdp how it works中解釋為了提高網路效能，沒有使用使用者態的OVS，而是直接操縱核心的datapath。使用 ovs-dpctl命令可以檢視核心datapath：

# ovs-dpctl showsystem@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)

可見datapath類似於一個OVS bridge裝置，負責資料交換，該裝置包含三個port：

• port 0: datapath (internal)

• port 1: vethwe-datapath

• port 2: vxlan-6784

除了 vethwe-datapath，還有一個 vxlan-6784，由名字可知這是一個vxlan：

# ip -d link show vxlan-678410: 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的網路流量圖如下：

四、簡單優雅的Flannel

4.1 Flannel簡介

Flannel網路是目前最主流的容器網路之一，同時支援overlay（如vxlan）和路由(如host-gw）兩種模式。

Flannel和Weave以及Docker原生overlay網路不同的是，後者的所有Node節點共享一個子網，而Flannel初始化時通常指定一個16位的網路，然後每個Node單獨分配一個獨立的24位子網。由於Node都在不同的子網，跨節點通訊本質為三層通訊，也就不存在二層的ARP廣播問題了。

另外，我認為Flannel之所以被認為非常簡單優雅的是，不像Weave以及Docker Overlay網路需要在容器內部再增加一個網路卡專門用於Overlay網路的通訊，Flannel使用的就是Docker最原生的bridge網路，除了需要為每個Node配置subnet(bip)外，幾乎不改變原有的Docker網路模型。

4.2 Flannel Overlay網路

我們首先以Flannel Overlay網路模型為例，三個節點的IP以及Flannel分配的子網如下：

在三個整合了Flannel網路的Node環境下分別建立一個 busybox容器：

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

容器列表如下：

檢視容器namespace的網路裝置：

# ./docker_netns.sh busybox ip -d -c  link416: 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

和Docker bridge網路一樣只有一張網路卡eth0，eth0為veth裝置，對端的ifindex為417.

我們查詢下ifindex 417的link資訊：

# ./find_links.sh 417default: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

可見ifindex 417在default namespace下，名稱為 veth1cfe340並且master為docker0，因此掛到了docker0的bridge下。

# brctl showbridge name     bridge id               STP enabled     interfacesdocker0         8000.0242d6f8613e       no              veth1cfe340                                                        vethd1fae9ddocker_gwbridge         8000.024257f32054       no

和Docker原生的bridge網路沒什麼區別，那它是怎麼解決跨主機通訊的呢？

實現跨主機通訊，要麼Overlay隧道封裝，要麼靜態路由，顯然docker0沒有看出有什麼overlay的痕跡，因此只能透過路由實現了。

不妨檢視下本地路由如下：

# ip rdefault via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.68 metric 10040.15.26.0/24 via 40.15.26.0 dev flannel.1 onlink40.15.43.0/24 dev docker0 proto kernel scope link src 40.15.43.140.15.56.0/24 via 40.15.56.0 dev flannel.1 onlink...

我們只關心40.15開頭的路由，忽略其他路由，我們發現除了40.15.43.0/24直接透過docker0直連外，其他均路由轉發到了 flannel.1。而40.15.43.0/24為本地Node的子網，因此在同一宿主機的容器直接透過docker0通訊即可。

我們檢視 flannel.1的裝置型別：

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

可見 flannel.1是一個Linux Vxlan裝置，其中 .1為VNI值，不指定預設為1。

由於不涉及ARP因此不需要proxy引數實現ARP代理，而本節點的容器通訊由於在一個子網內，因此直接ARP自己學習即可，不需要Vxlan裝置學習，因此有個nolearning引數。

而 flannel.1如何知道對端VTEP地址呢？我們依然檢視下轉發表fdb：

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

其中192.168.1.245、192.168.1.254正好是另外兩個Node的IP，即VTEP地址，而 4e:55:ee:0a:90:38以及 da:17:1b:07:d3:70為對端的 flannel.1裝置的MAC地址，由於是 permanent表，因此可推測是由flannel靜態新增的，而這些資訊顯然可以從etcd獲取：

# 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容器，結果如下：

我們檢視192.168.1.68的本地路由：

# ip rdefault via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.68 metric 10040.15.26.0/24 via 192.168.1.254 dev eth040.15.43.0/24 dev docker0 proto kernel scope link src 40.15.43.140.15.56.0/24 via 192.168.1.245 dev eth0...

我們只關心40.15字首的路由，發現40.15.26.0/24的下一跳為192.168.1.254，正好為node2 IP，而40.15.43.0/24的下一跳為本地docker0，因為該子網就是node所在的子網，40.15.56.0/24的下一跳為192.168.1.245，正好是node3 IP。可見，Flannel透過配置靜態路由的方式實現容器跨主機通訊，每個Node都作為路由器使用。

host-gw的方式相對Overlay由於沒有vxlan的封包拆包過程，直接路由就過去了，因此效能相對要好。不過正是由於它是透過路由的方式實現，每個Node相當於是容器的閘道器，因此每個Node必須在同一個LAN子網內，否則跨子網由於鏈路層不通導致無法實現路由導致host-gw實現不了。

4.4 Flannel利用雲平臺路由實現跨主機通訊

前面介紹的host-gw是透過修改主機路由表實現容器跨主機通訊，如果能修改主機閘道器的路由當然也是沒有問題的，尤其是和SDN結合方式動態修改路由。

目前很多雲平臺均實現了自定義路由表的功能，比如OpenStack、AWS等，Flannel藉助這些功能實現了很多公有云的VPC後端，透過直接呼叫雲平臺API修改路由表實現容器跨主機通訊，比如阿里雲、AWS、Google雲等，不過很可惜官方目前好像還沒有實現OpenStack Neutron後端。

下面以AWS為例，建立瞭如下4臺EC2虛擬機器：

• node-1: 197.168.1.68/24

• node-2: 197.168.1.254/24

• node-3: 197.168.1.245/24

• node-4: 197.168.0.33/24

注意第三臺和其餘兩臺不在同一個子網。

三臺EC2均關聯了flannel-role，flannel-role關聯了flannel-policy，policy的許可權如下：

{    "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 ACCEPTiptables -I FORWARD --src 40.15.0.0/16 -j ACCEPT

flannel配置如下：

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

啟動flannel，自動為每個Node分配24位子網，網段如下：

我們檢視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版本。

五、黑科技最多的Calico

5.1 Calico環境配置

Calico和Flannel host-gw類似都是透過路由實現跨主機通訊,區別在於Flannel透過flanneld程式逐一新增主機靜態路由實現，而Calico則是透過BGP實現節點間路由規則的相互學習廣播。

這裡不詳細介紹BGP的實現原理，僅研究容器是如何通訊的。

建立了3個節點的calico叢集，ip pool配置如下：

# 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: {}

Calico分配的ip如下：

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

由此可知，Calico和Flannel一樣，每個節點分配一個子網，只不過Flannel預設分24位子網，而Calico分的是26位子網。

三個節點分別建立busybox容器：

相互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.19197.19.26.0/26 via 192.168.1.245 dev eth0 proto birdblackhole 197.19.38.128/26 proto bird197.19.38.139 dev calia2656637189 scope link197.19.38.140 dev calie889861df72 scope link197.19.186.192/26 via 192.168.1.254 dev eth0 proto bird

我們發現跨主機通訊和Flannel host-gw完全一樣，下一跳直接指向hostIP，把host當作容器的閘道器。不一樣的是到達宿主機後，Flannel會透過路由轉發流量到bridge裝置中，再由bridge轉發給容器，而Calico則為每個容器的IP生成一條明細路由，直接指向容器的網路卡對端。因此如果容器數量很多的話，主機路由規則數量也會越來越多，因此才有了路由反射，這裡不過多介紹。

裡面還有一條blackhole路由，如果來的IP是在host分配的容器子網197.19.38.128/26中，而又不是容器的IP，則認為是非法地址，直接丟棄。

5.4 Calico多網路支援

在同一個叢集上可以同時建立多個Calico網路：

# docker network ls | grep calicoad7ca8babf01        calico-net-1        calico              global5eaf3984f69d        calico-net-2        calico              global

我們使用另一個Calico網路calico-net-2建立一個容器：

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'-A FORWARD -m comment --comment "cali:wUHhoiAYhphO9Mso" -j cali-FORWARD...

Calico把cali-FORWARD子鏈掛在了FORWARD鏈上，comment中的一串看起來像隨機字串 cali:wUHhoiAYhphO9Mso不知道是幹嘛的。

# 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...

cali+表示所有以cali為字首的網路介面，即容器的網路卡對端裝置。由於我們只關心發往容器的流量方向，即從caliXXX發往容器的流量，因此我們只關心條件匹配的 -o cali+的規則，從如上可以看出所有從 cali+出來的流量都跳轉到了 cali-to-wl-dispatch子鏈處理，其中 wl是workload的縮寫，workload即容器。

# 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

從子鏈名字也可以看出 cali-to-wl-dispatch是負責流量的分發的，即根據具體的流量出口引到具體的處理流程子鏈，從X出來的，由cali-tw-X處理，從Y出來的，由cali-tw-Y處理，依次類推，其中 tw為 to workload的簡寫。

我們假設是發往busybox 197.19.38.139這個容器的，對應的主機虛擬裝置為 calia2656637189，則跳轉子鏈為 cali-tw-calia2656637189：

# 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

其中第1、2條規則在深入淺出OpenStack安全組實現原理中介紹過，不再贅述。

第三條規則注意使用的是 set-xmark而不是 set-mark，為什麼不用 set-mark，這是由於 set-mark會覆蓋原來的值。而 set-xmark value/netmask，表示 X=(X&(~netmask))^value， --set-xmark0x0/0x1000000的意思就是把X的第25位重置為0，其他位保留不變。

這個mark位的含義我在官方中沒有找到，在Calico網路的原理、組網方式與使用這篇文章找到了相關資料：

node一共使用了3個標記位，0x7000000對應的標記位

0x1000000: 報文的處理動作，置1表示放行，預設0表示拒絕

0x2000000: 是否已經經過了policy規則檢測，置1表示已經過

0x4000000: 報文來源，置1，表示來自host-endpoint

即第25位表示報文的處理動作，為1表示透過，0表示拒絕，第5、6條規則也可以看出第25位的意義，匹配0x1000000/0x1000000直接RETRUN，不匹配的直接DROP。

因此第3條規則的意思就是清空第25位標誌位重新評估，誰來評估呢？這就是第4條規則的作用，根據虛擬網路裝置cali-XXX所處的網路跳轉到指定網路的子鏈中處理，由於 calia2656637189屬於calico-net-1，因此會跳轉到 cali-pri-calico-net-1子鏈處理。

我們觀察 cali-pri-calico-net-1的規則：

# 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

規則很簡單，只要IP在cali4-s:VFoIKKR-LOG_UuTlYqcKubo在這個ipset集合中就設定mark第25位為1，然後RETURN，否則如果IP不在ipset中則直接DROP（子鏈的預設行為為DROP)。

# ipset list cali4-s:VFoIKKR-LOG_UuTlYqcKuboName: cali4-s:VFoIKKR-LOG_UuTlYqcKuboType: hash:ipRevision: 4Header: family inet hashsize 1024 maxelem 1048576Size in memory: 280References: 1Number of entries: 4Members:197.19.38.143197.19.26.7197.19.186.199197.19.38.144

到這裡終於真相大白了，Calico是透過iptables + ipset實現多網路隔離的，同一個網路的IP會加到同一個ipset集合中，不同網路的IP放到不同的ipset集合中，最後透過iptables的set模組匹配ipset集合的IP，如果src IP在指定的ipset中則允許透過，否則DROP。

5.5 Calico跨網段通訊

我們知道Flannel host-gw不支援Node主機跨網段，Calico是否支援呢，為此我增加了一個node-4(192.168.0.33/24)，顯然和其他三個Node不在同一個子網。

在新的Node中啟動一個busybox：

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

驗證發現容器通訊時沒有問題的。

檢視node-1路由：

# ip r | grep 197.19197.19.26.0/26 via 192.168.1.245 dev eth0 proto birdblackhole 197.19.38.128/26 proto bird197.19.38.142 dev cali459cc263d36 scope link197.19.38.143 dev cali6d0015b0c71 scope link197.19.38.144 dev calic8e5fab61b1 scope link197.19.65.128/26 via 192.168.0.33 dev tunl0 proto bird onlink197.19.186.192/26 via 192.168.1.254 dev eth0 proto bird

和其他路由不一樣的是，我們發現197.19.65.128/26是透過tunl0出去的：

# ip -d link show tunl05: 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 showtunl0: any/ip remote any local any ttl inherit nopmtudisc

由此可知，如果節點跨網段，則Calico透過ipip隧道傳輸，相當於走的是overlay。

對比Flannel host-gw，除了靜態與BGP動態路由配置的區別，Calico還透過iptables + ipset解決了多網路支援問題，透過ipip隧道實現了節點跨子網通訊問題。

另外，某些業務或者POD需要固定IP，比如POD從一個節點遷移到另一個節點保持IP不變，這種情況下可能導致容器的IP不在節點Node上分配的子網範圍內，Calico可以透過新增一條32位的明細路由實現，Flannel不支援這種情況。

因此相對來說Calico實現的功能相對要多些，但是，最終也導致Calico相對Flannel要複雜得多，運維難度也較大，光一堆iptables規則就不容易理清了。

六、與OpenStack網路整合的Kuryr

Kuryr是OpenStack中一個較新的專案，其目標是“Bridge between container framework networking and storage models to OpenStack networking and storage abstractions.”,即實現容器與OpenStack的網路整合，該方案實現了與虛擬機器、裸機相同的網路功能和互通，比如多租戶、安全組等。

網路模型和虛擬機器基本一樣，唯一區別在於虛擬機器是透過TAP裝置直接掛到虛擬機器裝置中的，而容器則是透過VETH連線到容器的namespace。

    vm               Container        whatever
    |                    |                |
   tapX                tapY             tapZ
    |                    |                |
    |                    |                |
  qbrX                 qbrY             qbrZ
    |                    |                |
---------------------------------------------
    |               br-int(OVS)           |
---------------------------------------------
                         |
----------------------------------------------
    |               br-tun(OVS)           |
----------------------------------------------

Kuryr在我之前的文章OpenStack容器服務Zun初探與原理分析詳細介紹過，這裡不再贅述。文章好看點這裡[在看]?