官场小说排行榜,大主宰之灵路天蚕土豆

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案

Kubernetes集群網(wǎng)絡從懵圈到熟悉，看這一篇就夠了

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

目前創(chuàng)新互聯(lián)建站已為上千余家的企業(yè)提供了網(wǎng)站建設、域名、網(wǎng)絡空間、綿陽服務器托管、企業(yè)網(wǎng)站設計、古交網(wǎng)站維護等服務，公司將堅持客戶導向、應用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長，共同發(fā)展。

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

容器網(wǎng)絡基礎

一個 Linux 容器的網(wǎng)絡棧是被隔離在它自己的 Network Namespace 中，Network Namespace 包括了：網(wǎng)卡（Network Interface），回環(huán)設備（Lookback Device），路由表（Routing Table）和 iptables 規(guī)則，對于服務進程來講這些就構(gòu)建了它發(fā)起請求和相應的基本環(huán)境。而要實現(xiàn)一個容器網(wǎng)絡，離不開以下Linux網(wǎng)絡功能：

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

基于以上的基礎，同宿主機的容器時間如何通信呢？

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

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

我們啟動一個容器：

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

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

 
 
 
 
  
  
  
  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)卡。然后通過route -n 查看容器中的路由表，eth0也正是默認路由出口。所有對172.17.0.0/16網(wǎng)段的請求都會從eth0出去。

我們再來看Veth peer的另一端，我們查看宿主機的網(wǎng)絡設備：

 
 
 
 
  
  
  
  ifconfig 
  
  
  
   
  
  
  
  docker0: flags=4163 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 
  
  
  
   
  
  
  
  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 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 
  
  
  
   
  
  
  
  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 mtu 65536 
  
  
  
   
  
  
  
  inet 127.0.0.1 netmask 255.0.0.0 
  
  
  
   
  
  
  
  inet6 ::1 prefixlen 128 scopeid 0x10 
  
  
  
   
  
  
  
  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 mtu 1500 
  
  
  
   
  
  
  
  inet6 fe80::30e2:9cff:fe45:329 prefixlen 64 scopeid 0x20 
  
  
  
   
  
  
  
  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

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

 
 
 
 
  
  
  
  # brctl show 
  
  
  
   
  
  
  
  docker0 8000.02426a4693d2 no veth20b3dac

然后我們再啟動一個容器，從第一個容器是否能 ping 通第二個容器。

 
 
 
 
  
  
  
  $ 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 目標IP172.17.0.3時，會匹配到我們的路由表第二條規(guī)則，網(wǎng)關為0.0.0.0，這就意味著是一條直連路由，通過二層轉(zhuǎn)發(fā)到目的地。

要通過二層網(wǎng)絡到達172.17.0.3，我們需要知道它的Mac地址，此時就需要第一個容器發(fā)送一個ARP廣播，來通過IP地址查找Mac。此時Veth peer另外一段是docker0網(wǎng)橋，它會廣播到所有連接它的veth peer 虛擬網(wǎng)卡去，然后正確的虛擬網(wǎng)卡收到后會響應這個ARP報文，然后網(wǎng)橋再回給第一個容器。

以上就是同宿主機不同容器通過 docker0 通信，如下圖所示:

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

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

跨主機網(wǎng)絡通信

在 Docker 的默認配置下，不同宿主機上的容器通過 IP 地址進行互相訪問是根本做不到的。為了解決這個問題，社區(qū)中出現(xiàn)了很多網(wǎng)絡方案。同時k8s為了更好的控制網(wǎng)絡的接入，推出了CNI即容器網(wǎng)絡的API接口。它是k8s中標準的一個調(diào)用網(wǎng)絡實現(xiàn)的接口,kubelet通過這個API來調(diào)用不同的網(wǎng)絡插件以實現(xiàn)不同的網(wǎng)絡配置，實現(xiàn)了這個接口的就是CNI插件，它實現(xiàn)了一系列的CNI API接口。目前已經(jīng)有的包括flannel、calico、weave、contiv等等。

實際上CNI的容器網(wǎng)絡通信流程跟前面的基礎網(wǎng)絡一樣，只是CNI維護了一個單獨的網(wǎng)橋來代替 docker0。這個網(wǎng)橋的名字就叫作：CNI 網(wǎng)橋，它在宿主機上的設備名稱默認是：cni0。cni的設計思想，就是：Kubernetes 在啟動 Infra 容器之后，就可以直接調(diào)用 CNI 網(wǎng)絡插件，為這個 Infra 容器的 Network Namespace，配置符合預期的網(wǎng)絡棧。

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

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

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

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

 
 
 
 
  
  
  
  10.244.1.0/24 via 10.168.0.3 dev eth0

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

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

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

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

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

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

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

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

calico 主要由三個部分組成:

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

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

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

 
 
 
 
  
  
  
  10.92.77.163 dev cali93a8a799fe1 scope link

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

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

 
 
 
 
  
  
  
  10.92.160.0/23 via 10.106.65.2 dev bond0 proto bird

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

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

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

以上的工作原理依然是在二層通信，當我們有兩臺宿主機，一臺是10.100.0.2/24，節(jié)點上容器網(wǎng)絡是10.92.204.0/24；另外一臺是10.100.1.2/24，節(jié)點上容器網(wǎng)絡是10.92.203.0/24，此時兩臺機器因為不在同個二層所以需要三層路由通信，這時calico就會在節(jié)點上生成如下路由表：

 
 
 
 
  
  
  
  10.92.203.0/23 via 10.100.1.2 dev eth0 proto bird

這時候問題就來了，因為 10.100.1.2 跟我們 10.100.0.2 不在同個子網(wǎng)，是不能二層通信的。這之后就需要使用 Calico IPIP 模式，當宿主機不在同個二層網(wǎng)絡時就是用overlay網(wǎng)絡封裝以后再發(fā)出去。如下圖所示：

IPIP 模式下在非二層通信時，calico 會在node節(jié)點添加如下路由規(guī)則：

 
 
 
 
  
  
  
  10.92.203.0/24 via 10.100.1.2 dev tunnel0

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

以上盡管可以解決非二層網(wǎng)絡通信，但是仍然會因為封包和解包導致性能下降。如果calico 能夠讓宿主機之間的 router 設備也學習到容器路由規(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)關路由器，然后路由器收到 IP 包查看目的IP，通過本地路由表找到下一跳地址發(fā)送到 node2，最終到達目的容器。這種方案，我們是可以基于underlay 網(wǎng)絡來實現(xiàn)，只要底層支持 BGP 網(wǎng)絡，可以和我們 RR 節(jié)點建立 EBGP 關系來交換集群內(nèi)的路由信息。

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

分享文章：Kubernetes集群網(wǎng)絡從懵圈到熟悉，看這一篇就夠了
文章地址：http://fisionsoft.com.cn/article/dppjgio.html

新聞中心

容器網(wǎng)絡基礎

跨主機網(wǎng)絡通信

其他資訊