[[406785]]

在 Kubernetes 中要保證容器之間網(wǎng)絡(luò)互通，網(wǎng)絡(luò)至關(guān)重要。而 Kubernetes 本身并沒(méi)有自己實(shí)現(xiàn)容器網(wǎng)絡(luò)，而是通過(guò)插件化的方式自由接入進(jìn)來(lái)。在容器網(wǎng)絡(luò)接入進(jìn)來(lái)需要滿(mǎn)足如下基本原則：

• pod 無(wú)論運(yùn)行在任何節(jié)點(diǎn)都可以互相直接通信，而不需要借助 NAT 地址轉(zhuǎn)換實(shí)現(xiàn)。
• node 與 pod 可以互相通信，在不限制的前提下，pod 可以訪(fǎng)問(wèn)任意網(wǎng)絡(luò)。
• pod 擁有獨(dú)立的網(wǎng)絡(luò)棧，pod 看到自己的地址和外部看見(jiàn)的地址應(yīng)該是一樣的，并且同個(gè) pod 內(nèi)所有的容器共享同個(gè)網(wǎng)絡(luò)棧。

容器網(wǎng)絡(luò)基礎(chǔ)

一個(gè) Linux 容器的網(wǎng)絡(luò)棧是被隔離在它自己的 Network Namespace中，Network Namespace 包括了：網(wǎng)卡（Network Interface），回環(huán)設(shè)備（Lookback Device），路由表（Routing Table）和 iptables 規(guī)則，對(duì)于服務(wù)進(jìn)程來(lái)講這些就構(gòu)建了它發(fā)起請(qǐng)求和相應(yīng)的基本環(huán)境。

而要實(shí)現(xiàn)一個(gè)容器網(wǎng)絡(luò)，離不開(kāi)以下 Linux 網(wǎng)絡(luò)功能：

• 網(wǎng)絡(luò)命名空間：將獨(dú)立的網(wǎng)絡(luò)協(xié)議棧隔離到不同的命令空間中，彼此間無(wú)法通信。
• Veth Pair：Veth設(shè)備對(duì)的引入是為了實(shí)現(xiàn)在不同網(wǎng)絡(luò)命名空間的通信,總是以?xún)蓮執(zhí)摂M網(wǎng)卡（veth peer）的形式成對(duì)出現(xiàn)的。并且，從其中一端發(fā)出的數(shù)據(jù)，總是能在另外一端收到。
• Iptables/Netfilter：Netfilter 負(fù)責(zé)在內(nèi)核中執(zhí)行各種掛接的規(guī)則(過(guò)濾、修改、丟棄等)，運(yùn)行在內(nèi)核中；Iptables 模式是在用戶(hù)模式下運(yùn)行的進(jìn)程，負(fù)責(zé)協(xié)助維護(hù)內(nèi)核中 Netfilter 的各種規(guī)則表；通過(guò)二者的配合來(lái)實(shí)現(xiàn)整個(gè) Linux 網(wǎng)絡(luò)協(xié)議棧中靈活的數(shù)據(jù)包處理機(jī)制
• 網(wǎng)橋：網(wǎng)橋是一個(gè)二層網(wǎng)絡(luò)虛擬設(shè)備,類(lèi)似交換機(jī),主要功能是通過(guò)學(xué)習(xí)而來(lái)的Mac地址將數(shù)據(jù)幀轉(zhuǎn)發(fā)到網(wǎng)橋的不同端口上。
• 路由：Linux系統(tǒng)包含一個(gè)完整的路由功能，當(dāng)IP層在處理數(shù)據(jù)發(fā)送或轉(zhuǎn)發(fā)的時(shí)候，會(huì)使用路由表來(lái)決定發(fā)往哪里

基于以上的基礎(chǔ)，同宿主機(jī)的容器時(shí)間如何通信呢？

我們可以簡(jiǎn)單把他們理解成兩臺(tái)主機(jī)，主機(jī)之間通過(guò)網(wǎng)線(xiàn)連接起來(lái)，如果要多臺(tái)主機(jī)通信，我們通過(guò)交換機(jī)就可以實(shí)現(xiàn)彼此互通，在 Linux 中，我們可以通過(guò)網(wǎng)橋來(lái)轉(zhuǎn)發(fā)數(shù)據(jù)。

在容器中，以上的實(shí)現(xiàn)是通過(guò) docker0 網(wǎng)橋，凡是連接到 docker0 的容器，就可以通過(guò)它來(lái)進(jìn)行通信。要想容器能夠連接到 docker0 網(wǎng)橋，我們也需要類(lèi)似網(wǎng)線(xiàn)的虛擬設(shè)備Veth Pair 來(lái)把容器連接到網(wǎng)橋上。

我們啟動(dòng)一個(gè)容器：

docker run -d --name c1 hub.pri.ibanyu.com/devops/alpine:v3.8 /bin/sh 

然后查看網(wǎng)卡設(shè)備：

docker exec -it c1 /bin/sh 
 
/ # ifconfig 
 
eth0 Link encap:Ethernet HWaddr 02:42:AC:11:00:02 
 
inet addr:172.17.0.2 Bcast:172.17.255.255 Mask:255.255.0.0 
 
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 
 
RX packets:14 errors:0 dropped:0 overruns:0 frame:0 
 
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 
 
collisions:0 txqueuelen:0 
 
RX bytes:1172 (1.1 KiB) TX bytes:0 (0.0 B) 
 
lo Link encap:Local Loopback 
 
inet addr:127.0.0.1 Mask:255.0.0.0 
 
UP LOOPBACK RUNNING MTU:65536 Metric:1 
 
RX packets:0 errors:0 dropped:0 overruns:0 frame:0 
 
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 
 
collisions:0 txqueuelen:1000 
 
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) 
 
/ # route -n 
 
Kernel IP routing table 
 
Destination Gateway Genmask Flags Metric Ref Use Iface 
 
0.0.0.0 172.17.0.1 0.0.0.0 UG 0 0 0 eth0 
 
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 

可以看到其中有一張 eth0 的網(wǎng)卡，它就是 veth peer 其中的一端的虛擬網(wǎng)卡。

然后通過(guò) route -n 查看容器中的路由表，eth0 也正是默認(rèn)路由出口。所有對(duì)172.17.0.0/16 網(wǎng)段的請(qǐng)求都會(huì)從 eth0 出去。

我們?cè)賮?lái)看 Veth peer 的另一端，我們查看宿主機(jī)的網(wǎng)絡(luò)設(shè)備：

ifconfig 
 
docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 
 
inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255 
 
inet6 fe80::42:6aff:fe46:93d2 prefixlen 64 scopeid 0x20<link> 
 
ether 02:42:6a:46:93:d2 txqueuelen 0 (Ethernet) 
 
RX packets 0 bytes 0 (0.0 B) 
 
RX errors 0 dropped 0 overruns 0 frame 0 
 
TX packets 8 bytes 656 (656.0 B) 
 
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 
 
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 
 
inet 10.100.0.2 netmask 255.255.255.0 broadcast 10.100.0.255 
 
inet6 fe80::5400:2ff:fea3:4b44 prefixlen 64 scopeid 0x20<link> 
 
ether 56:00:02:a3:4b:44 txqueuelen 1000 (Ethernet) 
 
RX packets 7788093 bytes 9899954680 (9.2 GiB) 
 
RX errors 0 dropped 0 overruns 0 frame 0 
 
TX packets 5512037 bytes 9512685850 (8.8 GiB) 
 
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 
 
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 
 
inet 127.0.0.1 netmask 255.0.0.0 
 
inet6 ::1 prefixlen 128 scopeid 0x10<host> 
 
loop txqueuelen 1000 (Local Loopback) 
 
RX packets 32 bytes 2592 (2.5 KiB) 
 
RX errors 0 dropped 0 overruns 0 frame 0 
 
TX packets 32 bytes 2592 (2.5 KiB) 
 
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 
 
veth20b3dac: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 
 
inet6 fe80::30e2:9cff:fe45:329 prefixlen 64 scopeid 0x20<link> 
 
ether 32:e2:9c:45:03:29 txqueuelen 0 (Ethernet) 
 
RX packets 0 bytes 0 (0.0 B) 
 
RX errors 0 dropped 0 overruns 0 frame 0 
 
TX packets 8 bytes 656 (656.0 B) 
 
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 

我們可以看到，容器對(duì)應(yīng)的 Veth peer 另一端是宿主機(jī)上的一塊虛擬網(wǎng)卡叫veth20b3dac，并且可以通過(guò) brctl 查看網(wǎng)橋信息看到這張網(wǎng)卡是在 docker0 上。

# brctl show  
 
docker0 8000.02426a4693d2 no veth20b3dac  

然后我們?cè)賳?dòng)一個(gè)容器，從第一個(gè)容器是否能 ping 通第二個(gè)容器。

$ docker run -d --name c2 -it hub.pri.ibanyu.com/devops/alpine:v3.8 /bin/sh 
 
$ docker exec -it c1 /bin/sh 
 
/ # ping 172.17.0.3 
 
PING 172.17.0.3 (172.17.0.3): 56 data bytes 
 
64 bytes from 172.17.0.3: seq=0 ttl=64 time=0.291 ms 
 
64 bytes from 172.17.0.3: seq=1 ttl=64 time=0.129 ms 
 
64 bytes from 172.17.0.3: seq=2 ttl=64 time=0.142 ms 
 
64 bytes from 172.17.0.3: seq=3 ttl=64 time=0.169 ms 
 
64 bytes from 172.17.0.3: seq=4 ttl=64 time=0.194 ms 
 
^C 
 
--- 172.17.0.3 ping statistics --- 
 
5 packets transmitted, 5 packets received, 0% packet loss 
 
round-trip min/avg/max = 0.129/0.185/0.291 ms 

可以看到，能夠 ping 通，其原理就是我們 ping 目標(biāo) IP 172.17.0.3時(shí)，會(huì)匹配到我們的路由表第二條規(guī)則，網(wǎng)關(guān)為0.0.0.0，這就意味著是一條直連路由，通過(guò)二層轉(zhuǎn)發(fā)到目的地。

要通過(guò)二層網(wǎng)絡(luò)到達(dá)172.17.0.3，我們需要知道它的 Mac 地址，此時(shí)就需要第一個(gè)容器發(fā)送一個(gè)ARP廣播，來(lái)通過(guò)IP地址查找Mac。

此時(shí) Veth peer 另外一段是 docker0 網(wǎng)橋，它會(huì)廣播到所有連接它的 veth peer 虛擬網(wǎng)卡去，然后正確的虛擬網(wǎng)卡收到后會(huì)響應(yīng)這個(gè)ARP報(bào)文，然后網(wǎng)橋再回給第一個(gè)容器。

以上就是同宿主機(jī)不同容器通過(guò) docker0 通信，如下圖所示：

默認(rèn)情況下，通過(guò) network namespace 限制的容器進(jìn)程，本質(zhì)上是通過(guò)Veth peer設(shè)備和宿主機(jī)網(wǎng)橋的方式，實(shí)現(xiàn)了不同 network namespace 的數(shù)據(jù)交換。

與之類(lèi)似地，當(dāng)你在一臺(tái)宿主機(jī)上，訪(fǎng)問(wèn)該宿主機(jī)上的容器的 IP 地址時(shí)，這個(gè)請(qǐng)求的數(shù)據(jù)包，也是先根據(jù)路由規(guī)則到達(dá) docker0 網(wǎng)橋，然后被轉(zhuǎn)發(fā)到對(duì)應(yīng)的 Veth Pair 設(shè)備，最后出現(xiàn)在容器里。

跨主機(jī)網(wǎng)絡(luò)通信

在 Docker 的默認(rèn)配置下，不同宿主機(jī)上的容器通過(guò) IP 地址進(jìn)行互相訪(fǎng)問(wèn)是根本做不到的。為了解決這個(gè)問(wèn)題，社區(qū)中出現(xiàn)了很多網(wǎng)絡(luò)方案。同時(shí) K8s 為了更好的控制網(wǎng)絡(luò)的接入，推出了 CNI 即容器網(wǎng)絡(luò)的 API 接口。

它是 K8s 中標(biāo)準(zhǔn)的一個(gè)調(diào)用網(wǎng)絡(luò)實(shí)現(xiàn)的接口，kubelet通過(guò)這個(gè)API來(lái)調(diào)用不同的網(wǎng)絡(luò)插件以實(shí)現(xiàn)不同的網(wǎng)絡(luò)配置，實(shí)現(xiàn)了這個(gè)接口的就是CNI插件，它實(shí)現(xiàn)了一系列的CNI API接口。目前已經(jīng)有的包括flannel、calico、weave、contiv等等。

實(shí)際上 CNI 的容器網(wǎng)絡(luò)通信流程跟前面的基礎(chǔ)網(wǎng)絡(luò)一樣，只是CNI維護(hù)了一個(gè)單獨(dú)的網(wǎng)橋來(lái)代替 docker0。這個(gè)網(wǎng)橋的名字就叫作：CNI 網(wǎng)橋，它在宿主機(jī)上的設(shè)備名稱(chēng)默認(rèn)是：cni0。

cni的設(shè)計(jì)思想，就是：Kubernetes 在啟動(dòng) Infra 容器之后，就可以直接調(diào)用 CNI 網(wǎng)絡(luò)插件，為這個(gè) Infra 容器的 Network Namespace，配置符合預(yù)期的網(wǎng)絡(luò)棧。

CNI 插件三種網(wǎng)絡(luò)實(shí)現(xiàn)模式：

• overlay 模式是基于隧道技術(shù)實(shí)現(xiàn)的，整個(gè)容器網(wǎng)絡(luò)和主機(jī)網(wǎng)絡(luò)獨(dú)立，容器之間跨主機(jī)通信時(shí)將整個(gè)容器網(wǎng)絡(luò)封裝到底層網(wǎng)絡(luò)中，然后到達(dá)目標(biāo)機(jī)器后再解封裝傳遞到目標(biāo)容器。不依賴(lài)與底層網(wǎng)絡(luò)的實(shí)現(xiàn)。實(shí)現(xiàn)的插件有flannel（UDP、vxlan）、calico（IPIP）等等
• 三層路由模式中容器和主機(jī)也屬于不通的網(wǎng)段，他們?nèi)萜骰ネㄖ饕腔诼酚杀泶蛲?，無(wú)需在主機(jī)之間建立隧道封包。但是限制條件必須依賴(lài)大二層同個(gè)局域網(wǎng)內(nèi)。實(shí)現(xiàn)的插件有flannel（host-gw）、calico（BGP）等等
• underlay網(wǎng)絡(luò)是底層網(wǎng)絡(luò)，負(fù)責(zé)互聯(lián)互通。容器網(wǎng)絡(luò)和主機(jī)網(wǎng)絡(luò)依然分屬不同的網(wǎng)段，但是彼此處于同一層網(wǎng)絡(luò)，處于相同的地位。整個(gè)網(wǎng)絡(luò)三層互通，沒(méi)有大二層的限制，但是需要強(qiáng)依賴(lài)底層網(wǎng)絡(luò)的實(shí)現(xiàn)支持.實(shí)現(xiàn)的插件有calico（BGP）等等

我們看下路由模式的一種實(shí)現(xiàn) flannel Host-gw：

如圖可以看到當(dāng) node1上container-1 要發(fā)數(shù)據(jù)給 node2 上的 container2 時(shí)，會(huì)匹配到如下的路由表規(guī)則：

10.244.1.0/24 via 10.168.0.3 dev eth0 

表示前往目標(biāo)網(wǎng)段 10.244.1.0/24 的 IP 包，需要經(jīng)過(guò)本機(jī) eth0 出去發(fā)往的下一跳ip地址為10.168.0.3（node2）。然后到達(dá) 10.168.0.3 以后再通過(guò)路由表轉(zhuǎn)發(fā) cni 網(wǎng)橋，進(jìn)而進(jìn)入到 container2。

以上可以看到 host-gw 工作原理，其實(shí)就是在每個(gè) node 節(jié)點(diǎn)配置到每個(gè) pod 網(wǎng)段的下一跳為pod網(wǎng)段所在的 node 節(jié)點(diǎn) IP，pod 網(wǎng)段和 node 節(jié)點(diǎn) ip 的映射關(guān)系，flannel 保存在etcd或者k8s中。flannel 只需要 watch 這些數(shù)據(jù)的變化來(lái)動(dòng)態(tài)更新路由表即可。

這種網(wǎng)絡(luò)模式最大的好處就是避免了額外的封包和解包帶來(lái)的網(wǎng)絡(luò)性能損耗。缺點(diǎn)我們也能看見(jiàn)主要就是容器ip包通過(guò)下一跳出去時(shí)，必須要二層通信封裝成數(shù)據(jù)幀發(fā)送到下一跳。如果不在同個(gè)二層局域網(wǎng)，那么就要交給三層網(wǎng)關(guān)，而此時(shí)網(wǎng)關(guān)是不知道目標(biāo)容器網(wǎng)絡(luò)的（也可以靜態(tài)在每個(gè)網(wǎng)關(guān)配置pod網(wǎng)段路由）。所以 flannel host-gw 必須要求集群宿主機(jī)是二層互通的。

而為了解決二層互通的限制性，calico提供的網(wǎng)絡(luò)方案就可以更好的實(shí)現(xiàn)，calico 大三層網(wǎng)絡(luò)模式與flannel 提供的類(lèi)似，也會(huì)在每臺(tái)宿主機(jī)添加如下格式的路由規(guī)則：

<目標(biāo)容器IP網(wǎng)段> via <網(wǎng)關(guān)的IP地址> dev eth0 

其中網(wǎng)關(guān)的 IP 地址不通場(chǎng)景有不同的意思,如果宿主機(jī)是二層可達(dá)那么就是目的容器所在的宿主機(jī)的 IP 地址，如果是三層不同局域網(wǎng)那么就是本機(jī)宿主機(jī)的網(wǎng)關(guān)IP（交換機(jī)或者路由器地址）。

不同于 flannel 通過(guò) k8s 或者 etcd 存儲(chǔ)的數(shù)據(jù)來(lái)維護(hù)本機(jī)路由信息的做法，calico是通過(guò)BGP 動(dòng)態(tài)路由協(xié)議來(lái)分發(fā)整個(gè)集群路由信息。

BGP 全稱(chēng)是 Border Gateway Protocol邊界網(wǎng)關(guān)協(xié)議,linxu原生支持的、專(zhuān)門(mén)用于在大規(guī)模數(shù)據(jù)中心為不同的自治系統(tǒng)之間傳遞路由信息。只要記住BGP簡(jiǎn)單理解其實(shí)就是實(shí)現(xiàn)大規(guī)模網(wǎng)絡(luò)中節(jié)點(diǎn)路由信息同步共享的一種協(xié)議。而B(niǎo)GP這種協(xié)議就能代替flannel 維護(hù)主機(jī)路由表功能。

calico 主要由三個(gè)部分組成：

• calico cni插件: 主要負(fù)責(zé)與kubernetes對(duì)接，供kubelet調(diào)用使用。
• felix: 負(fù)責(zé)維護(hù)宿主機(jī)上的路由規(guī)則、FIB轉(zhuǎn)發(fā)信息庫(kù)等。
• BIRD: 負(fù)責(zé)分發(fā)路由規(guī)則，類(lèi)似路由器。
• confd: 配置管理組件。

除此之外，calico 還和 flannel host-gw 不同之處在于，它不會(huì)創(chuàng)建網(wǎng)橋設(shè)備，而是通過(guò)路由表來(lái)維護(hù)每個(gè)pod的通信，如下圖所示：

可以看到 calico 的 cni 插件會(huì)為每個(gè)容器設(shè)置一個(gè) veth pair 設(shè)備，然后把另一端接入到宿主機(jī)網(wǎng)絡(luò)空間，由于沒(méi)有網(wǎng)橋，cni 插件還需要在宿主機(jī)上為每個(gè)容器的 veth pair設(shè)備配置一條路由規(guī)則，用于接收傳入的IP包，路由規(guī)則如下：

10.92.77.163 dev cali93a8a799fe1 scope link 

以上表示發(fā)送10.92.77.163的IP包應(yīng)該發(fā)給cali93a8a799fe1設(shè)備，然后到達(dá)另外一段容器中。

有了這樣的veth pair設(shè)備以后，容器發(fā)出的IP包就會(huì)通過(guò)veth pair設(shè)備到達(dá)宿主機(jī)，然后宿主機(jī)根據(jù)路有規(guī)則的下一條地址，發(fā)送給正確的網(wǎng)關(guān)(10.100.1.3)，然后到達(dá)目標(biāo)宿主機(jī)，在到達(dá)目標(biāo)容器。

10.92.160.0/23 via 10.106.65.2 dev bond0 proto bird 

這些路由規(guī)則都是felix維護(hù)配置的，而路由信息則是calico bird組件基于BGP分發(fā)而來(lái)。calico實(shí)際上是將集群里所有的節(jié)點(diǎn)都當(dāng)做邊界路由器來(lái)處理,他們一起組成了一個(gè)全互聯(lián)的網(wǎng)絡(luò)，彼此之間通過(guò)BGP交換路由，這些節(jié)點(diǎn)我們叫做BGP Peer。

需要注意的是calico 維護(hù)網(wǎng)絡(luò)的默認(rèn)模式是 node-to-node mesh ,這種模式下，每臺(tái)宿主機(jī)的BGP client都會(huì)跟集群所有的節(jié)點(diǎn)BGP client進(jìn)行通信交換路由。這樣一來(lái)，隨著節(jié)點(diǎn)規(guī)模數(shù)量N的增加，連接會(huì)以N的2次方增長(zhǎng)，會(huì)集群網(wǎng)絡(luò)本身帶來(lái)巨大壓力。

所以一般這種模式推薦的集群規(guī)模在50節(jié)點(diǎn)左右,超過(guò)50節(jié)點(diǎn)推薦使用另外一種RR（Router Reflector）模式，這種模式下，calico 可以指定幾個(gè)節(jié)點(diǎn)作為RR，他們負(fù)責(zé)跟所有節(jié)點(diǎn) BGP client 建立通信來(lái)學(xué)習(xí)集群所有的路由，其他節(jié)點(diǎn)只需要跟RR節(jié)點(diǎn)交換路由即可。這樣大大降低了連接數(shù)量，同時(shí)為了集群網(wǎng)絡(luò)穩(wěn)定性，建議RR>=2.

以上的工作原理依然是在二層通信，當(dāng)我們有兩臺(tái)宿主機(jī)，一臺(tái)是10.100.0.2/24，節(jié)點(diǎn)上容器網(wǎng)絡(luò)是10.92.204.0/24;另外一臺(tái)是10.100.1.2/24,節(jié)點(diǎn)上容器網(wǎng)絡(luò)是10.92.203.0/24,此時(shí)兩臺(tái)機(jī)器因?yàn)椴辉谕瑐€(gè)二層所以需要三層路由通信，這時(shí)calico就會(huì)在節(jié)點(diǎn)上生成如下路由表：

10.92.203.0/23 via 10.100.1.2 dev eth0 proto bird 

這時(shí)候問(wèn)題就來(lái)了，因?yàn)?0.100.1.2跟我們10.100.0.2不在同個(gè)子網(wǎng)，是不能二層通信的。這之后就需要使用Calico IPIP模式，當(dāng)宿主機(jī)不在同個(gè)二層網(wǎng)絡(luò)時(shí)就是用overlay網(wǎng)絡(luò)封裝以后再發(fā)出去。如下圖所示：

IPIP模式下在非二層通信時(shí)，calico 會(huì)在node節(jié)點(diǎn)添加如下路由規(guī)則:

10.92.203.0/24 via 10.100.1.2 dev tunnel0 

可以看到盡管下一條任然是node的IP地址，但是出口設(shè)備卻是tunnel0,其是一個(gè)IP隧道設(shè)備，主要有Linux內(nèi)核的IPIP驅(qū)動(dòng)實(shí)現(xiàn)。會(huì)將容器的ip包直接封裝宿主機(jī)網(wǎng)絡(luò)的IP包中，這樣到達(dá)node2以后再經(jīng)過(guò)IPIP驅(qū)動(dòng)拆包拿到原始容器IP包，然后通過(guò)路由規(guī)則發(fā)送給veth pair設(shè)備到達(dá)目標(biāo)容器。

以上盡管可以解決非二層網(wǎng)絡(luò)通信，但是仍然會(huì)因?yàn)榉獍徒獍鼘?dǎo)致性能下降。如果calico 能夠讓宿主機(jī)之間的router設(shè)備也學(xué)習(xí)到容器路由規(guī)則，這樣就可以直接三層通信了。比如在路由器添加如下的路由表：

10.92.203.0/24 via 10.100.1.2 dev interface1 

而node1添加如下的路由表:

10.92.203.0/24 via 10.100.1.1 dev tunnel0 

那么node1上的容器發(fā)出的IP包，基于本地路由表發(fā)送給10.100.1.1網(wǎng)關(guān)路由器，然后路由器收到IP包查看目的IP，通過(guò)本地路由表找到下一跳地址發(fā)送到node2，最終到達(dá)目的容器。這種方案，我們是可以基于underlay 網(wǎng)絡(luò)來(lái)實(shí)現(xiàn)，只要底層支持BGP網(wǎng)絡(luò)，可以和我們RR節(jié)點(diǎn)建立EBGP關(guān)系來(lái)交換集群內(nèi)的路由信息。

以上就是kubernetes 常用的幾種網(wǎng)絡(luò)方案了，在公有云場(chǎng)景下一般用云廠商提供的或者使用flannel host-gw這種更簡(jiǎn)單，而私有物理機(jī)房環(huán)境中，Calico項(xiàng)目更加適合。根據(jù)自己的實(shí)際場(chǎng)景，再選擇合適的網(wǎng)絡(luò)方案。