在Kubernetes中要保證容器之間網絡互通，網絡至關重要。而Kubernetes本身并沒有自己實作容器網絡，而是通過插件化的方式自由接入進來。在容器網絡接入進來需要滿足如下基本原則：
- Pod無論運作在任何節點都可以互相直接通信，而不需要借助NAT位址轉換實作。
- Node與Pod可以互相通信，在不限制的前提下，Pod可以通路任意網絡。
- Pod擁有獨立的網絡棧，Pod看到自己的位址和外部看見的位址應該是一樣的，并且同個Pod内所有的容器共享同個網絡棧。
容器網絡基礎
一個Linux容器的網絡棧是被隔離在它自己的Network Namespace中，Network Namespace包括了：網卡（Network Interface），回環裝置（Lookback Device），路由表（Routing Table）和iptables規則，對于服務程序來講這些就建構了它發起請求和相應的基本環境。而要實作一個容器網絡，離不開以下Linux網絡功能：
- 網絡命名空間：将獨立的網絡協定棧隔離到不同的指令空間中，彼此間無法通信
- Veth Pair：Veth裝置對的引入是為了實作在不同網絡命名空間的通信，總是以兩張虛拟網卡（veth peer）的形式成對出現的。并且，從其中一端發出的資料，總是能在另外一端收到
- Iptables/Netfilter：Netfilter負責在核心中執行各種挂接的規則（過濾、修改、丢棄等），運作在核心中；Iptables模式是在使用者模式下運作的程序，負責協助維護核心中Netfilter的各種規則表；通過二者的配合來實作整個Linux網絡協定棧中靈活的資料包處理機制
- 網橋：網橋是一個二層網絡虛拟裝置，類似交換機，主要功能是通過學習而來的Mac位址将資料幀轉發到網橋的不同端口上
- 路由: Linux系統包含一個完整的路由功能，當IP層在處理資料發送或轉發的時候，會使用路由表來決定發往哪裡
基于以上的基礎，同主控端的容器時間如何通信呢？
我們可以簡單把他們了解成兩台主機，主機之間通過網線連接配接起來，如果要多台主機通信，我們通過交換機就可以實作彼此互通，在Linux中，我們可以通過網橋來轉發資料。
在容器中，以上的實作是通過docker0網橋，凡是連接配接到docker0的容器，就可以通過它來進行通信。要想容器能夠連接配接到docker0網橋，我們也需要類似網線的虛拟裝置Veth Pair來把容器連接配接到網橋上。
我們啟動一個容器：
docker run -d --name c1 hub.pri.ibanyu.com/devops/alpine:v3.8 /bin/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的網卡，它就是veth peer其中的一端的虛拟網卡。然後通過route -n 檢視容器中的路由表，eth0也正是預設路由出口。所有對172.17.0.0/16網段的請求都會從eth0出去。
我們再來看Veth peer的另一端，我們檢視主控端的網絡裝置：
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
我們可以看到，容器對應的Veth peer另一端是主控端上的一塊虛拟網卡叫veth20b3dac，并且可以通過brctl檢視網橋資訊看到這張網卡是在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時，會比對到我們的路由表第二條規則，網關為0.0.0.0，這就意味着是一條直連路由，通過二層轉發到目的地。要通過二層網絡到達172.17.0.3，我們需要知道它的Mac位址，此時就需要第一個容器發送一個ARP廣播，來通過IP位址查找Mac。此時Veth peer另外一段是docker0網橋，它會廣播到所有連接配接它的veth peer虛拟網卡去，然後正确的虛拟網卡收到後會響應這個ARP封包，然後網橋再回給第一個容器。
以上就是同主控端不同容器通過docker0通信，如下圖所示：
預設情況下，通過network namespace限制的容器程序，本質上是通過Veth peer裝置和主控端網橋的方式，實作了不同network namespace的資料交換。
與之類似地，當你在一台主控端上，通路該主控端上的容器的IP位址時，這個請求的資料包，也是先根據路由規則到達docker0網橋，然後被轉發到對應的Veth Pair裝置，最後出現在容器裡。
跨主機網絡通信
在Docker的預設配置下，不同主控端上的容器通過IP位址進行互相通路是根本做不到的。為了解決這個問題，社群中出現了很多網絡方案。同時Kubernetes為了更好的控制網絡的接入，推出了CNI即容器網絡的API接口。它是Kubernetes中标準的一個調用網絡實作的接口，kubelet通過這個API來調用不同的網絡插件以實作不同的網絡配置，實作了這個接口的就是CNI插件，它實作了一系列的CNI API接口。目前已經有的包括Flannel、Calico、Weave、Contiv等等。
實際上CNI的容器網絡通信流程跟前面的基礎網絡一樣，隻是CNI維護了一個單獨的網橋來代替 docker0。這個網橋的名字就叫作：CNI 網橋，它在主控端上的裝置名稱預設是：cni0。cni的設計思想，就是：Kubernetes在啟動Infra容器之後，就可以直接調用CNI網絡插件，為這個Infra容器的Network Namespace，配置符合預期的網絡棧。
CNI插件三種網絡實作模式：
- Overlay模式是基于隧道技術實作的，整個容器網絡和主機網絡獨立，容器之間跨主機通信時将整個容器網絡封裝到底層網絡中，然後到達目标機器後再解封裝傳遞到目标容器。不依賴與底層網絡的實作。實作的插件有Flannel（UDP、vxlan）、Calico（IPIP）等等
- 三層路由模式中容器和主機也屬于不通的網段，他們容器互通主要是基于路由表打通，無需在主機之間建立隧道封包。但是限制條件必須依賴大二層同個區域網路内。實作的插件有Flannel（host-gw）、Calico（BGP）等等
- Underlay網絡是底層網絡，負責互聯互通。容器網絡和主機網絡依然分屬不同的網段，但是彼此處于同一層網絡，處于相同的地位。整個網絡三層互通，沒有大二層的限制，但是需要強依賴底層網絡的實作支援.實作的插件有Calico（BGP）等等
我們看下路由模式的一種實作flannel Host-gw：
如圖可以看到當node1上container-1要發資料給node2上的container2時,會比對到如下的路由表規則：
10.244.1.0/24 via 10.168.0.3 dev eth0
表示前往目标網段10.244.1.0/24的IP包，需要經過本機eth0出去發往的下一跳IP位址為10.168.0.3(node2)，然後到達10.168.0.3以後再通過路由表轉發CNI網橋，進而進入到container2。
以上可以看到host-gw工作原理，其實就是在每個Node節點配置到每個Pod網段的下一跳為Pod網段所在的Node節點IP，Pod網段和Node節點IP的映射關系，Flannel儲存在etcd或者Kubernetes中。Flannel隻需要watch這些資料的變化來動态更新路由表即可。
這種網絡模式最大的好處就是避免了額外的封包和解包帶來的網絡性能損耗。缺點我們也能看見主要就是容器IP包通過下一跳出去時，必須要二層通信封裝成資料幀發送到下一跳。如果不在同個二層區域網路，那麼就要交給三層網關，而此時網關是不知道目标容器網絡的（也可以靜态在每個網關配置Pod網段路由）。是以flannel host-gw必須要求叢集主控端是二層互通的。
而為了解決二層互通的限制性，Calico提供的網絡方案就可以更好的實作，Calico大三層網絡模式與Flannel提供的類似，也會在每台主控端添加如下格式的路由規則：
<目标容器IP網段> via <網關的IP位址> dev eth0
其中網關的IP位址不通場景有不同的意思，如果主控端是二層可達那麼就是目的容器所在的主控端的IP位址，如果是三層不同區域網路那麼就是本機主控端的網關IP（交換機或者路由器位址）。
不同于Flannel通過Kubernetes或者etcd存儲的資料來維護本機路由資訊的做法，Calico是通過BGP動态路由協定來分發整個叢集路由資訊。
BGP全稱是Border Gateway Protocol邊界網關協定，Linxu原生支援的、專門用于在大規模資料中心為不同的自治系統之間傳遞路由資訊。隻要記住BGP簡單了解其實就是實作大規模網絡中節點路由資訊同步共享的一種協定。而BGP這種協定就能代替Flannel維護主機路由表功能。
Calico主要由三個部分組成：
- Calico CNI插件：主要負責與kubernetes對接，供kubelet調用使用。
- Felix：負責維護主控端上的路由規則、FIB轉發資訊庫等。
- BIRD：負責分發路由規則，類似路由器。
- Confd：配置管理元件。
除此之外，Calico還和flannel host-gw不同之處在于，它不會建立網橋裝置，而是通過路由表來維護每個Pod的通信，如下圖所示：
可以看到Calico的CNI插件會為每個容器設定一個veth pair裝置，然後把另一端接入到主控端網絡空間，由于沒有網橋，CNI插件還需要在主控端上為每個容器的veth pair裝置配置一條路由規則，用于接收傳入的IP包，路由規則如下：
10.92.77.163 dev cali93a8a799fe1 scope link
以上表示發送10.92.77.163的IP包應該發給cali93a8a799fe1裝置，然後到達另外一段容器中。
有了這樣的veth pair裝置以後，容器發出的IP包就會通過veth pair裝置到達主控端，然後主控端根據路有規則的下一條位址，發送給正确的網關（10.100.1.3），然後到達目标主控端，在到達目标容器。
10.92.160.0/23 via 10.106.65.2 dev bond0 proto bird
這些路由規則都是Felix維護配置的，而路由資訊則是calico bird元件基于BGP分發而來。Calico實際上是将叢集裡所有的節點都當做邊界路由器來處理，他們一起組成了一個全互聯的網絡，彼此之間通過BGP交換路由，這些節點我們叫做BGP Peer。
需要注意的是Calico維護網絡的預設模式是node-to-node mesh，這種模式下，每台主控端的BGP client都會跟叢集所有的節點BGP client進行通信交換路由。這樣一來，随着節點規模數量N的增加，連接配接會以N的2次方增長，會叢集網絡本身帶來巨大壓力。
是以一般這種模式推薦的叢集規模在50節點左右，超過50節點推薦使用另外一種RR（Router Reflector）模式，這種模式下，Calico可以指定幾個節點作為RR，他們負責跟所有節點BGP client建立通信來學習叢集所有的路由，其他節點隻需要跟RR節點交換路由即可。這樣大大降低了連接配接數量，同時為了叢集網絡穩定性，建議RR>=2。
以上的工作原理依然是在二層通信，當我們有兩台主控端，一台是10.100.0.2/24，節點上容器網絡是10.92.204.0/24；另外一台是10.100.1.2/24，節點上容器網絡是10.92.203.0/24，此時兩台機器因為不在同個二層是以需要三層路由通信，這時Calico就會在節點上生成如下路由表：
10.92.203.0/23 via 10.100.1.2 dev eth0 proto bird
這時候問題就來了，因為10.100.1.2跟我們10.100.0.2不在同個子網，是不能二層通信的。這之後就需要使用Calico IPIP模式，當主控端不在同個二層網絡時就是用Overlay網絡封裝以後再發出去。如下圖所示：
IPIP模式下在非二層通信時，Calico會在Node節點添加如下路由規則：
10.92.203.0/24 via 10.100.1.2 dev tunnel0
可以看到盡管下一條任然是Node的IP位址，但是出口裝置卻是tunnel0，其是一個IP隧道裝置，主要有Linux核心的IPIP驅動實作。會将容器的IP包直接封裝主控端網絡的IP包中，這樣到達node2以後再經過IPIP驅動拆包拿到原始容器IP包，然後通過路由規則發送給veth pair裝置到達目标容器。
以上盡管可以解決非二層網絡通信，但是仍然會因為封包和解包導緻性能下降。如果Calico能夠讓主控端之間的router裝置也學習到容器路由規則，這樣就可以直接三層通信了。比如在路由器添加如下的路由表：
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上的容器發出的IP包，基于本地路由表發送給10.100.1.1網關路由器，然後路由器收到IP包檢視目的IP，通過本地路由表找到下一跳位址發送到node2，最終到達目的容器。這種方案，我們是可以基于underlay 網絡來實作，隻要底層支援BGP網絡，可以和我們RR節點建立EBGP關系來交換叢集内的路由資訊。
以上就是Kubernetes常用的幾種網絡方案了，在公有雲場景下一般用雲廠商提供的或者使用flannel host-gw這種更簡單，而私有實體機房環境中，Calico項目更加适合。根據自己的實際場景，再選擇合适的網絡方案。
原文連結：
https://tech.ipalfish.com/blog/2020/03/06/kubernetes_container_network/
- END -
看完一鍵三連在看，轉發，點贊
是對文章最大的贊賞，極客重生感謝你
推薦閱讀
圖解Linux 核心TCP/IP 協定棧實作|Linux網絡硬核系列
網絡排障全景指南手冊v1.0精簡版pdf
一個奇葩的網絡問題