Kubernetes是用于大規(guī)模管理容器化應(yīng)用程序出色的編排工具。但是，您可能知道，使用kubernetes并非易事，尤其是后端網(wǎng)絡(luò)實現(xiàn)。我在網(wǎng)絡(luò)中遇到了許多問題，花了我很多時間弄清楚它是如何工作的。

我想以最簡單的實現(xiàn)為例，來解釋kubernetes的網(wǎng)絡(luò)工作。

Kubernetes網(wǎng)絡(luò)模型

下圖顯示了kubernetes集群的簡單圖像：

Kubernetes管理Linux機器集群（可能是ECS之類的云VM或物理服務(wù)器），在每臺主機上，kubernetes運行任意數(shù)量的Pod，在每個Pod中可以有任意數(shù)量的容器。用戶的應(yīng)用程序正在這些容器之一中運行。

對于kubernetes，Pod是最小的管理單元，并且一個Pod中的所有容器共享相同的網(wǎng)絡(luò)名稱空間，這意味著它們具有相同的網(wǎng)絡(luò)接口并且可以使用*localhost*相互連接

在官方文件中說kubernetes網(wǎng)絡(luò)模式要求：

• 所有容器無需NAT即可與所有其他容器通信
• 所有節(jié)點都可以與所有容器通信（反之亦然），而無需NAT
• 容器所看到的IP其他人所看到的IP一樣

我們可以按照上述要求將所有容器替換為Pod，因為容器與Pod網(wǎng)絡(luò)共享。

基本上，這意味著所有Pod都應(yīng)該能夠與群集中的其他Pod自由通信，即使它們位于不同的主機中，并且它們也使用自己的IP地址相互識別，就像基礎(chǔ)主機不存在一樣。此外，主機也應(yīng)該能夠使用自己的IP地址與任何Pod通信，而無需任何地址轉(zhuǎn)換。

Kubernetes不提供任何默認的網(wǎng)絡(luò)實現(xiàn)，而是僅定義模型，并由其他工具來實現(xiàn)。如今有很多實現(xiàn)，F(xiàn)lannel是其中之一，也是最簡單的之一。在以下各節(jié)中，我將解釋Flannel的UDP模式實現(xiàn)。

The Overlay Network

Flannel是由CoreOS創(chuàng)建的，用于Kubernetes網(wǎng)絡(luò)，也可以用作其他目的的通用軟件定義網(wǎng)絡(luò)解決方案。

為了滿足kubernetes的網(wǎng)絡(luò)要求，flannel的想法很簡單：創(chuàng)建另一個在主機網(wǎng)絡(luò)之上運行的扁平網(wǎng)絡(luò)，這就是所謂的覆蓋網(wǎng)絡(luò)overlay network。在此覆蓋網(wǎng)絡(luò)中，所有容器（Pod）將被分配一個IP地址，它們通過直接調(diào)用彼此的IP地址來相互通信。

為了幫助解釋，我在AWS上使用了一個小型的測試kubernetes集群，該集群中有3個Kubernetes節(jié)點。網(wǎng)絡(luò)如下所示：

此群集中有三個網(wǎng)絡(luò)：

AWS VPC網(wǎng)絡(luò)：所有實例都在一個VPC子網(wǎng)中172.20.32.0/19。它們已經(jīng)在此范圍內(nèi)分配了ip地址，所有主機都可以彼此連接，因為它們位于同一LAN中。

Flannel overlay network：flannel創(chuàng)建了另一個網(wǎng)絡(luò)100.96.0.0/16，它是一個更大的網(wǎng)絡(luò)，可以容納65536個地址，并且遍及所有kubernetes節(jié)點，將在此范圍內(nèi)為每個Pod分配一個地址，稍后我們將看到flannel如何實現(xiàn)此目的。

主機內(nèi)docker網(wǎng)絡(luò)：在每個主機內(nèi)部，flannel為該主機中的所有pod分配了一個網(wǎng)絡(luò)100.96.x.0/24，它可以容納256地址。docker橋接接口docker0將使用此網(wǎng)絡(luò)創(chuàng)建新容器。

通過這種設(shè)計，每個容器都有其自己的IP地址，都屬于覆蓋子網(wǎng)100.96.0.0/16。同一主機內(nèi)的容器可以通過docker bridge網(wǎng)絡(luò)接口Docker0相互通信，這很簡單，因此在本文中我將跳過。為了在主機上與覆蓋網(wǎng)絡(luò)中的其他容器進行跨主機通信，flannel使用內(nèi)核路由表和UDP封裝來實現(xiàn)該功能，以下各節(jié)對此進行了說明。

跨主機容器通信

假設(shè)具有IP地址的節(jié)點1中的容器（我們將其稱為容器1）100.96.1.2要使用IP地址連接到節(jié)點2中的容器（我們將其稱為容器2）100.96.2.3，讓我們看看覆蓋網(wǎng)絡(luò)如何啟用數(shù)據(jù)包通過。

第一個container-1使用創(chuàng)建一個IP數(shù)據(jù)包src: 100.96.1.2 -> dst: 100.96.2.3，該數(shù)據(jù)包將作為容器的網(wǎng)關(guān)進入docker0網(wǎng)橋。

在每個主機中，flannel運行一個名為的守護進程flanneld，它在內(nèi)核的路由表中創(chuàng)建一些路由規(guī)則，這是節(jié)點1的路由表的樣子：

admin@ip-172-20-33-102:~$ ip route
default via 172.20.32.1 dev eth0
100.96.0.0/16 dev flannel0  proto kernel  scope link  src 100.96.1.0
100.96.1.0/24 dev docker0  proto kernel  scope link  src 100.96.1.1
172.20.32.0/19 dev eth0  proto kernel  scope link  src 172.20.33.102

如我們所見，數(shù)據(jù)包的目標地址100.96.2.3位于更大的覆蓋網(wǎng)絡(luò)中100.96.0.0/16，因此它與第二條規(guī)則匹配，現(xiàn)在內(nèi)核知道應(yīng)該將數(shù)據(jù)包發(fā)送到flannel0。

flannel0TUN是由我們的flanneld守護進程創(chuàng)建的TUN設(shè)備，TUN是在Linux內(nèi)核中實現(xiàn)的軟件接口，它可以在用戶程序和內(nèi)核之間傳遞原始ip數(shù)據(jù)包。它在兩個方向上起作用：

• 將IP數(shù)據(jù)包寫入     flannel0設(shè)備時，該數(shù)據(jù)包將直接發(fā)送到內(nèi)核，內(nèi)核將根據(jù)其路由表對數(shù)據(jù)包進行路由
• 當(dāng)IP數(shù)據(jù)包到達內(nèi)核，并且路由表說應(yīng)該將其路由到     flannel0設(shè)備時，內(nèi)核會將數(shù)據(jù)包直接發(fā)送到創(chuàng)建該設(shè)備的     flanneld進程，該進程是守護進程。

當(dāng)內(nèi)核將數(shù)據(jù)包發(fā)送到TUN設(shè)備時，它將直接進入flanneld進程，它看到目標地址為100.96.2.3，盡管從圖中可以看出該地址屬于在Node 2上運行的容器，但是如何flanneld知道呢？

Flannel碰巧將某些信息存儲在名為etcd的鍵值存儲服務(wù)中，如果您知道kubernetes，則不應(yīng)感到驚訝。在flannel，我們可以將其視為常規(guī)鍵值存儲。

Flannel將子網(wǎng)映射信息存儲到etcd服務(wù)中，我們可以使用以下etcdctl命令查看它：

admin@ip-172-20-33-102:~$ etcdctl ls /coreos.com/network/subnets
/coreos.com/network/subnets/100.96.1.0-24
/coreos.com/network/subnets/100.96.2.0-24
/coreos.com/network/subnets/100.96.3.0-24
admin@ip-172-20-33-102:~$ etcdctl get /coreos.com/network/subnets/100.96.2.0-24
{"PublicIP":"172.20.54.98"}

因此，每個flanneld進程查詢etcd都知道每個子網(wǎng)屬于哪個主機，并將目標ip地址與etcd中存儲的所有子網(wǎng)密鑰進行比較。在本例中，該地址100.96.2.3將與子網(wǎng)匹配100.96.2.0-24，并且如我們所見，存儲在此鍵中的值表示Node ip為172.20.54.98。

現(xiàn)在flanneld知道了目的地址，然后將原始IP數(shù)據(jù)包包裝到UDP數(shù)據(jù)包中，以其自己的主機ip作為源地址，而目標主機的IP作為目的地址。在每個主機中，該flanneld進程將偵聽默認的UDP端口:8285。因此，只需要將UDP數(shù)據(jù)包的目標端口設(shè)置為8285，然后通過網(wǎng)絡(luò)發(fā)送它。

UDP數(shù)據(jù)包到達目標主機后，內(nèi)核的IP堆棧會將數(shù)據(jù)包發(fā)送到flanneld進程，因為那是用戶進程在UDP端口上偵聽:8285。然后flanneld將獲得UDP數(shù)據(jù)包的有效負載，該數(shù)據(jù)包是由原始容器生成的原始IP數(shù)據(jù)包，只需將其寫入TUN設(shè)備flannel0，然后該數(shù)據(jù)包將直接傳遞到內(nèi)核，這就是TUN的工作方式。

與節(jié)點1相同，路由表將決定此數(shù)據(jù)包的去向，讓我們看一下節(jié)點2的路由表：

admin@ip-172-20-54-98:~$ ip route
default via 172.20.32.1 dev eth0
100.96.0.0/16 dev flannel0  proto kernel  scope link  src 100.96.2.0
100.96.2.0/24 dev docker0  proto kernel  scope link  src 100.96.2.1
172.20.32.0/19 dev eth0  proto kernel  scope link  src 172.20.54.98

IP數(shù)據(jù)包的目標地址是100.96.2.3，內(nèi)核將采用最精確的匹配，這是第三條規(guī)則。數(shù)據(jù)包將發(fā)送到docker0設(shè)備。就像docker0橋接設(shè)備一樣，此主機中的所有容器都連接到該橋接器，最終目的地容器2將看到并接收到該數(shù)據(jù)包。

最終，我們的數(shù)據(jù)包完成了一種傳遞到目標的方式，當(dāng)contianer-2將數(shù)據(jù)包發(fā)送回容器1時，反向路由將以完全相同的方式工作。這就是跨主機容器通信的工作方式。

使用Docker網(wǎng)絡(luò)進行配置

在以上解釋中，我們遺漏了一點。這就是我們?nèi)绾闻渲胐ocker使用較小的子網(wǎng)100.96.x.0/24？

碰巧flanneld會將其子網(wǎng)信息寫入主機中的文件中：

admin@ip-172-20-33-102:~$ cat /run/flannel/subnet.env
FLANNEL_NETWORK=100.96.0.0/16
FLANNEL_SUBNET=100.96.1.1/24
FLANNEL_MTU=8973
FLANNEL_IPMASQ=true

該信息將用于配置docker守護程序的選項，因此docker可以將FLANNEL_SUBNET用作其橋接網(wǎng)絡(luò)，然后主機容器網(wǎng)絡(luò)將起作用：

dockerd --bip = $ FLANNEL_SUBNET --mtu = $ FLANNEL_MTU

數(shù)據(jù)包復(fù)制和性能

較新版本的flannel不建議將UDP封裝用于生產(chǎn)，它表示僅應(yīng)將其用于調(diào)試和測試目的。原因之一是性能。

盡管flannel0TUN設(shè)備提供了一種通過內(nèi)核獲取和發(fā)送數(shù)據(jù)包的簡單方法，但它會降低性能：必須將數(shù)據(jù)包從用戶空間來回復(fù)制到內(nèi)核空間：

如上所述，必須從原始容器進程發(fā)送數(shù)據(jù)包，然后在用戶空間和內(nèi)核空間之間復(fù)制3次，這將顯著增加網(wǎng)絡(luò)開銷，因此，如果可以的話，應(yīng)避免在生產(chǎn)中使用UDP。

Flannel是kubernetes網(wǎng)絡(luò)模型的最簡單實現(xiàn)之一。它使用現(xiàn)有的Docker網(wǎng)絡(luò)和帶有守護進程的額外Tun設(shè)備進行UDP封裝。我解釋了核心部分的詳細信息：跨主機容器通信，并簡要提到了性能損失。