怎樣進行Kubernetes的網絡原理解析

這篇文章給大家介紹怎樣進行Kubernetes的網絡原理解析，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

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上的通信，等等。

Kubernetes Node(root network namespace)

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

主要的網絡接口 eth0 就是在這個root netns下。

Kubernetes Node（pod network namespace）

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

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

Kubernetes Node（linux network bridge）

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

Kubernetes Node（same node pod-to-pod communication）

假設一個網絡數據包要由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沖突。

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

這里我們有兩個節點，與之前看到的類似。每個節點有不同的網絡命名空間、網絡接口以及網橋。

Kubernetes Nodes with route table（cross node pod-to-pod communication）

假設一個數據包要從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的路由，類型如下：
   

7. 網橋接收了數據包，發送ARP請求，發現目標IP屬于vethyyy。

8. 數據包跨過管道對到達pod4。

關于怎樣進行Kubernetes的網絡原理解析就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。