本文主要是介紹docker默認的網絡行為，包含創建的默認網絡類型以及如何創建用戶自定義網絡，也會介紹如何在單一主機或者跨主機集群上創建網絡的資源需求。

默認網絡

當你安裝了docker,它自動創建了3個網絡，可以使用docker network命令來查看

1.png

這三個網絡被docker內建。當你運行一個容器的時候，可以使用--network參數來指定
你的容器連接到哪一個網絡。

1、bridge網絡

默認連接到docker0這個網橋上。

2.png

啟動并運行一個容器

3.png

可以看到test1容器已經獲取了一個地址172.17.0.2，和主機的docker0接口地址在同一網絡，并將主機的docker0接口地址設置為了網關。

4.png

5.png

Docker 容器默認使用 bridge 模式的網絡。其特點如下：

• 使用一個 linux bridge，默認為 docker0
• 使用 veth 對，一頭在容器的網絡 namespace 中，一頭在 docker0 上
• 該模式下Docker Container不具有一個公有IP，因為宿主機的IP地址與vethpair的 IP地址不在同一個網段內
• Docker采用 NAT 方式，將容器內部的服務監聽的端口與宿主機的某一個端口port 進行“綁定”，使得宿主機以外的世界可以主動將網絡報文發送至容器內部
• 外界訪問容器內的服務時，需要訪問宿主機的 IP 以及宿主機的端口 port
• NAT 模式由于是在三層網絡上的實現手段，故肯定會影響網絡的傳輸效率。
• 容器擁有獨立、隔離的網絡棧；讓容器和宿主機以外的世界通過NAT建立通信

效果是這樣的：

6.png

示意圖如下：

7.png

8.png

可以使用docker network inspect bridge命令來查看bridge網絡情況：

[root@docker01 sysctl.d]# docker network inspect bridge
[
    {
        "Name": "bridge",
        "Id":
"2d82fcfaa00883ff4f6637b7fa199489dc9a2332a73b6f0d306625f72bb5979b",
        "Created": "2018-01-03T11:16:46.249349532+08:00",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.17.0.0/16",
                    "Gateway": "172.17.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {
           
"976c6814378e8bb27c209ce711434a70334d12a5ef13e965320501f7586f65f3": {
                "Name": "test1",
                "EndpointID":
"c3ed6dda70d048580b061812b4f53f94a4a4c1a90146897c7b0e7c71df967d57",
                "MacAddress": "02:42:ac:11:00:02",
                "IPv4Address": "172.17.0.2/16",
                "IPv6Address": ""
            }
        },
        "Options": {
            "com.docker.network.bridge.default_bridge": "true",
            "com.docker.network.bridge.enable_icc": "true",
            "com.docker.network.bridge.enable_ip_masquerade": "true",
            "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
            "com.docker.network.bridge.name": "docker0",
            "com.docker.network.driver.mtu": "1500"
        },
        "Labels": {}
    }
]

2、none網絡模式：

網絡模式為 none，即不為Docker容器構造任何網絡環境，不會為容器創建網絡接口，一旦Docker容器采用了none網絡模式，那么容器內部就只能使用loopback網絡設備，不會再有其他的網絡資源。Docker Container的none網絡模式意味著不給該容器創建任何網絡環境，容器只能使用127.0.0.1的本機網絡。

啟動一個容器，設為none網絡

docker run -it -d --network none --name test2 centos7:new002 /bin/bash
進入容器，查看網絡情況：

9.png

3、host網絡模式

Host模式并沒有為容器創建一個隔離的網絡環境。而之所以稱之為host模式，是因為該模式下的Docker 容器會和host宿主機共享同一個網絡namespace，故Docker Container可以和宿主機一樣，使用宿主機的eth0，實現和外界的通信。換言之，Docker Container的IP地址即為宿主機 eth0的IP地址。

其特點包括：

• 這種模式下的容器沒有隔離的 network namespace
• 容器的 IP 地址同 Docker host 的 IP 地址
• 需要注意容器中服務的端口號不能與 Docker host 上已經使用的端口號相沖突

• host 模式能夠和其它模式共存
  示意圖：

  
  
  1.png
  
  

  例如，我們在192.168.1.102/24 的機器上用 host 模式啟動一個含有 web 應用的 Docker容器，監聽 tcp 80 端口。當我們在容器中執行任何類似 ifconfig 命令查看網絡環境時，看到的都是宿主機上的信息。而外界訪問容器中的應用，則直接使用192.168.1.102:80 即可，不用任何 NAT 轉換，就如直接跑在宿主機中一樣。但是，容器的其他方面，如文件系
  統、進程列表等還是和宿主機隔離的。

啟動容器前，查看物理主機的httpd進程

2.png

啟動一個容器：

docker run -itd --privileged --name test7 --network host centos7:new002 init

3.png

進入容器，安裝httpd服務，并啟動

[root@docker01 ~]# docker exec -it test7 /bin/bash
[root@docker01 /]# yum install httpd -y
[root@docker01 /]# systemctl start httpd
[root@docker01 /]# echo "test docker host network" > /var/www/html/index.html

退出容器，再次查看httpd進程

4.png

訪問主機的80端口，可以訪問到容器test7中的網站服務:

5.png

6.png

4、container 模式

這個模式指定新創建的容器和已經存在的一個容器共享一個 Network Namespace，而不是和宿主機共享。新創建的容器不會創建自己的網卡，配置自己的 IP，而是和一個指定的容器共享 IP、端口范圍等。同樣，兩個容器除了網絡方面，其他的如文件系統、進程列表等還是隔離的。兩個容器的進程可以通過 lo 網卡設備通信。

Container 網絡模式是 Docker 中一種較為特別的網絡的模式。這兩個容器之間不存在網絡隔離，而這兩個容器又與宿主機以及除此之外其他的容器存在網絡隔離。
注意：因為此時兩個容器要共享一個network namespace，因此需要注意端口沖突情況，否則第二個容器將無法被啟動。
示意圖：

7.png

8.png

9.png

1.png

從docker hub下載一個httpd鏡像

[root@docker01 ~]# docker pull httpd

2.png

3.png

4.png

注意：
?容器有自己的內部網絡和 ip 地址（使用  docker inspect  可以獲取所有的變量。）
? -p 標記可以多次使用來綁定多個端口

5.png

image.png

1.png

2.png

# docker run -d -p 127.0.0.1:5000:5000/udp –name db4 commit:v1

查看映射端口配置
使用 docker port 來查看當前映射的端口配置，也可以查看到綁定的地址

3.png

docker端口映射實質上是在iptables 的nat表中添加了DNAT規則

4.png

用戶定義網絡（User-defined networks）

建議使用用戶定義的橋接網絡來控制容器之間彼此通信，并啟用容器名稱和IP地址的自動DNS解析，docker默認提供了用于創建這些網絡的默認網絡驅動程序，你能創建：

• bridge network

• overlay network

• MACVLAN network

• network plugin

• remote network

  您可以根據需要創建盡可能多的網絡，并且可以在任何給定的時間將容器連接到0個或多個網絡。此外，還可以在不重新啟動容器的情況下連接和斷開網絡中的運行容器。當容器連接到多個網絡時，它的外部連接是通過第一個非內部網絡提供的。
  Bridge networks
  是docker中最常見的網絡類型，它類似與默認的橋接網絡，但是添加了一些新功能，去掉了一些舊功能。
  可以通過下面的命令創建一個bridge網絡

docker network create --driver bridge isolated_nw

查看網絡情況：

[root@docker01 ~]# docker network inspect isolated_nw
[
    {
        "Name": "isolated_nw",
        "Id":
"61ed2c0fb3befae89f9f3642f46b8702578eb77d331593cc337cb7f601ada41c",
        "Created": "2018-01-04T10:28:30.080659461+08:00",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": {},
            "Config": [
                {
                    "Subnet": "172.18.0.0/16",
                    "Gateway": "172.18.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {
           
"810bf5548fdf263ced0f9b358cbbb08bf1438201578472ae74101a36bebfcf34": {
                "Name": "web001",
                "EndpointID":
"051f35c6dd332a3013f1d5e6bb5afd2d5aaacf16b9ed724d6f25c722a3bbea7e",
                "MacAddress": "02:42:ac:12:00:02",
                "IPv4Address": "172.18.0.2/16",
                "IPv6Address": ""
            }
        },
        "Options": {},
        "Labels": {}
    }
]
 [root@docker01 ~]# docker network ls
NETWORK ID          NAME                DRIVER              SCOPE
519fb0569cc3        bridge              bridge              local
731204303d51        host                host                local
61ed2c0fb3be        isolated_nw         bridge              local
6f69db181323        none                null                local

啟動一個容器然后將其加入新創建的網絡：

[root@docker01 ~]# docker run -itd --network isolated_nw --name web002 httpd
77c9bb8d8414d4cf9444445916f07b5f29dcd5ff8ab768089e365370c4614872
[root@docker01 ~]# docker network inspect isolated_nw
[
    {
        "Name": "isolated_nw",
        "Id":
"61ed2c0fb3befae89f9f3642f46b8702578eb77d331593cc337cb7f601ada41c",
        "Created": "2018-01-04T10:28:30.080659461+08:00",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": {},
            "Config": [
                {
                    "Subnet": "172.18.0.0/16",
                    "Gateway": "172.18.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {
           
"77c9bb8d8414d4cf9444445916f07b5f29dcd5ff8ab768089e365370c4614872": {
                "Name": "web002",
                "EndpointID":
"c1c1bf1f40890b28850b4b7d80d376ffc143e88259b8ffb18e7612caa93e5a22",
                "MacAddress": "02:42:ac:12:00:03",
                "IPv4Address": "172.18.0.3/16",
                "IPv6Address": ""
            },
           
"810bf5548fdf263ced0f9b358cbbb08bf1438201578472ae74101a36bebfcf34": {
                "Name": "web001",
                "EndpointID":
"051f35c6dd332a3013f1d5e6bb5afd2d5aaacf16b9ed724d6f25c722a3bbea7e",
                "MacAddress": "02:42:ac:12:00:02",
                "IPv4Address": "172.18.0.2/16",
                "IPv6Address": ""
            }
        },
        "Options": {},
        "Labels": {}
    }
]

加入你創建的網絡中的容器必須在同一個HOST主機上，網絡中的每個容器都可以立即與網絡中的其他容器通信。然而，網絡本身將容器與外部網絡隔離開來。

5.png

在用戶定義的網橋網絡中，不支持linking。可以在這個網絡中公開和發布容器端口,也就是expose and publish 。

6.png

如果你想在單一主機上運行一個相對小的網絡，使用橋接網絡是有效果的。
然而你想創建一個大網絡，可以通過overlay 網絡來實現。

跨主機docker容器通信方案介紹：

現有的主要Docker網絡方案

基于實現方式分類：

隧道方案

通過隧道，或者說Overlay Networking的方式：

• Weave：UDP廣播，本機建立新的BR，通過PCAP互通。
• Open vSwitch(OVS)：基于VxLAN和GRE協議，但是性能方面損失比較嚴重。
• Flannel：UDP廣播，VxLan。
  隧道方案在IaaS層的網絡中應用也比較多，大家共識是隨著節點規模的增長復雜度會提升，而且出了網絡問題跟蹤起來比較麻煩，大規模集群情況下這是需要考慮的一個點。

路由方案

通過路由來實現，比較典型的代表有：

• Calico：基于BGP協議的路由方案，支持很細致的ACL控制，對混合云親和度比較高。
• Macvlan：從邏輯和Kernel層來看隔離性和性能最優的方案，基于二層隔離，所以需要二層路由器支持，大多數云服務商不支持，所以混合云上比較難以實現。

路由方案一般是從3層或者2層實現隔離和跨主機容器互通的，出了問題也很容易排查。

基于網絡模型分類

Docker Libnetwork Container Network Model(CNM)陣營

• Docker Swarm overlay
• Macvlan & IP network drivers
• Calico
• Contiv（from Cisco）
  Docker Libnetwork的優勢就是原生，而且和Docker容器生命周期結合緊密；缺點也可以理解為是原生，被Docker“綁架”。

Container Network Interface(CNI)陣營

• Kubernetes
• Weave
• Macvlan
• Flannel
• Calico
• Contiv
• Mesos CNI
  CNI的優勢是兼容其他容器技術(e.g. rkt)及上層編排系統(Kuberneres & Mesos)，而且社區活躍勢頭迅猛，Kubernetes加上CoreOS主推；缺點是非Docker原生。
  從上的可以看出，有一些第三方的網絡方案是同時屬于兩個陣營的。
  下面主要介紹了Docker容器平臺中的libnetwork，flannel，calico，weave這幾種跨主機通信方案，并對各個方案的原理進行闡述。

Libnetwork

Libnetwork是從1.6版本開始將Docker的網絡功能從Docker核心代碼中分離出去，形成一個單獨的庫。Libnetwork的目標是定義一個健壯的容器網絡模型，提供一個一致的編程接口和應用程序的網絡抽象。

Libnetwork通過插件的形式為Docker提供網絡功能，使得用戶可以根據自己的需求實現自己的Driver來提供不同的網絡功能。從1.9版本開始，docker已經實現了基于Libnetwork和libkv庫的網絡模式-多主機的Overlay網絡。

Libnetwork所要實現的網絡模型基本是這樣的：用戶可以創建一個或多個網絡(一個網絡就是一個網橋或者一個VLAN)，一個容器可以加入一個或多個網絡。 同一個網絡中容器可以通信，不同網絡中的容器隔離。

Libnetwork實現了一個叫做Container Network Model (CNM)的東西，也就是說希望成為容器的標準網絡模型、框架。其包含了下面幾個概念：

7.png

• Sandbox。Sandbox包含容器網絡棧的配置，包括容器接口，路由表，DNS配置等的管理。 linux network namespace是常見的一種sandbox的實現。Sandbox中包含眾多網絡中的若干Endpoint。
• Endpoint。Neutron中和Endpoint相對的概念應該是VNIC，也就是虛擬機的虛擬網卡（也可以看成是VIF）。Endpoint的常見實現包括veth pair、Openvswitch的internal port。當Sandbox要和外界通信的時候就是通過Endpoint連接到外界的，最簡單的情況就是連接到一個Bridge上。
• Network。Network是一組可以互相通信的Endpoints集合，組內endpoint可以相互通訊。不同組內endpoint是不能通迅的，是完全隔離的。常見的實現包括linux bridge,vlan等。

目前已經實現了如下Driver：

• Host：主機網絡，只用這種網絡的容器會使用主機的網絡，這種網絡對外界是完全開放的，能夠訪問到主機，就能訪問到容器。
• Bridge：橋接網絡，這個Driver就是Docker現有網絡Bridge模式的實現。除非創建容器的時候指定網絡，不然容器就會默認的使用橋接網絡。屬于這個網絡的容器之間可以相互通信，外界想要訪問到這個網絡的容器需使用橋接網絡。
• Null： Driver的空實現，類似于Docker容器的None模式。使用這種網絡的容器會完全隔離。
• Overlay： Overlay驅動可以實現通過vxlan等重疊網絡封裝技術跨越多個主機的網絡，目前Docker已經自帶該驅動。
• Remote：Remote驅動包不提供驅動，但提供了融合第三方驅動的接口。

Flannel

Flannel之前的名字是Rudder，它是由CoreOS團隊針對Kubernetes設計的一個重載網絡工具，它的主要思路是：預先留出一個網段，每個主機使用其中一部分，然后每個容器被分配不同的ip；讓所有的容器認為大家在同一個直連的網絡，底層通過UDP/VxLAN等進行報文的封裝和轉發。

Flannel類似于weave、vxlan，提供了一個可配置的虛擬承載網絡。Flannel以一個daemon形式運行，負責子網的分配，flannel使用etcd存儲、交換網絡配置、狀態等信息。

flannel基本原理

flannel默認使用8285端口作為UDP封裝報文的端口，VxLan使用8472端口。

8.png

1. 容器直接使用目標容器的ip訪問，默認通過容器內部的eth0發送出去。
2. 報文通過veth pair被發送到vethXXX。
3. vethXXX是直接連接到虛擬交換機docker0的，報文通過虛擬bridge docker0發送出去。
4. 查找路由表，外部容器ip的報文都會轉發到flannel0虛擬網卡，這是一個P2P的虛擬網卡，然后報文就被轉發到監聽在另一端的flanneld。
5. flanneld通過etcd維護了各個節點之間的路由表，把原來的報文UDP封裝一層，通過配置的iface發送出去。
6. 報文通過主機之間的網絡找到目標主機。
7. 報文繼續往上，到傳輸層，交給監聽在8285端口的flanneld程序處理。
8. 數據被解包，然后發送給flannel0虛擬網卡。
9. 查找路由表，發現對應容器的報文要交給docker0。
10. docker0找到連到自己的容器，把報文發送過去。

Calico

Calico是一個純3層的數據中心網絡方案，而且無縫集成像OpenStack這種IaaS云架構，能夠提供可控的VM、容器、裸機之間的IP通信。

它基于BPG協議和Linux自己的路由轉發機制，不依賴特殊硬件，沒有使用NAT或Tunnel等技術。能夠方便的部署在物理服務器、虛擬機或者容器環境下。同時它自帶的基于Iptables的ACL管理組件非常靈活，能夠滿足比較復雜的安全隔離需求。

Calico在每一個計算節點利用Linux Kernel實現了一個高效的vRouter來負責數據轉發，而每個vRouter通過BGP協議負責把自己上運行的workload的路由信息向整個Calico網絡內傳播—小規模部署可以直接互聯，大規模下可通過指定的BGP route reflector來完成。

這樣保證最終所有的workload之間的數據流量都是通過IP路由的方式完成互聯的。

基本原理

9.png

Calico的方案如上圖所示。它把每個操作系統的協議棧認為是一個路由器，然后把所有的容
器認為是連在這個路由器上的網絡終端，在路由器之間跑標準的路由協議—BGP的協議，然
后讓它們自己去學習這個網絡拓撲該如何轉發。所以Calico方案其實是一個純三層的方案，
也就是說讓每臺機器的協議棧的三層去確保兩個容器，跨主機容器之間的三層連通性。

Calico架構

10.png

結合上面這張圖，我們來過一遍Calico的核心組件：

• Felix:Calico Agent，跑在每臺需要運行Workload的節點上，主要負責配置路由及ACLS等信息來確保Endpoint的連通狀態。
• etcd:分布式鍵值存儲，主要負責網絡元數據一致性，確保Calico網絡狀態的準確性。
• BGP Client（BIRD）: 主要負責把Felix寫入Kernel的路由信息分發到當前Calico網絡，確保Workload間的通信的有效性。
• BGP Route Reflector（BIRD）：大規模部署時使用，摒棄所有節點互聯的mesh模式，通過一個或者多個BGP Route Reflector來完成集中式的路由分發。

每個節點上會運行兩個主要的程序，一個是它自己的叫Felix，它會監聽ECTD中心的存儲，從它獲取事件，比如說用戶在這臺機器上加了一個IP，或者是分配了一個容器等。接著會在這臺機器上創建出一個容器，并將其網卡、IP、MAC都設置好，然后在內核的路由表里面寫一條，注明這個IP應該到這張網卡。

bird是一個標準的路由程序，它會從內核里面獲取哪一些IP的路由發生了變化，然后通過標準BGP的路由協議擴散到整個其他的宿主機上，讓外界都知道這個IP在這里，你們路由的時候得到這里來。

由于Calico是一種純三層的實現，因此可以避免與二層方案相關的數據包封裝的操作，中間沒有任何的NAT，沒有任何的overlay，所以它的轉發效率可能是所有方案中最高的，因為它的包直接走原生TCP/IP的協議棧，它的隔離也因為這個棧而變得好做。因為TCP/IP的協議棧提供了一整套的防火墻的規則，所以它可以通過IPTABLES的規則達到比較復雜的隔離邏輯。

Calico優劣勢

• Calico的優勢

1. 網絡拓撲直觀易懂，平行式擴展，可擴展性強
2. 容器間網絡三層隔離，無需要擔心arp風暴
3. 基于iptable/linux kernel包轉發效率高，損耗低
4. 更容易的編程語言(python)
5. 社區活躍，正式版本較成熟

• Calico的劣勢

1. calico僅支持TCP, UDP, ICMP andICMPv6協議，如果你想使用L4協議，你只能選擇Flannel,Weave或Docker Overlay Network。
2. Calico沒有加密數據路徑。 用不可信網絡上的Calico建立覆蓋網絡是不安全的。
3. 沒有IP重疊支持。 雖然Calico社區正在開發一個實驗功能，將重疊IPv4包放入IPv6包中。 但這只是一個輔助解決方案，并不完全支持技術上的IP重疊。

Weave

Weave是由Zett.io公司開發的，它能夠創建一個虛擬網絡，用于連接部署在多臺主機上的Docker容器，這樣容器就像被接入了同一個網絡交換機，那些使用網絡的應用程序不必去配置端口映射和鏈接等信息。

外部設備能夠訪問Weave網絡上的應用程序容器所提供的服務，同時已有的內部系統也能夠暴露到應用程序容器上。Weave能夠穿透防火墻并運行在部分連接的網絡上，另外，Weave的通信支持加密，所以用戶可以從一個不受信任的網絡連接到主機。

Weave實現原理

11.png

容器的網絡通訊都通過route服務和網橋轉發。

12.png

Weave會在主機上創建一個網橋,每一個容器通過veth pair連接到該網橋上，同時網橋上有個Weave router的容器與之連接，該router會通過連接在網橋上的接口來抓取網絡包(該接口工作在Promiscuous模式)。

在每一個部署Docker的主機(可能是物理機也可能是虛擬機)上都部署有一個W(即Weaverouter)，它本身也可以以一個容器的形式部署)。Weave run的時候就可以給每個veth的容器端分配一個ip和相應的掩碼。veth的網橋這端就是Weave router容器，并在Weavelaunch的時候分配好ip和掩碼。

Weave網絡是由這些weave routers組成的對等端點(peer)構成，每個對等的一端都有自己的名字，其中包括一個可讀性好的名字用于表示狀態和日志的輸出，一個唯一標識符用于運行中相互區別，即使重啟Docker主機名字也保持不變，這些名字默認是mac地址。

每個部署了Weave router的主機都需要將TCP和UDP的6783端口的防火墻設置打開，保證Weave router之間控制面流量和數據面流量的通過。控制面由weave routers之間建立的TCP連接構成，通過它進行握手和拓撲關系信息的交換通信。 這個通信可以被配置為加密通信。而數據面Weave routers之間建立的UDP連接構成，這些連接大部分都會加密。這些連接都是全雙工的，并且可以穿越防火墻。

Weave優劣勢

• Weave優勢

1. 支持主機間通信加密。
2. 支持container動態加入或者剝離網絡。
3. 支持跨主機多子網通信。

• Weave劣勢

1. 只能通過weave launch或者weave connect加入weave網絡。

各方案對比

• Flannel和overlay方案均使用承載網絡，承載網絡的優勢和劣勢都是非常明顯。

優勢有：對底層網絡依賴較少，不管底層是物理網絡還是虛擬網絡，對層疊網絡的配置管理影響較少；配置簡單，邏輯清晰，易于理解和學習，非常適用于開發測試等對網絡性能要求不高的場景。

劣勢主要包括：網絡封裝是一種傳輸開銷，對網絡性能會有影響，不適用于對網絡性能要求高的生產場景；由于對底層網絡結構缺乏了解，無法做到真正有效的流量工程控制，也會對網絡性能產生影響；某些情況下也不能完全做到與下層網絡無關，例如隧道封裝會對網絡的MTU限制產生影響。

• Calico方案因為沒有隧道封裝的網絡開銷，會帶來相對較高的網絡性能。不支持多租戶，由于沒有封裝所有的容器只能通過真實的IP來區分自己，這就要求所有租戶的容器統一分配一個地址空間。Calico基于三層轉發的原理對物理架構可能會有一定的要求和侵入性。
• weave可以穿透防火墻，安全性較高，流量是被加密的，允許主機連接通過一個不被信任的網絡，同樣會有承載網絡的帶來的優缺點。