## 1. Linux網路基礎

### 1.1 名詞解釋

1. Network Namespace(網路名稱空間)：Linux在網路棧中引入網路名稱空間，將獨立的網路協議棧隔離到不同的命令空間中，彼此間無法通訊；docker利用這一特性，實現不容器間的網路隔離。
2. Iptables/Netfilter：Netfilter負責在核心中執行各種掛接的規則(過濾、修改、丟棄等)，執行在核心模式中；Iptables模式是在使用者模式下執行的程式，負責協助維護核心中Netfilter的各種規則表；透過分析進入主機的網路封包，將封包的表頭資料提取出來進行分析，以決定該聯機為放行或抵擋的機制。 由於這種方式可以直接分析封包表頭資料，所以包括硬體地址(MAC), 軟體地址 (IP), TCP, UDP, ICMP 等封包的資訊都可以進行過濾分析。
3. Veth裝置對：Veth裝置對的引入是為了實現在不同網路名稱空間的通訊。
4. Bridge(網橋)：網橋是一個二層網路裝置，是最簡單的CNI網路外掛，它首先在Host建立一個網橋，然後再透過veth pair連線該網橋到container netns。另外，Bridge模式下，多主機網路通訊需要額外配置主機路由
5. Route(路由)：Linux系統包含一個完整的路由功能，當IP層在處理資料傳送或轉發的時候會使用路由表來決定發往哪裡。
6. Container Network Interface (CNI) 最早是由CoreOS發起的容器網路規範，是 Kubernetes網路外掛的基礎。其基本思想為:Container Runtime在建立容器時，先建立好network namespace，然後呼叫CNI外掛為這個netns配置網路，其後再啟動容器內的程式

## 2. Kubernetes 網路模型

Kubernetes網路有一個重要的基本設計原則：

**每個Pod擁有唯一的IP**

這個Pod IP被該Pod內的所有容器共享，並且其它所有Pod都可以路由到該Pod。你可曾注意到，你的Kubernetes節點上執行著一些"pause"容器？它們被稱作“沙盒容器（sandbox containers）"，其唯一任務是保留並持有一個網路名稱空間（netns），該名稱空間被Pod內所有容器共享。透過這種方式，即使一個容器死掉，新的容器建立出來代替這個容器，Pod IP也不會改變。這種IP-per-pod模型的巨大優勢是，Pod和底層主機不會有IP或者埠衝突。我們不用擔心應用使用了什麼埠。

這點滿足後，Kubernetes唯一的要求是，這些Pod IP可被其它所有Pod訪問，不管那些Pod在哪個節點。

### 2.1 節點內通訊

第一步是確保同一節點上的Pod可以相互通訊，然後可以擴充套件到跨節點通訊、internet上的通訊，等等。

![](http://img.blog.itpub.net/blog/2019/11/19/3d63492aa03e7a81.png?x-oss-process=style/bb)

<div align="center">Kubernetes Node(root network namespace)</div>

在每個Kubernetes節點（本場景指的是Linux機器）上，都有一個根（root）名稱空間（root是作為基準，而不是超級使用者）-- root netns(root network namespace)。

主要的網路介面 eth0 就是在這個root netns下。
![](http://img.blog.itpub.net/blog/2019/11/19/e683d97ba2f5b3f3.png?x-oss-process=style/bb)

<div align="center">Kubernetes Node（pod network namespace）</div>

類似的，每個Pod都有其自身的netns(network namespace)，透過一個虛擬的乙太網對連線到root netns。這基本上就是一個管道對，一端在root netns內，另一端在Pod的netns內。

我們把Pod端的網路介面叫 eth0，這樣Pod就不需要知道底層主機，它認為它擁有自己的根網路裝置。另一端命名成比如 vethxxx。你可以用 `ifconfig` 或者 `ip a` 命令列出你的節點上的所有這些介面。

![](http://img.blog.itpub.net/blog/2019/11/19/c0f53a70ff562ffd.png?x-oss-process=style/bb)

<div align="center">Kubernetes Node（linux network bridge）</div>

節點上的所有Pod都會完成這個過程。這些Pod要相互通訊，就要用到linux的乙太網橋 cbr0 了。Docker使用了類似的網橋，稱為docker0。你可以用 `brctl show` 命令列出所有網橋。

![](http://img.blog.itpub.net/blog/2019/11/19/96186e0347ffdedf.gif?x-oss-process=style/bb)

<div align="center">Kubernetes Node（same node pod-to-pod communication）</div>

假設一個網路資料包要由pod1到pod2

1. 它由pod1中netns的eth0網口離開，透過vethxxx進入root netns。
2. 然後被傳到cbr0，cbr0使用ARP請求，說“誰擁有這個IP”，從而發現目標地址。
3. vethyyy說它有這個IP，因此網橋就知道了往哪裡轉發這個包。
4. 資料包到達vethyyy，跨過管道對，到達pod2的netns。

這就是同一節點內容器間通訊的流程。當然也可以用其它方式，但是無疑這是最簡單的方式，同時也是Docker採用的方式。

### 2.2 不同節點間通訊

正如我前面提到，Pod也需要跨節點可達。Kubernetes不關心如何實現。我們可以使用L2（ARP跨節點），L3（IP路由跨節點，就像雲提供商的路由表），Overlay網路，或者甚至信鴿。無所謂，只要流量能到達另一個節點的期望Pod就好。每個節點都為Pod IPs分配了唯一的CIDR塊（一段IP地址範圍），因此每個Pod都擁有唯一的IP，不會和其它節點上的Pod衝突。

大多數情況下，特別是在雲環境上，雲提供商的路由表就能確保資料包到達正確的目的地。我們在每個節點上建立正確的路由也能達到同樣的目的。許多其它的網路外掛透過自己的方式達到這個目的。

這裡我們有兩個節點，與之前看到的類似。每個節點有不同的網路名稱空間、網路介面以及網橋。

![](http://img.blog.itpub.net/blog/2019/11/19/e977bf344b1270d4.gif?x-oss-process=style/bb)

<div align="center">Kubernetes Nodes with route table（cross node pod-to-pod communication）</div>

假設一個資料包要從pod1到達pod4（在不同的節點上）

1. 它由pod1中netns的eth0網口離開，透過vethxxx進入root netns。
2. 然後被傳到cbr0，cbr0透過傳送ARP請求來找到目標地址。
3. 本節點上沒有Pod擁有pod4的IP地址，根據路由判斷資料包由cbr0 傳到主網路介面 eth0.
4. 資料包的源地址為pod1，目標地址為pod4，它以這種方式離開node1進入電纜。
5. 路由表有每個節點的CIDR塊的路由設定，它把資料包路由到CIDR塊包含pod4的IP的節點。
6. 因此資料包到達了node2的主網路介面eth0。現在即使pod4不是eth0的IP，資料包也仍然能轉發到cbr0，因為節點配置了IP forwarding enabled。節點的路由表尋找任意能匹配pod4 IP的路由。它發現了 cbr0 是這個節點的CIDR塊的目標地址。你可以用route -n命令列出該節點的路由表，它會顯示cbr0的路由，型別如下：
![](http://img.blog.itpub.net/blog/2019/11/19/57ea616648b317de.png?x-oss-process=style/bb)

7. 網橋接收了資料包，傳送ARP請求，發現目標IP屬於vethyyy。
8. 資料包跨過管道對到達pod4。

這就是Kubernetes網路的基礎。下次你碰到問題，務必先檢查這些網橋、iptables規則表和路由表。

【Kubernetes系列】第9篇網路原理解析（上篇）

相關文章

【Kubernetes系列】第9篇 網路原理解析（上篇）

相關文章

【Kubernetes系列】第9篇網路原理解析（上篇）